Active G-Codes List

When I'm running a program, are the list of active G-Codes on the MDI page updated? I was trying to cut using G41 cutter compensation but the list of active codes always showed G40 (comp. turned off).

After smashing the eStop on the first two passes, I single stepped through and found that the comp. was being performed properly but the MDI active code window did not reflect the mode.

Hi

Just to clarify, you are refering to the Active G / M code list on the MDI tab of Axis

You cannot take any account of the MDI tab when you are in Auto (Run) mode. It is disabled, even if not greyed out.
(Try running a MDI command during a program, no error, just nothing happens)

I can't see any obvious reason why the self.update function does not continue to update codes in the line edit box during the run,
but it certainly does not seem to.
The codes seem to be changed as per the initialisation header of the code, but once any movement starts they stop updating.

The G / M code weirdness does not stop at G40.
If you insert a G91 half way down the code and initialise with G90, the display will stay at G90 all the way through despite making incremental moves later on

It is really an aide-memoir to what codes are active when using MDI, rather than any real time display of active codes.

Most people would probably have the Manual tab uppermost when running a program anyway, so be oblivious.

regards

Thanks for the quick response. It is consistent with what I've seen.

I guess you're saying that I was better off when I was oblivious.

TMI:
I initially tried a skim cut at z=-.003 to verify my program. Unfortunately, I'd previously left the spindle at an X Y position that was very close to the starting position. I immediately got an error about not being able to reach the next position without gouging. I offset the spindle and I thought I reset the program. Upon restart, my initial cut was performed - the program completed. I reset the Z depth for the real cut but I noticed that the cutter was offset from the first run. E-Stop. When I looked at the active code list, I noticed G40 instead of G41 like I expected. I (incorrectly) assumed the second run was wrong. Repeat the process including the panicked E-Stop. Lots of single stepping before I decide that the second/third/fourth etc. runs were correct.

I have now decided that when the program was interrupted the first time, G41 went inactive and I failed to reset it. So it was the initial run that was preformed without compensation. I'm still not sure why my reset wasn't done like I expected.

There is a known issue with M2 and M30, which people routinely use to terminate programs, in that they reset everything.
It is documented, but people often do not realise the extent of it.

I don't know if using emcCommandBuffer->write(task_abort_msg);
(which is what pressing Esc will do) will have the same effect.
Might get round to testing at some point.

In ngcgui, Dewey had to write in the use of % to delimit gcode, so that all offsets etc were not cancelled at the end of each sub routine.

As with everything, check twice then watch carefully with one hand over the red button

regards

As far as I have seen and noticed and coded, gmoccapy is updating the g code list in every mode:-)

The only code i need to resolve, because of not realistic values, is the feed value shown in my info frame for active gcode. I am working on that one!

Norbert

I am pretty sure that the Qt C++ GUI I wrote did too.

I can only imagine it is something to do with the MDI tab being disabled.

I was using direct calls to emcStatus->task.activeGCodes[t]; etc, I imaging the python calls are just the same through the emcmodule wrapper

regards