Hello Guest it is April 24, 2024, 08:50:22 AM

Author Topic: macro problem  (Read 1885 times)

0 Members and 1 Guest are viewing this topic.

Offline Bill_O

*
  •  563 563
    • View Profile
Re: macro problem
« Reply #10 on: March 06, 2019, 12:25:37 PM »
Craig,

I will fix the M22 and make it M220.
I thought I looked at which Mcodes could be scripted and that was I thought in that group.
I was just using the button script to call M22.
Because you told me in the other thread on here that the code is sometimes different I will stop trying to use that for testing and just type in the MDI to test the M220 macro.

Thanks again,

Bill
Re: macro problem
« Reply #11 on: March 06, 2019, 12:42:19 PM »
Hi,
you need to get into the habit of calling macros by their lowercase names, m220() not M220().
It will throw up errors from time to time which can be very hard to understand.

In Mach3 all M codes above M100 were considered user codes whereas any below that number were
reserved for Mach. I suspect m22() would work (in Mach4) but my preference is name it in such a manner that
there is no ambiguity.

Quote
Because you told me in the other thread on here that the code is sometimes different I will stop trying to use that for testing and just type in the MDI to test the M220 macro.

It not so much that the code is different but rather it is in two different locations. As Mach runs it is going from the GUI
chunk to the GCode interpreter chunk and back again all the time. What I have suggested is that if you want some particular
machine behavior that is the same in both chunks then code it in two places. With such simple code this is easy. If
the code were complex it would be best placed in a module. The module could then be accessed by either the GUI OR
the GCode interpreter but the code would not have to be repeated in both chunks.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'