How to get M-Code Status in HAL

Hello! I really want to know is there any way to get the status of modal commands, like M5, G21, G40,M9 and so forth. I would like to replace Gcode panel with LED one, which would show only necessary parameters. Is it possible?

Yes and no.
You can use python to read the M and g codes and use that data for what ever you want. GladeVCP would be a good choice for this.

But unfortunately it reads the state of the interpreter which can be far ahead of the actual running gcode.

There has been effort to fix this problem (a branch called state-tags) but it is relatively far away from being incorporated.

Chris M

In other words yes there is supposed to be a way, but no you can't really use it for anything useful because it is currently broken (and has been since the introduction of the new tool planner.)

actually the new trajectory planer didn't break this, it always been this way.

Chris M

With the old planner I thought it was only 1 line ahead rather than all the way to the end.

cmorley wrote: There has been effort to fix this problem (a branch called state-tags) but it is relatively far away from being incorporated.

I know I shouldn't complain as we are all volunteers but I find it frustrating when valuable branches like this and reverse run seem to get right through ready to be merged into master branch but then languish in limbo for such a long time (sometimes 3 years or more) that the code base moves so far ahead of them they become broken and its a major work to merge them. The original author is not likely to be motivated to redo his work after his first experience.

Todd Zuercher wrote: With the old planner I thought it was only 1 line ahead rather than all the way to the end.

yes that is true. but either way the interpreter makes a large list of commands it has pre-planned - faster then the machine can run them usually.

Trajectory planning look-head describes the amount of lines ahead (usually ahead of the currently running line) it considers when planning. It improves quality of movement of course.

The Interpreter list is just a place for the planner to keep those pre-planned moves.

Chris M

rodw wrote:

cmorley wrote: There has been effort to fix this problem (a branch called state-tags) but it is relatively far away from being incorporated.

I know I shouldn't complain as we are all volunteers but I find it frustrating when valuable branches like this and reverse run seem to get right through ready to be merged into master branch but then languish in limbo for such a long time (sometimes 3 years or more) that the code base moves so far ahead of them they become broken and its a major work to merge them. The original author is not likely to be motivated to redo his work after his first experience.

Yes it's an on going problem (and a underlying reason why machinekit was forked).
I believe it's a combination of things (my off the cuff opinion):
because of a lack of people to do merging.
The maybe-too-restrictive of keeping master basically usable as production on a machine at all times.
Not pushing master out more regularly.

Which really comes down to the first reason

Chris M

Sorry Guys,

but you are getting off topic! The merge etc does not belong to gmoccapy!!
But you are right and wrong! If you are interested in thre merge of a branch, test it!!! And report about the results, so it will be merged! Do not shout on developers if you do not participate.

You are right in the meaning of master, Imho we shouild have three main branches, stable, master and development.

Pardon for the open words.

Norbert