Controlling TinyG programmatically: Best practices?

I think I read somewhere on this forum that the TinyG doesn't always give a response back.

I'd be interested in knowing this too actually.

Thank you for the clearification and the helpful tips!

>What problems are you running into?

I find very difficult to figure out when TinyG has sent all the infromation it has to send. I'd like to find a non-leaking way to patiently wait until I have all the information there is to come, but not lock up waiting for something that is not coming.

Keeping track of the buffers does not work, in some cases (homing at least) it reports 28 buffers and then does the operation. Not all status reports include the stat, and stat:3 is not always the last status report sent.

But your tips have alrady been helpful, my communication routine is already simpler and better. Maybe homing and zero movement commands are indeed the only exeptions to the stat:3 rule? If so, I think I can build workarounds.

Answering my own question to share my experiences during last two days: As said, the goal is to recognize TinyG idle state, where all status variables are up to date and the machine state or position will not change anymore. The following logic seems to work for my application:

In the controlling software:
- Filter movement commands beforehand, so that commands that don't result in movement, are not sent to TinyG.
-Home one axis at a time.

In the TinyG interface setion, my communication is set up so that only full lines get processed. The line iterpretation routine logic is:

-If homing for axis q (where q is x, y or z; I don't have homing on other axis), wait for a line that has both "mpoq":0.000 and "coor":2 => handle it as a status report (update all status variables), fire ready event and return.

-If line starts with {"sr": => handle it as a status report. If it also contains "stat":3 , fire ready event. Return.

-If line starts with {"r":{"sr" , it is the response for asking a status report => Remove the wrapper, handle line as a status report, fire ready event and return

-If line starts with {"r": , it is a response for asking or setting a setting or setting group => replace all "n" (where n = 1, 2, 3 or 4) with "motor_n" to get valid field names for Microsoft JavaScriptSerializer class (and other JSON interpretes, I suppose). Handle line as a settings report (updating UI where applicable etc), fire ready event and return.

--
The issues that caused some thinking were 'no movement' commands (that send out an empty status report) and a bug(?) in homing routine: On X axis homing, the stat:3 report comes the second to last status report, not the last. Firmware is 392.65, btw.

> I need to see what you are getting back from the end of homing.

When I started to collect data for a response, I found that the bug has to do with zero backoff. Here is a log, with some comments added:

{"xzb":0}   // <=======  Zero backoff to 0
{"r":{"xzb":0.000},"f":[1,0,10,2510]}
g28.2 x0
{"r":{},"f":[1,0,9,4402]}
{"sr":{"coor":0,"dist":1,"home":0,"cycs":3}}
{"qr":28}
{"qr":27}
{"sr":{"mpox":-2.895,"stat":9,"momo":1,"macs":5,"mots":1}}
{"sr":{"mpox":-8.465,"hold":3,"mots":2}}
{"sr":{"mpox":-9.385,"hold":4}}
{"qr":27}
{"sr":{"mpox":-6.638,"hold":0,"mots":1}}
{"sr":{"mpox":-0.929,"hold":3,"mots":2}}
{"sr":{"mpox":-0.109,"hold":4}}
{"sr":{"mpox":0.000,"stat":3,"coor":2,"momo":4,"dist":0,"home":1,"hold":0,"macs":3,"cycs":0,"mots":0}}
{"qr":28}  // <=== Homing ended cleanly with "stat":3 and "all buffers free"
{"xzb":2}  // <===  Setting zero backoff to != 0
{"r":{"xzb":2.000},"f":[1,0,10,5205]}
g28.2 x0
{"r":{},"f":[1,0,9,4402]}
{"sr":{"coor":0,"dist":1,"home":0,"cycs":3}}
{"qr":28}
{"qr":27}
{"sr":{"mpox":-2.747,"stat":9,"momo":1,"macs":5,"mots":1}}
{"sr":{"mpox":-8.415,"hold":3,"mots":2}}
{"sr":{"mpox":-9.235,"hold":4}}
{"qr":27}
{"sr":{"mpox":-6.340,"hold":0,"mots":1}}
{"sr":{"mpox":-0.779,"hold":3,"mots":2}}
{"sr":{"mpox":0.041,"hold":4}}
{"qr":27}
{"sr":{"mpox":1.778,"hold":0,"mots":1}}
{"sr":{"mpox":2.041,"stat":3,"macs":3,"mots":0}}  <=== and the "stat":3 comes one message early. A bug?
{"qr":28}
{"sr":{"mpox":0.000,"coor":2,"momo":4,"dist":0,"home":1,"cycs":0}}
{"qr":28}

> I also want to see what behavior should occur if a non-drawable line is received.

Another log:

g0 x1
{"r":{},"f":[1,0,6,4399]}
{"sr":{"mpox":0.001,"stat":5,"macs":5,"cycs":1,"mots":1}}
{"qr":27}
{"sr":{"mpox":0.998}}
{"sr":{"mpox":1.000,"stat":3,"macs":3,"cycs":0,"mots":0}}
{"qr":28}
g0 x1
{"r":{},"f":[1,0,5,4398]}

Here, it would be cleaner if there would have been a response {"sr":{"mpox":1.000,"stat":3, ... even though the second g0 x1 is an empty command in real life.

Please note, that the bug (if it is a bug; I have misunderstood things earlier! :) ) or the missing status report are no problems at all. The logic above seems to work by today's experiments, my code works just fine. And now when the behaviour is on the forum, others will not lock their code for waiting for "stat":3 that will never come or have their machine one location message off after homing either. :)

Yes, I do multithread also. :) But I am also doing optical alignment, and for that to work, I need to be sure the machine is not moving and the position information is updated before taking a look.