Hitting spindle CW and CCW buttons don't call M3, M4, M5

[A_Camera]

Not sure if this is a bug or a feature, but I regard this being a bug.

When I hit the spindle start buttons CW and CCW in Run screen I expect the M3, M4 and M5 macros to be called, depending on button state. This is not happening, unless I made a mistake somewhere in the configuration of UCCNC. The spindle start relay is activated if I have defined one, but the macros are not called, so the spindle will not start unless it is controlled by the relay. It seems that the DospinCW() DospinCCW() and Stopspin() are executed internally only, not through the macros, which makes it difficult to control the spindle if Modbus is used because it demands a macro loop and continuous button state checking. This is not very convenient and it adds to the load on UCCNC without any real purpose, other than controlling the on/of of the spindle. That task is better done through the M3, M4 and M5 macros.

Could this be added to the list of bugs to be fixed? Or am I doing something wrong, or is there a reason not to call those M macros from the buttons?

[ger21]

I'm sure it's the intended behavior. But maybe not the best behavior?
Lots of buttons seem to call internal functions.
I think that what may have made sense when UCCNC was origianlly designed, now shows some weaknesses, regarding some of these buttons with internal functions.

A simple workaround for your issue is to duplicate your M3 macro. Call it M20001.txt
Then just edit the CW button to button #20001.

[cncdrive]

Yes, I confirm that this works exactly how mentioned is that the M3,M4,M5,M7,M8,M9, those buttons call the internal Spin functions when pressed on the screen.
This was made this way in the very beginning when the software was not so flexible, there was no screen designer, no changeable screen etc.
and was never changed afterwards. But I see the issue with this and it was already noted that this has to be changed.

Gerry, I think only the mentioned buttons call internal functions, no others, but I will check it again as soon as I will change these to always call the macro,
will create an exception in the internal Spin functions to simply do not Dwell when called from the screen buttons.

And yes, a quick workaround is what Gerry mentioned is to replace those button codes and call your own macro numbers with the spin functions inside,
the only downside will be that then the button calls will also Dwell which I don't like and that is what I want to change...

[A_Camera]

Yes, I confirm that this works exactly how mentioned is that the M3,M4,M5,M7,M8,M9, those buttons call the internal Spin functions when pressed on the screen.
This was made this way in the very beginning when the software was not so flexible, there was no screen designer, no changeable screen etc.
and was never changed afterwards. But I see the issue with this and it was already noted that this has to be changed.

Once again, thank you very much. Hopefully this is easier to fix than the cutter compensation, but of course, all depends on how modular you programmed.

Gerry, I think only the mentioned buttons call internal functions, no others, but I will check it again as soon as I will change these to always call the macro,
will create an exception in the internal Spin functions to simply do not Dwell when called from the screen buttons.

And yes, a quick workaround is what Gerry mentioned is to replace those button codes and call your own macro numbers with the spin functions inside,
the only downside will be that then the button calls will also Dwell which I don't like and that is what I want to change...

Yes, if it is possible to change the button calls, but another possibility is to simply monitor the buttons in a macro loop and call M3 and M4 and M5 when a change is detected. I definitely don't want dwell since I monitor VFD parameters which will tell UCCNC when the speed is up and to continue with the rest of the G-codes. I don't use any other delay than what is needed by the VFD and that is variable, depending on the spindle speed, since it takes longer to accelerate from zero to 24krpm than to 6krpm. I have already modified the M3 M4 and M5 macros to handle that.

[cncdrive]

Once again, thank you very much. Hopefully this is easier to fix than the cutter compensation, but of course, all depends on how modular you programmed.

No problem. Yes, probably this can be done much faster.
The cutter compensation is not a fix you know, it is imply not implemented yet and implementing it means that we have to create new algorithms.
It is hard to tell an ETA on that one, because creating new things can involve new problems to arrise which we may not think about when starting to make them.
The button calls issue is different, because it is only a change in the current code/algorithm and no need to create new things.
And however I already started making the cutter comp algorithm, but I think I already described in another thread here that the algorithm yet works perfect only with lines,
with arcs there is still things to do to make it work always properly and that will sure take time, because the algorithm is pretty complex.

Yes, if it is possible to change the button calls, but another possibility is to simply monitor the buttons in a macro loop and call M3 and M4 and M5 when a change is detected. I definitely don't want dwell since I monitor VFD parameters which will tell UCCNC when the speed is up and to continue with the rest of the G-codes. I don't use any other delay than what is needed by the VFD and that is variable, depending on the spindle speed, since it takes longer to accelerate from zero to 24krpm than to 6krpm. I have already modified the M3 M4 and M5 macros to handle that.

Yes, using a loop and polling the button presses is also a way of handling them.
And sure, I also don't like the dwell on button press and this is the "to be solved" task in this, but I think we can probably easily handle this as an exception, I will look into it more deep a bit later.

[A_Camera]

Once again, thank you very much. Hopefully this is easier to fix than the cutter compensation, but of course, all depends on how modular you programmed.

No problem. Yes, probably this can be done much faster.
The cutter compensation is not a fix you know, it is imply not implemented yet and implementing it means that we have to create new algorithms.
It is hard to tell an ETA on that one, because creating new things can involve new problems to arrise which we may not think about when starting to make them.
The button calls issue is different, because it is only a change in the current code/algorithm and no need to create new things.
And however I already started making the cutter comp algorithm, but I think I already described in another thread here that the algorithm yet works perfect only with lines,
with arcs there is still things to do to make it work always properly and that will sure take time, because the algorithm is pretty complex.

Yes, if it is possible to change the button calls, but another possibility is to simply monitor the buttons in a macro loop and call M3 and M4 and M5 when a change is detected. I definitely don't want dwell since I monitor VFD parameters which will tell UCCNC when the speed is up and to continue with the rest of the G-codes. I don't use any other delay than what is needed by the VFD and that is variable, depending on the spindle speed, since it takes longer to accelerate from zero to 24krpm than to 6krpm. I have already modified the M3 M4 and M5 macros to handle that.

Yes, using a loop and polling the button presses is also a way of handling them.
And sure, I also don't like the dwell on button press and this is the "to be solved" task in this, but I think we can probably easily handle this as an exception, I will look into it more deep a bit later.

Thank you for the quick answer. Also, please look at the Reset button handling as well. It does not call M5, which I think it should. Again, it resets the spindle relay but unless the spindle is controlled with that relay, like I am controlling mine via Modbus, the spindle is not stopped when Reset is pushed. In my opinion, it should be stopped also when pressing Cycle Stop, but that does also nothing.

In fact, it seems that no action, which normally MUST stop the spindle does actually stop it. E-Stop, hard limits or any other stop command just ignores M5 and only reset the spindle relay if such relay is defined in the configuration, so as it is now, it is pretty dangerous to use it with Modbus in my opinion. I think you should put out a warning about this because it is pretty nasty to see the spindle continuing to spin when you expect it to be stopped. As it is now, only spindles controlled by the spindle relay are stopped.

[ger21]

I think that you are running into issues that Terry alluded to earlier, with the way that you are controlling your spindle.

You are also making the assumption that everyone else thinks it should work the same way that you want it to.
I don't necessarily think that Stop should call M5 or stop the spindle. In Mach3, you have the option for it to do that. My guess is that there were differing opinions on how things should work.

[A_Camera]

I think that you are running into issues that Terry alluded to earlier, with the way that you are controlling your spindle.

You are also making the assumption that everyone else thinks it should work the same way that you want it to.
I don't necessarily think that Stop should call M5 or stop the spindle. In Mach3, you have the option for it to do that. My guess is that there were differing opinions on how things should work.

Fine, but that behaviour should be known in that case, and most of all, it should be consistent. If the Spindle relay is reset when you hit stop then it should stop the spindle, don't you think so? Consistent behaviour is important.

[Robertspark]

Please don't change the compiled M3, M4 and M5 macro codes, there really is no point and you are wasting time and effort for little to no gain.

The problem is I believe that the modbus plugin, macros and macroloops are not being understood and how they inter relate

I posted something a little while ago on cnczone under the uccnc + modbus thread... it may be worth a read..
There are about three threads discussing the same thing at the same time

[cncdrive]

"In fact, it seems that no action, which normally MUST stop the spindle does actually stop it. E-Stop, hard limits or any other stop command just ignores M5 and only reset the spindle relay if such relay is defined in the configuration, so as it is now, it is pretty dangerous to use it with Modbus in my opinion. I think you should put out a warning about this because it is pretty nasty to see the spindle continuing to spin when you expect it to be stopped. As it is now, only spindles controlled by the spindle relay are stopped.

Stop and Reset and hardlimit etc. actions all stop the spindle also accidental disconnection of the motion controller stops the spindle.
The stop is done with the spindle relay off and the PWM set to it's defined inactive state or the step signal to zero frequency depending on how the spindle is configured.
The spindle signals are special kind of signals in the software (we call them hardware signals, because they are controlled directly by the motion controller with highest priority), the motion controller handles these in a special way where if a stop is requested or anything problematic happens then the configured inactive states of these signals are output by the motion controller to make sure the spindle will stop.
With modbus the software has no idea which register and what value of that register will stop your spindle, there is no configuration for that, you could freely code that many different ways for different hardwares.
Also I'm not sure how safe is that to leave the spindle stop on a modbus or any kind of serial communication, I would probably not do that and instead would use the relay signals,
because however they still depends on software, but depends only on the closest level of software piece to the device, because that part of the software runs on the motion controller microcontroller.
As far as I remember the spindle to comply the CE rules must directly disabled it by the external e-stop button with the e-stop button must have at least 2 normally closed contacts and the signal must go through on both in series so if any of the contactors will fail the circuit will still disconnect in case of an e-stop button activation. Or at least this was the rule about a year ago when I read them.
I don't know how would you comply these safety rules without using at least one physical input on the VFD instead of the modbus or a power relay discharger.
My description started getting a bit long, so I cut it short now so the most important is that I don't think leaving the spindle enable signal to depend from modbus register values is a safe way of controlling a spindle.

And I think that a solution for your suggestion can be is if you running a macro loop you could add a poll to the stop button press and if it is pressed then you could change your modbus variable which stops your spindle. Also you could check the reset button or LED state and do the same. But again I don't feel this a safe solution...