fascinating feed rate override error

It is not a bug!
If yo use code for remap, you should know what it is doing.
You can change the remap code to fit your needs.

IMHO it is bad style not to set speed, feed and G43 and cooling after a tool change.

Norbert

bad form or not .. changing feed modes after a tool change is unexpected behavior.
I wonder if it is easy to check the current g codes in the remap and then restore them?

Chris M

Hallo Cris,

you are right, but the user uses a remap part, within that one G0 is used, so the behavior is correct.

He should change the remap code to fit his needs.
It is definitely not a gmoccapy problem.

Norbert

Thank you guys.

As you noticed the problem is in the G code and the post-processor seems to be one problem.

Thank you for your support

cmorley wrote: bad form or not .. changing feed modes after a tool change is unexpected behavior.
I wonder if it is easy to check the current g codes in the remap and then restore them?

i see there's a #<_motion_mode> system var. unfortunately it is read-only. one could use a null move to change the motion mode on exit like:


but i'm not sure if a trick like this is possible for all modes in modal group 1:
G0, G1, G2, G3, G33, G38.x, G73, G76, G80, G81, G82, G83, G84, G85, G86, G87, G88, G89