forum.cncdrive.com

I had someone request an option to goto Safe Z when hitting the Stop button, like Mach3 has.
I thought I could do it in a macro, but I can run a macro from a button while g-code is running. And further, I don't like UCCNC's SafeZ, in work coordinates.
I'd also like a little more power.
Some industrial routers, will lift the spindle during a Feedhold, which would be a nice feature.
So here's my idea.

Can we have UCCNC run a macro in 3 different cases.
1) Macro 1, when feedhold is pressed, and motion stops. I'd like to use this to stop stop the spindle, and lift it up.
2) Macro 2, when feedhold is pressed, before motion begins. This would let me restart the spindle and lower it back down.
3) Macro3, after Stop is pressed. This would allow me to lift the spindle on stop.

Rather than hard code these features, this would allow other users to do other things as well, like turn off coolant during feedhold, or who knows what else?

What do you think?

Hi Gerry,

Well, the move to safeZ when the Cycle is stopped is the easier part, because you could write a macroloop which monitors the Cycle LED and if the LED's previous state was ON and the next state is OFF then execute a motion to the safeZ.
Also if you enable the 3D printer plugin that executes a Z lift to the set coordinate in the plugin, it is to lift the Z-axis when the cycle is stopped, so the 3D print filament will not freeze on the workpiece.

The safeZ movement is not so easy, because the UCCNC API does not allow motion when in feedhold.
However a macro could issue a stop and remove the feedhold, make the required things and set the feedhold back.

You mean you want macros to be automatically executed when the events you described happen?

cncdrive wrote:You mean you want macros to be automatically executed when the events you described happen?

Yes, but if the macroloop will work, then that will be fine for now. I'll try it tomorrow.

And yes, I understand that you would like a bit more power.
How we see it is that the more power is the better for the advanced users, but can become very problematic and confusing for the beginner and avarage users,
because if we allow everything to be done then the avarage user can't decide what will cause problems and what will not and could easily create problems.
So, giving power is a double edge sword as we see and so far we tried to balance to give enough power to let users make what they want to but limit things which we think could easily create problems.

One thing which could very easily become problematic is to run a macro when g-code is running.

Yes, macroloops running in the background even if g-code is running, they still execute, but you know there are things which are not adviced to be done when there is motion ongoing is for example to execute .Code from a macroloop when there is still g-code execution, because then what will happen is the g-code line will be inserted into the motion buffer while the normal g-code run is also inserting g-code lines,
and that could cause random looking behaviour. So, be careful what and how you executing from the macroloop.

Yes, the UCCNC will clear the motion buffer when you executing a Stop, but the code line pointer will point on the line where you executed the Stop, so there will be no issue Stopping, moving off and continuing, except if the code line was in G91 or if it was an arc, because if it was a G91 and so if you stop that then on executing that line again will move again that distance and not the absolute value and if it was an arc and you moved off the arc then it might cause an arc error, because the arc may be not insertable mathematically on the moved off point or it may be a different arc which might be a problem.

Terry, Yes, that's how it is, I see you figured it out meanwhile.

The UCCNC will know how to complete the arc if the arc is mathematically insertable on the current point and the programmed endpoint and the center.
The less problematic when the arc is defined from the 2 points and center (IJ mode) and is more problematic when it is defined from the 2 points and Radius,
because then if you jog off and restart you may jog too far where the distance gets too high compared to the size of the radius to calculate the center point, in other words mathematically an arc can't be defined from 2 points and radius if the 2*radius is smaller than the distance of the 2 points, then there will be no valid center point, so the arc can't be executed and that is when the UCCNC gives you an arc error.

And the G91 mode is already an issue to restart from a midpoint of the movement, so stopping and restarting from a feedhold is not more problematic then when simply stopping and restarting, it's the same problematic.

because you could write a macroloop which monitors the Cycle LED and if the LED's previous state was ON and the next state is OFF

Can you give me a quick example of how to do this?
Thanks.

Code: Select all

bool LEDprevstate = AS3.GetLED(54);
double Zup = -20;

while(loop)
{
  loop = exec.looprun[loopnumber]; //To update the loop variable, because this internal loop does not reach the end of the macro, so the loop can be stopped and does not have to be killed to get stopped
  bool LEDcurrstate = AS3.GetLED(54); //Get the Cycle start LED current value
  if(LEDcurrstate != LEDprevstate && !LEDcurrstate) //If the Cyclestart LED state changes and if it changed to off then do some action...
  {
     exec.macrostop = false; //The Stop button sets the macrostop variable, so this has to be reset, because otherwise movement will not execute.
     exec.Code("G53 G0 Z" + Zup); //Execute the movement
  }
 
  LEDprevstate = LEDcurrstate; //Set the current LED state to the previous one
  Thread.Sleep(50); //Sleep some time so the loop will not overload the CPU
}

Yep, there is a trick why it probably did not work for you Terry and honestly yesterday when I wrote this advice I did not think about this, only when I've coded the macro.
So, the issue is that this thing have to be triggered on the stop button, but the stop button is the button used to stop motion.
The problem about this is that the stop button has to stop motion, but in this case the macro still has to execute motion, and that motion also has to be stopable with the stop button.
When the stop button is pressed then an internal variable is reset to stop the movements and so the macro executer will not accept more movements, because then the macros can still continue the run,
but should not add more motion to the buffer if the user requested a stop.
The trick for the macroloop is to set that internal variable of the UCCNC (as in the above code) ater the stop button is pressed, so the software will accept the movement.

Just FYI, the same variable is also set when a Cycle is started and when a MDI code is executed and is reset when a Stop or reset it executed, so the macros will know when it is allowed and when not to make movements.

In general macroloops are not adviced to generate motion, but they could, just it is a little tricky...