View Issue Details

IDProjectCategoryView StatusLast Update
0001751SkyChart1-Softwarepublic18-10-03 10:03
ReporterRolf StegelmannAssigned ToPatrick Chevalley 
PrioritynormalSeverityminorReproducibilityalways
Status assignedResolutionopen 
PlatformMacOSOS-XOS Version10.8.5
Product Version4.0 
Target Version4.4Fixed in Version 
Summary0001751: problems using server commands
Descriptionskychart version: 4.0-3575 2017/03/19 04:30:39

I want to interface with skychart "server commands". I tried first just using telnet so that I could see what kind of output is expected. Then I implemented some code in objective-c to interface via a socket connection to skychart.

It connected just fine, but both the telnet session and objective-c code got a response and then proceeded do get a bunch of dots. The longer one waits the more the dots. Here is the output:

resultMessage __NSCFString * @"OK! id=1 chart=Chart_1\r\n.\r\n.\r\n.\r\n.\r\n.\r\n.\r\n.\r\n.\r\n.\r\n.\r\n.\r\n.\r\n.\r\n.\r\n.\r\n.\r\n.\r\n.\r\n.\r\n.\r\n.\r\n.\r\n.\r\n.\r\n.\r\n"

That's from the xcode debug output just looking at the results packet that came back from skychart. What is all that ".\r\n" for? I know its a dot, carriage return and line feed. But why keep generating them. There are a lot, since I was stepping through code via the debugger and they kept accumulating.

The other issue is that there are commands that either I don't understand how they work or are broken. I have just tried a few from telnet and the objective-c code. For examples ZOOM- does nothing but return "OK!" I don't see anything happening on the screen. The command CONNECTINDI just returns and OK but it is embedded in this output string:

resultMessage __NSCFString * @".\r\n.\r\n.\r\n.\r\nOK!\r\n.\r\n"

I was stepping it through via the debugger and it already filled part of the buffer with .\r\n and the OK! ended up in the middle of the returned packet.

The CONNECTINDI returned OK! but it did not do anything.

I can go through the other commands, but I think there is probably some generic problem, so the attempt would be futile. Better to wait for some fixes for the basic commands first.

The commands where sent from a different computer on the network. It was not a localhost connection.

Thanks

 

Steps To Reproducesimplest way is to just connect via telnet and issue the commands to see what happens. Notice a new ".\r\n" line about every 5 seconds.
TagsNo tags attached.

Activities

Rolf Stegelmann

17-07-28 20:52

reporter   ~0003944

Some commands seem to work:

Search M51

resultMessage __NSCFString * @".\r\n>\tChart_1 :\t 13h30m35.71s\t+47°06'40.9\"\t Gx\tM 51\tm: 9.26\tId:NGC 5194 \tsbr:22.90\tDim: 13.7 x 11.7 '\tpa:157\tclass:SABb \tOther name:2MASX J13295269+4711429,IRAS 13277+4727,MCG +08-25-012,PGC 047404,UGC 08493,Whirlpool Galaxy \tV-Mag:8.36\tJ-Mag:6.4\tH-Mag:5.65\tK-Mag:5.5\tCstar U-Ma:0.0\tCStar B-Ma:0.0\tCStar V-Ma:0.0\t\r\nOK!\r\n.\r\n"

The OK! is at the end??

PLANETINFO command does open the planet window.

Any command to slew to an object? I don't find one. There is SLEW to RA DEC. So one has to SEARCH for an object first. Parse the returned RA DEC values that are in Hexigesimal format and convert to decimal format for the slew command, I guess? Am I missing something?

The SLEW does work, but I made sure I was connected to the telescope first. I thought the CONNECTINDI or CONNECTTELESCOPE would do that for me? Am I using it wrong?

Patrick Chevalley

17-07-29 17:20

administrator   ~0003945

Last edited: 17-07-29 17:21

View 2 revisions

The .\r\n are send about every 5 seconds by CDC to check if the client is still alive. If the send operation failed then the client is considered as disconnected and the session is closed.
This is to handle the case when the client crash or do not send a QUIT command for some reason. Otherwise all the ten available slot will be filled quickly and no more connection can be done.
Your client code must just read and ignore this dots.
In all my clients code I alway purge the receive buffer with a read without timeout to delete any remaining data from a previous command or from this dots.

Most of the command that change the chart drawing do not make the action visible immediately, you have to send the REDRAW command after all the action. This is to avoid performance problem if you have a lot of command to send to change the chart. So after ZOOM- you must send REDRAW to see the change.

The OK! is at the end of the message send by SEARCH to indicate the end of the message.

If you send a SLEW after a SEARCH you not need to add the ra,dec parameters.

I suggest you take a look at the available examples.
I not have objective-C example but the Java and Python code can give some idea.
https://sourceforge.net/p/skychart/code/HEAD/tree/trunk/skychart/sample_client/

About the CONNECTINDI and PLANETINFO error, this is a bug specific to OS X, it look like the way I simulate the button press by code work only on Windows and Linux. I try to correct that for next version.

Rolf Stegelmann

17-07-29 18:50

reporter   ~0003948

Thank you for the explanation. That helps a lot. Looking at examples does not necessarily tell one, for example, why the .\r\n are thrown away. and it did not sink in to my brain. Now I understand the logic and the reason of why it is done this way.
I did not even look at the redraw command. It probably would help to have some a simple explanation of the basic protocol in the documentation. I will make the changes to my code to see if this works.

Okay SEARCH followed with SLEW takes the last coordinates that were set to slew to. Got it!

Rolf Stegelmann

17-07-30 02:31

reporter   ~0003950

skychart: 4.1-svn-3627 2017/07/10 10:58:12

I coded the changes based on your information. But the SLEW command with no coordinates does not actually slew the telescope even though I am connected. It shows the FOV indicator for the telescope that it moved in sky view but the actual telescope does not move. It is connected. I tried from a telnet session, it did the same thing. The SLEW command does come back with OK! Earlier I did try the SLEW with decimal coordinates in telnet and that did SLEW the telescope.

here is the Objective C version of the code. It follows the python example.

            //now send the command
            NSString * response = [self cdccmd:[NSString stringWithFormat:@"SEARCH %@", theObject]];
            DebugLog(@"Find Object Result: %@",response);

            if ([response containsString:@"OK!"]) {
                // good found object
                //start the slew to the object and track on the screen
                [self cdccmd:@"SLEW"];
                [self cdccmd:@"TRACKTELESCOPE ON"];
                [self cdccmd:@"REDRAW"];
                return YES;
            }

the printout of results:

1: cdc cmd: SEARCH m51 resp: Chart_1 : 13h30m35.68s +47°06'40.9" Gx M 51 m: 9.26 Id:NGC 5194 sbr:22.90 Dim: 13.7 x 11.7 ' pa:158 class:SABb Identifier:2MASX J13295269+4711429,IRAS 13277+4727,MCG +08-25-012,PGC 047404,UGC 08493 Common nam:Whirlpool Galaxy Const:CVn V-Mag:8.36 J-Mag:6.4 H-Mag:5.65 K-Mag:5.5 Cstar U-Ma:0.0 CStar B-Ma:0.0 CStar V-Ma:0.0
OK!

2: cdc cmd: SLEW resp: OK!

3: cdc cmd: TRACKTELESCOPE ON resp: OK!

4: cdc cmd: REDRAW resp: OK!

Ahh! is see that the INDI server protocol is still getting a "Bad INDI message"
You want me to put that in 1741, or just report here: badINDI2.png
Want me to do a protocol trace on that again?

badINDI2.png (42,888 bytes)
badINDI2.png (42,888 bytes)

Rolf Stegelmann

17-07-30 02:38

reporter   ~0003951

Also note the RA field in the connect window is actually too small. The high digit is actually a 12 not a 2.

Issue History

Date Modified Username Field Change
17-07-28 01:46 Rolf Stegelmann New Issue
17-07-28 20:52 Rolf Stegelmann Note Added: 0003944
17-07-29 17:20 Patrick Chevalley Assigned To => Patrick Chevalley
17-07-29 17:20 Patrick Chevalley Status new => assigned
17-07-29 17:20 Patrick Chevalley Target Version => 4.2
17-07-29 17:20 Patrick Chevalley Note Added: 0003945
17-07-29 17:21 Patrick Chevalley Note Edited: 0003945 View Revisions
17-07-29 18:50 Rolf Stegelmann Note Added: 0003948
17-07-30 02:31 Rolf Stegelmann File Added: badINDI2.png
17-07-30 02:31 Rolf Stegelmann Note Added: 0003950
17-07-30 02:38 Rolf Stegelmann Note Added: 0003951
18-10-03 10:03 Patrick Chevalley Target Version 4.2 => 4.4