error at the end of a remapped m6

[dhweizel]

I just changed to master. The machine uses a m6 remap copied of the vismach sample and works ok on 2.7 and now , on master, raises an error at the end of the tool change.

emc/task/emctask.cc 397: interp_error: exception during generator call: TypeError: 'NoneType' object is not callable

exception during generator call: TypeError: 'NoneType' object is not callable

Interpreter stack: - int Interp::pycall(setup_pointer, context_pointer, const char*, const char*, in - int Interp::execute_return(setup_pointer, context_pointer, int) - int Interp::convert_control_functions(block_pointer, setup_pointer) - int Interp::_execute(const char*)
emcTaskPlanExecute((null)) returned 5

There is the same error in the vismach sample : Here are the steps I follow to reproduce the issue:

1. linuxcnc sim.axis.vismach.VMC_toolchange/vmc_index.ini
2. home all
3. t10m6

the ini file says:
REMAP=M6 modalgroup=6 prolog=change_prolog ngc=toolchange epilog=change_epilog
There is no error if I delete epilog=change_epilog

The error apears to be related to change_epilog of stdglue.py

in the line 198 : return INTERP_EXECUTE_FINISH

if I change to : return INTERP_OK it works as expected

I don't know the implications of the change but I found this return vaue used in another stdglue.py file in the master (gmoccapy)

edit: typo

[andypugh]

I don't really understand remap and/or stdglue.py but I have a feeling that INTERP_EXECUTE_FINISH is intended to cause a "synch" after a tool change, ie make sure that the readeahed queue is emptied and recalculated with new tool data.

I don't think we are seeing the line where the actual error occurs in any of the messages. But I could be wrong.

[dhweizel]

If I undertand correctly the error is related to the re execution of the epilog.
I traced back the apparition of the error to this commit of the file src/emc/rs274ngc/interp_o_word.cc

44377d8

When a python epilog returns INTERP_EXECUTE_FINISH:

• Set the executing block call type to CT_REMAP so the next read()
  skips, and
• Return control to task.

The next call to execute() will resume epilog execution.

Signed-off-by: John Morris john@zultron.com

[zultron]

@dhweizel Thanks for reporting this. I'm going to have a little trouble finding time to look at this before January, but I'll try. I'm very sorry you must have had to look at this extremely hairy part of the codebase!

[dhweizel]

@zultron Thanks for your quick response. I wish to add that Andy found that the error shows more easy if you just just open sim/remap/rack
toolchange because the preview.

The code IS very complex but the variety of different log functions amazed me

[zultron]

@dhwiezel, the error turns out to be in stdglue.py in the change_epilog() function, which was not properly written as a python generator function. You can fix the function by replacing all return INTERP_* lines with yield INTERP_*, as I did in PR #221 (which should automatically close this issue as soon as it is merged).

Thanks again for the hard work you did to track down and report this problem. That made it a lot easier to reproduce and fix.

[dhweizel]

Good news !!!
I'm glad I was able to help.