Re: How to use M41-M43 - SOLVED
Posted: Sun Jan 05, 2025 3:58 pm
There are several pitfalls to watch for with this type of code.
First, if your M3 or M4 macro contains an M5 code (e.g. to stop the spindle prior to attempting a gear change), then the Search and Resume options may not recognize that the spindle should be on when they get to the search line (because the parser saw M3 or M4, then saw an M5, and so concludes that the most-recent spindle M function is M5. That can generally be avoided with the usual "skip the whole macro in search or graph" logic, as Muzzer's code has. It can also be avoided by replacing the M5 with "M95/1/2" or "M95/1/2/19".
Second, if the M3 or M4 macro proceeds with running the gear change code unconditionally (without checking to see whether the head is already in the desired gear), and if the gear change process has a dwell time or other lengthy operations, then that may cause an unexpected delay at the bottom of a G74 or G84 tapping cycle, when M3 or M4 is called to reverse the spindle. That can generally be avoided by making the code check the current range (based on inputs or memory bits), then only doing the gear shift if not already in the desired range.
Third, on a lathe control, it is possible that the target RPM is unknown. If the G code starts up the spindle in CSS mode (G96), then the given S code would be surface speed (meters/minute or feet/minute) instead of RPM. Testing #4119 would not give a meaningful answer. That issue can only be fixed in the G codes (e.g. in the postprocessor). A well-behaved lathe postprocessor should always start up the spindle in RPM mode (G97), with an RPM that is approximately correct for the start of the upcoming cut. If should only switch to G96 and call out the surface speed after the initial rapid move that brings the X axis into position for the first cut. Auto-gear-change code called from an M3 or M4 would have to either do nothing, or trigger an error, if the spindle speed mode is G96 and not G97.
First, if your M3 or M4 macro contains an M5 code (e.g. to stop the spindle prior to attempting a gear change), then the Search and Resume options may not recognize that the spindle should be on when they get to the search line (because the parser saw M3 or M4, then saw an M5, and so concludes that the most-recent spindle M function is M5. That can generally be avoided with the usual "skip the whole macro in search or graph" logic, as Muzzer's code has. It can also be avoided by replacing the M5 with "M95/1/2" or "M95/1/2/19".
Second, if the M3 or M4 macro proceeds with running the gear change code unconditionally (without checking to see whether the head is already in the desired gear), and if the gear change process has a dwell time or other lengthy operations, then that may cause an unexpected delay at the bottom of a G74 or G84 tapping cycle, when M3 or M4 is called to reverse the spindle. That can generally be avoided by making the code check the current range (based on inputs or memory bits), then only doing the gear shift if not already in the desired range.
Third, on a lathe control, it is possible that the target RPM is unknown. If the G code starts up the spindle in CSS mode (G96), then the given S code would be surface speed (meters/minute or feet/minute) instead of RPM. Testing #4119 would not give a meaningful answer. That issue can only be fixed in the G codes (e.g. in the postprocessor). A well-behaved lathe postprocessor should always start up the spindle in RPM mode (G97), with an RPM that is approximately correct for the start of the upcoming cut. If should only switch to G96 and call out the surface speed after the initial rapid move that brings the X axis into position for the first cut. Auto-gear-change code called from an M3 or M4 would have to either do nothing, or trigger an error, if the spindle speed mode is G96 and not G97.