[Grbl_Esp32 Issue#157] Can we implement M1 command

#1 – bdring 于 2019-06-02

Please explain why you want the M1 command. How will you be using it? Is it generated by your CAM program?

#2 – mac7988 于 2019-06-05

Hi Bdring,

I want to be able to run some process and then cycle start to resume. My code has alot of m1 where there is some manual process involved.

#3 – 109JB 于 2019-06-05

In g-code a M1 is an “optional stop” which means the controller has to be set to stop on these. It works the same as a M0 stop command but M0 is not optional.

How would the ESP32 know that it should or should not stop on M1?

Will M0 work for your application?

#4 – terjeio 于 2019-06-05

Either a physical switch (requires a valuable input pin) or perhaps new realtime command(s) issued from the sender (via a button or checkbox) may be used as input to whether M1 causes a pause or not.

#5 – bdring 于 2019-06-05

Currently Grbl has a real time pause. Perhaps this could be used by M0/M1. It would need be part of modal group, so it is not real time. It would need to kick in after the previous gcode finished. G4 does this and would be a good place to start.

M6 (tool change) could probably be wrapped in at the same time, for a manual tool change opportunity.

I suggest bringing this up at the AVR Grbl repo. I would think a feature like this should be coordinated across versions, so they all react the same.

#6 – terjeio 于 2019-06-05

@bdring As I understand it M1 behaviour should be exactly the same as the current M0 implementation except it is dependent on a switch setting. I have added support for that in my HALified version of grbl, but in addition to (or an alternative to) using input from a switch it may be made dependent on a flag instead, possibly set/reset via a realtime command. IMO M6 for tool change is a different issue altogether, I have acheived that by added a new state and double buffering of the input stream – this allow jogging while in tool change state (just like on my Mach3 controlled router).

Today a I also restarted work on a “cheap” Micro ATC (for up to eight 3.175mm shaft tools), with luck I may be able to conlude that sucessfully. This requires another set of updates to the grbl core which I believe I have working now – at least all the movements are running as they should. The hard part will be completing the mechanical bits successfully…

#7 – bdring 于 2019-06-05

@mac7988 Can you change your post processor to use M0 instead on M1? I think that will get you the features you need.

@terjeio I did a Grbl based ATC years ago. I actually did the tool change in the sender by inserting extra gcode when it saw the M6, etc. I thought the same could be done inside Grbl on MCUs with more memory than 328p. It would be nice via a config.h value to allow manual tool changes, like top of Z…spindle off…move to G28.

#8 – terjeio 于 2019-06-05

@bdring I know about your ATC solution, suitable for my large router/mill – but far too big and expensive for my mini router/mill. I have manual tool change up and running in my grbl port – but it is a quite extensive rewrite so I do not know how easy it will be to backport.

Implementing M1 is IMO straightforward code wise, but not easy in practice since there are no free pins for a switch? @mac7988 did not specify which sender he is using, adding a realtime command and GUI support for that may also be problematic?

#9 – mac7988 于 2019-06-06

Hi everyone,

So maybe I can explain better. I am running 2 axis to pocket out something. Once the pocket is done. I go and insert a part in the pocket. Once done the same two axis insert adhesive in the pocket to capture the part.

I need the motion to pause until I insert the part and by hitting cycle start it would resume.

#10 – bdring 于 2019-06-06

@mac7989 I seems like you should be using M0. What CAM software are you using? Can you adjust the post processor.

#11 – terjeio 于 2019-06-06

@mac7989 you can also customize grbl if you feel so inclined, in gcode.cpp add M1 action (near line 300):

gcblock.modal.programflow = PROGRAMFLOWPAUSED;

after the case 1: statement. Or just move case 1: up a bit so that it does the same as M0…

But then perhaps M1 should be enabled as default for safety reasons?

LinuxCNC M0/M1 spec here.

#12 – mac7988 于 2019-06-06

@bdring the gcode is compiled using an Excel sheet which has some parameters. Based on some drop down selection it will adjust the code.

I can implement M0 and try it out. I will keep you posted.

#13 – 109JB 于 2019-06-06

M1 is easily handled by sending programs. Mine does it and I’m not even a good programmer.

M1 is optional and in my opinion should remain optional. If you make it function the same as M0 then it is no longer optional. Personally, I would rather it remain as an undefined command than to implement it contrary to its definition.