Mcode out of range, greater than 199 error
- Aciera
- Offline
- Administrator
Less
More
- Posts: 4034
- Thank you received: 1741
04 Jan 2025 16:07 #318095
by Aciera
Yes, that is the expected behavior.
Replied by Aciera on topic Mcode out of range, greater than 199 error
The error only occurs when I don't remap m-codes higher than 199. If you don't remap, then LCNC's standard user m-code range is 100-199, using capital "M" and no file extension.
Yes, that is the expected behavior.
Please Log in or Create an account to join the conversation.
- Lcvette
- Topic Author
- Offline
- Platinum Member
Less
More
- Posts: 1246
- Thank you received: 634
04 Jan 2025 16:15 #318098
by Lcvette
Replied by Lcvette on topic Mcode out of range, greater than 199 error
would it be better to use 100-199 for the switchkins to avoid the possible conflict?
Please Log in or Create an account to join the conversation.
- Lcvette
- Topic Author
- Offline
- Platinum Member
Less
More
- Posts: 1246
- Thank you received: 634
04 Jan 2025 16:19 #318100
by Lcvette
Replied by Lcvette on topic Mcode out of range, greater than 199 error
its been a while since i tested this, and i currently have a large project pulled that i don't want to exist until finished as we are preparing a release for qtpyvcp and probe basic.
based on spumco's response above does this mean that a remap for 200+ mcodes is required? i think spumco is running probe basic also if memory serves so his experience should be the same as the pb sim.
based on spumco's response above does this mean that a remap for 200+ mcodes is required? i think spumco is running probe basic also if memory serves so his experience should be the same as the pb sim.
Please Log in or Create an account to join the conversation.
- Aciera
- Offline
- Administrator
Less
More
- Posts: 4034
- Thank you received: 1741
04 Jan 2025 16:53 - 05 Jan 2025 10:25 #318104
by Aciera
Replied by Aciera on topic Mcode out of range, greater than 199 error
M100 .. M199 are User Defined Commands and can be any executable script. These need to be located in the path set in [RS274NGC]USER_M_PATH in the ini file. These do not need a remap.
M200...M999 are gcode or python files and need to be located in the [RS274NGC]SUBROUTINE_PATH and these DO need to be listed as remap.
[edit]
The error message comes from here
github.com/LinuxCNC/linuxcnc/blob/master...interp_read.cc#L1122
If the mcode in the gcode is not found in the list of remapped mcodes and is above 199 then you get the error.
M200...M999 are gcode or python files and need to be located in the [RS274NGC]SUBROUTINE_PATH and these DO need to be listed as remap.
[edit]
The error message comes from here
github.com/LinuxCNC/linuxcnc/blob/master...interp_read.cc#L1122
If the mcode in the gcode is not found in the list of remapped mcodes and is above 199 then you get the error.
Last edit: 05 Jan 2025 10:25 by Aciera.
The following user(s) said Thank You: spumco
Please Log in or Create an account to join the conversation.
- spumco
- Offline
- Platinum Member
Less
More
- Posts: 1840
- Thank you received: 745
05 Jan 2025 02:09 #318144
by spumco
I'm running PB on my mill, and will use PB on the lathe when it's mechanically done.
My suggestion is to use remap for everything when you have a bunch of custom M-codes. In fact, I may change my M100-M103 to m100.ngc remaps.
Reason being is that if you have some m-codes as User Defined Commands, and some as remaps... they're going to be in different folders and 'look' different to anyone poking around in the folders or trying to edit them.
I think for clarity it'd be better to have everything in one place, in the same basic format. And once you've got the remap for one m-code, it's easy enough to paste a bunch more in the INI file.
Using remaps also lets you organize the m-code numbers somewhat logically without running out of headroom. In my case, since I've got about 3 different 'mist' functions and 3 or 4 different pneumatic cyls/grippers planned, I could use M700-M702 for the mist, and maybe M900-M904 for the automation stuff.
You could also number all the Probe Basic probing routines as M200-Mnn instead of the long text names.
If your list gets long enough, you can also put a "MCODES.txt" file in the subroutines folder with a (hopefully current) list of what they all do.
Replied by spumco on topic Mcode out of range, greater than 199 error
Lcvette -its been a while since i tested this, and i currently have a large project pulled that i don't want to exist until finished as we are preparing a release for qtpyvcp and probe basic.
based on spumco's response above does this mean that a remap for 200+ mcodes is required? i think spumco is running probe basic also if memory serves so his experience should be the same as the pb sim.
I'm running PB on my mill, and will use PB on the lathe when it's mechanically done.
My suggestion is to use remap for everything when you have a bunch of custom M-codes. In fact, I may change my M100-M103 to m100.ngc remaps.
Reason being is that if you have some m-codes as User Defined Commands, and some as remaps... they're going to be in different folders and 'look' different to anyone poking around in the folders or trying to edit them.
I think for clarity it'd be better to have everything in one place, in the same basic format. And once you've got the remap for one m-code, it's easy enough to paste a bunch more in the INI file.
Using remaps also lets you organize the m-code numbers somewhat logically without running out of headroom. In my case, since I've got about 3 different 'mist' functions and 3 or 4 different pneumatic cyls/grippers planned, I could use M700-M702 for the mist, and maybe M900-M904 for the automation stuff.
You could also number all the Probe Basic probing routines as M200-Mnn instead of the long text names.
If your list gets long enough, you can also put a "MCODES.txt" file in the subroutines folder with a (hopefully current) list of what they all do.
Please Log in or Create an account to join the conversation.
Time to create page: 0.155 seconds