Remote control - strange behaviour

[Miguel Gutiérrez Páez]

Hi all,

First of all, thanks for this fantastic piece of software.

I'm starting to play with stellarium's api.

I don't know if I'm missing something or there is something wrong. I've read the user manual, but cannot find an explanation of what I'm experiencing.

I have a loop of code with sets two different dates in stellarium. After each 'setTime' request, I perform a 'status' request to find out some data.

Let me explain with the following (bash) code:

JD1=2459419.375162037
JD2=3454563.375162037

while [[ true ]]

do

curl -s -XPOST "http://localhost:8090/api/main/time?time=${JD1}"  > /dev/null 2>&1
curl -s "http://localhost:8090/api/main/status"
curl -s -XPOST "http://localhost:8090/api/main/time?time=${JD2}" > /dev/null 2>&1
curl -s "http://localhost:8090/api/main/status"
done

Hope it's clear. It switches between two dates, and performs a query to find out a particular data (HA/Dec).

Well, the output should be like (I omitted in the code the 'grep' part):

HA/Dec:     6h45m45.31s
HA/Dec:    18h49m46.07s
HA/Dec:     6h45m45.29s
HA/Dec:    18h49m46.11s
HA/Dec:     6h45m45.30s
[...]

I've pasted the parsed output.

Well, the above, actually does not happen. Instead, I get some weird result, in the form:

HA/Dec:     6h45m44.33s
HA/Dec:    21h31m08.54s
HA/Dec:     4h04m20.89s
HA/Dec:    18h49m45.10s
HA/Dec:     4h04m20.89s
HA/Dec:    18h49m45.10s

Output does not switches from one to another.

*BUT*, if I insert a 1 sec sleep before calling the status api entrypoint, it works as expected.

Seems like stellarium does not have enough data to process so many queries, but did not find anything in the doc. Surely, I'm missing something.

Any help?

Regards

[Georg Zotti]

Yes, after setting the time you need to wait for one frame to let the actual computations run. 1/10s waiting should be enough if your framerate is always higher than 10fps.

The main application of the plugin is interactive control (see its web interface). What you are doing (sending many commands in automatized sequence) could be better done in a script.

[Miguel Gutiérrez Páez]

Hi Georg,

Thanks for the reply and clarification. I will have a look to stellarium scripting. It seems to fit my needs.

Regards

--
You received this message because you are subscribed to the Google Groups "Stellarium" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellarium+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellarium/27ef425e-778b-4ec7-9142-b67d1fa72b9an%40googlegroups.com.

[Georg Zotti]

Also here, insert a wait(0.1) or so after changing the time. Creating ephemerides by scripting is not the designated use, so expect some unelegance... And you still must accept some (known) inaccuracies.

[Miguel Gutiérrez Páez]

Is there any way to check if stellarium did finish processing the previous request instead of inserting a 0.1 delay?

You received this message because you are subscribed to a topic in the Google Groups "Stellarium" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/stellarium/nnU9e4MR4us/unsubscribe.
To unsubscribe from this group and all its topics, send an email to stellarium+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellarium/dc6a0ad0-8e69-4737-932d-3cd23a1933bcn%40googlegroups.com.

[Georg Zotti]

Not one that I am aware of. (open source, read the code...)

The basic cycle is:

set time

compute everything

draw everything

advance time

compute everything

draw everything

advance time

compute everything

draw everything

advance time

...

and in between, interactive settings and user changes are processed.

I don't think it would work to set the time, check it in the next instruction and assume that computations with that time have already been triggered.

[Miguel Gutiérrez Páez]

Great, thanks a lot!

To view this discussion on the web visit https://groups.google.com/d/msgid/stellarium/d692cffd-dba3-4826-802a-389e384600f6n%40googlegroups.com.