Feedhold and status reports

[JimF42]

Is there a way to definitively tell that the TinyG is in a Feedhold (!) via status reports?

That is, is the only time "stat" would be 6 is when it is in a feed hold, or can it be 6 for other reasons? If I look at the "hold" status report, it seems to imply that a status of 6 could happen while running (planning, deceleration, etc.). Or, is there some other way of determining that a Feedhold (!) has been issued?

[aldenhart]

You are correct. The only time stat is 6 is during a feedhold. There are no other conditions that should return this state.

[JimF42]

Thanks for the info. Courious then, what are the "Hold" states used for? For example, Hold=2 is "feedhold planning phase" according to https://github.com/synthetos/TinyG/wiki/TinyG-Status-Codes#status-report-enumerations

[aldenhart]

You are looking at the internal states that make up the combined systems states "stat". stat is all that is usually reported, but you can get at the sub-states if you want them by configuring them in the status reports - or by just asking for them like {hold:n}, or {macs:n}

[stewartoallen]

how do you get a stat report when the system is in "hold" state. IOW, how can I know if a system was left in a "hold" state without re-issuing "~". The problem with that is if the buffer was not emptied it could start running. Either way, stat never seems to report 6/hold because hold prevents it.

[aldenhart]

You can request a status report using {sr:n}. Here are some details: https://github.com/synthetos/TinyG/wiki/TinyG-Status-Reports#json-mode-on-demand-status-reports

You can also request just the machine status using {stat:n}. The status will transition to hold as soon as the system begins the hold sequence, but before the machine has stopped. The {hold:n} status tells the exact state of the hold - it's a state machine that rapidly transitions through the hold sequence until it arrives at the stopped state (hold = 4 in master 440.20).

Given your use case I may consider changing {stat:n} (and stat:n in status reports, of course) to not transition to HOLD (stat = 6) until the stop actually occurs.

In the mean time you can definitively see if the machine has stopped in a hold by examining the {stat:n} and {hold:n} values

[stewartoallen]

I'm not certain I understand. once the machine state is in hold (6), it no longer responds to {stat:n} and {hold:n} requests. In my case, I'm using the serial port json server to access tinyg. So if I disconnect then reconnect (wss/tcp in browser), it doesn't seem possible to probe the state of the machine without issuing a (potentially dangerous) release (~). Perhaps I am missing a step or doing something wrong. But I would like to be able to recover a state in the UI without relying on prior knowledge of the previously issues commands.

thanks!