Hello,
I'm developping an apps, and communicating through COM port to use TinyG. Generally it works fine, but sometime, I do received wrong formatted JSON report from the board.
I use all the correct communication artifacts to be sure the dialog goes well (available buffers in TinyG, CTS,RTS...).
I used an external COM port sniffer to check that the issues wasn't from my code, and here is the result :
{"r":{ "c":{"am":0,"vm":3600,"fr":3600, "tm":-1,"jm":20000000,"jd":0,"ra ":1.000},"f":[1,0,9,6752]}}
{"r ":{"sys":{"fb":380.05,"fv":0.960 ,"hv":8,"id":"9H3583-PXN","ja":2 {"r":{"fb":380.05,"fv":0.960,"hv ":8,"id":"9H3583-PXN","msg":"SYS TEM READY","f":[1,0,0,2080]}}
{ "qr":28}
As you see the second report is not correct.
Am I the only one having issues ??
Looks like your response is being stepped on. The second "r" appears in the middle of the report. Can you try to send to coolterm using XON/XOFF protocol? We have not seen this error before.
Also, you have spaces in all responses that should not be there. What are you reading this with?
Can you tell me what build you are running, what commands (requests) you sent, and if there was any time delay between the requests. Thanks.
Hi alden, thanks for the answer.
The space in the response is simply a format issue. I'm using Free Serial Port Monitor (not the best software...) and the output format adds a lot of spaces and CR\NL. When removing them, space appeared. I do not have them in the communication.
Firmware parameters are :
"sys":{"fb":380.05,"fv":0.96}
The board is a TinyG v7.
I'll reproduce the issue and give you the exact commands.
I cannot tell you if there is any delay, because it appears while sending a file, and I notice this while reading the log after finishing.
I'll also try with cooltermright now.
Ok here is an example of a really simple issue. Sending an homing command on X and Y. The issue is on the last line.
{"r":{"gc":"G28.2X0Y0","f":[1,0,12,2883]}}
{"sr":{"coor":0,"dist":1}}
{"qr":28}
{"qr":27}
{"sr":{"posx":223.489,"vel":147.00,"stat":9}}
{"sr":{"posx":223.852,"vel":588.00}}
{"sr":{"posx":224.345,"vel":600.00}}
{"sr":{"posx":224.845}}
{"sr":{"posx":225.295}}
{"sr":{"posx":225.794}}
{"sr":{"posx":226.294}}
{"sr":{"posx":226.794}}
{"sr":{"posx":227.237,"vel":453.00}}
{"sr":{"posx":227.385,"vel":12.00}}
{"sr"{"sr":{"vel":0.00,"stat":3}}
$si parameter is at 50 ms.
Below are the several issues I had after playing with it for a couple of minutes. Mainly emulating jog command (G0X-1000 and then stopping and flushing with !%)
{"sr"{"sr":{"vel":0.00,"stat":3}}
{"sr{"sr":{"vel":0.00,"stat":3}}
{"sr"{"sr":{"vel":0.00,"stat":3}}
{"sr":{{"sr":{"vel":0.00,"stat":3}}
{"r":{"sys":{"fb":380.05,"fv":0.960,"hv":8,"id":"9H3583-PXN","ja":2540000,"ct":0.0254,"st":1,"mt":180,"ej":1,"{"sr":{"stat":3}}
Strangely, it seems to always be at the same command. Always a status report, with null/zero velocity.
It might be my code, but I don't really know where to look.
I cannot reproduce it with Coolterm. It looks like I'm sending data incorrectly, but it's not 100% reproductible...
It looks like it happen on very short jog operation or, when stopping close to the generation of a new status report. Below is a copy of my capturing software : (double dot are actually CR and LF)
Requête:03/01/2014 00:33:26.84964 (+7.8780 seconds)
G1X-1000.0F150.
Réponse:03/01/2014 00:33:26.91164 (+0.0156 seconds)
{"r":{"gc":"G1X-1000.0F150","f":[1,0,15,4488]}}..{"sr":{"posx":-17.581,"vel":0.28,"stat":5}}..{"qr":27}..{"sr":{"posx":-17.774,"vel":125.14}}..
Requête:03/01/2014 00:33:26.33464 (+0.1716 seconds)
!%.
Réponse:03/01/2014 00:33:27.64664 (+0.3120 seconds)
{"sr":{"posx":-18.677,"vel":4.41,"stat":6}}..{"sr"{"sr":{"vel":0.00,"stat":3}}..
This really looks like a serial buffer problem. What flow control are you using? With Coolterm I recommend using XON/XOFF. Make sure both the board and Coolterm are set up for XON/XOFF.
Can you send me your status report setup line and parameters? Or are you using the default status report?
Are you doing anything to cause the SYS report? - like asking for {"sys":""}, or is this just showing up "on its own"?
I'll try to reproduce once I have the data.
Alden,
Yes I'm using XON/XOFF. I already had issues before and manage to fix the issue. I already managed to send 40k line GCode file with no problem (but still having the SR issue. Since they're only information, it's not critical). If I'm the only one having the issue, it's probably something wrong in my code, but I'd like to understand what.
When connecting, I'm requesting all the parameters to initialize my application internal state. So I call :
{"sr":""}
{"1":""}
{"2":""}
{"3":""}
{"4":""}
{"x":""}
{"y":""}
{"z":""}
{"a":""}
{"b":""}
{"c":""}
{"sys":""}
But for some reason I don't understand the last line is not complete. I randomly stop in the middle of the line. The total received byte usually is between 1300 and 1400.
My serial port creation (using rxtx in java) is like :
serialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT | SerialPort.FLOWCONTROL_XONXOFF_IN | SerialPort.FLOWCONTROL_XONXOFF_OUT );
serialPort.setRTS(true);
I already had a hard time to determine that the setRTS(true) was required.
While receiving bytes from the serial loop, I watch for Xon and Xoff character to change an internal CTS (like) flag. Maybe that's not required with the flow control configured in the serial port... Not sure but the wiki confirm.
The SR is the default filtered one...
Is there a chat we can talk on ? It could be faster if you have a bit of time.
I won't be able to chat until sometime later. Have you tried introducing a delay between the commands, or executing them synchronously - i.e. wait for one command the return before requesting the next.
Running them synchronously is what I'm working on right now...
I don't really understand how the handling of Xon and Xoff is impacting the way TinyG send me data.
By the wayI only rarely receive Xon and Xoff characters...