polling input while executing G code

[dhanger]

I don't have a $180,000 machine and it doesn't have a check for the drawbar, that's the point I don't seem to be getting across. The machine originally came equipped the way I'm trying to set it up. It has two crash sensors attached to the carousel that checks whether it's being pulled up or pushed down. Okay, you don't see the need--that doesn't mean someone else doesn't.

[dhanger]

Some photos of the carousel construction.

Sensors at the top
Belleville washers below, with the platter mounted on 6 points that allow the platter to be initially adjusted level, then the belleville washers allow the platter to move up or down if the drawbar gets stuck open or closed, triggering one of the sensors.

[dhanger]

I also tried setting an input trigger for the 2 sensors with a trigger of 130 (cycle stop)

Dan,

I think you're on the right path here. If the motion command is ignoring the Cycle Stop signal, then I'd suggest trying other triggers which should force motion to stop.

• Set the input trigger to the Reset button (144).
• Assign the input pin to one (or both) probe inputs on the settings page, and enable safe probe mode in the macro.
• Couple the crash sensor to the e-stop circuit (after all, crashing into something would certainly qualify as an emergency).
• Couple the crash sensor to an axis limit circuit.

In addition, after your while(exec.Ismoving()) loop, you'll want to check the exec.Ismacrostopped() flag to prevent continuing your macro statements if a crash happened.

Frank-

Changing the trigger from cycle stop (130) to reset (144) gave me the response I was looking for; adding Ismacrostopped allowed me to gain control and terminate the macro. I still have some code cleaning to do but at this point it looks like problem solved.

Thanks,
Dan

[fsli]

It seems pointless to rely on the while loop for anything after the the exec.code command as long as it's not even referenced until the move is completed

I'm still trying to wrap my head around the exec.Ismoving(), but I include it as an idling loop after every exec.Code() that moves the machine, as a precaution. I think the key is the exec.Ismacrostopped(), more so than exec.Ismoving(). For example, I can see a case where you issue the exec.Code to move the machine, and that motion is interrupted (say, by a Cycle Stop), and the exec.Code completes before the machine has physically stopped moving. That's because Cycle Stop is a stop with deceleration and not a hard stop. So, think about it: machine is moving, you hit Cycle Stop, the exec.Code completes, but the machine is still moving however slightly as it decelerates. In that scenario, the exec.Ismoving() returns true immediately after the exec.Code() completes, but would return false some milliseconds later.

An alternate method, paraphrasing from your macro:

Code: Select all

// Get the machine moving.
exec.Code("G1 F100 G53 Z2");

// Idle loop to wait for motion to stop.
while (exec.Ismoving()) ;

// If the motion command was interrupted (presumably by the crash sensor, but
// could be for other reasons) or the crash sensor pin is raised, then exit the macro.
if (exec.Ismacrostopped() || !AS3.GetLED(in_pullSensor_pin))
{
   MessageBox.Show("Tool not released! Stopping tool change.");
   return;
}


The exec.Stop() isn't needed because the exec.Ismoving() loop guarantees the machine is no longer in motion.

As for building your own polling mechanism using a timer or background macroloop, yeah, that gets complicated. Which is why I stated previously that you were on the right path by using a built-in mechanism (cycle stop, reset, safe probe, e-stop, or physical limit) to recognize that things didn't work as expected.

[fsli]

Oh, just saw your response while I was posting mine. Glad to hear it worked out.

[dezsoe]

Well, it's strange, but exec.Code really don't return before finishing the G1. If you want to handle the problem and not just reset out the whole stuff, here is a sample using a timer (open Console for results):

Code: Select all

System.Timers.Timer StateTimer;

StateTimer = new System.Timers.Timer(10);
StateTimer.Enabled = false;
StateTimer.Elapsed += UpdateStatus_Event;
StateTimer.AutoReset = true;

exec.Codesync("G0 G53 Z0");

Console.WriteLine("Code running");

StateTimer.Enabled = true;
exec.Code("G01 f100.0 G53 Z-3");
StateTimer.Enabled = false;

Console.WriteLine("Out of the loop");

if (exec.Ismacrostopped())
  Console.WriteLine("Stopped");

while(exec.IsMoving()) ;

#Events

int cnt = 0;

void UpdateStatus_Event(Object source, System.Timers.ElapsedEventArgs e)
{
  Console.WriteLine("Check inputs");
  if (++cnt == 20)
    exec.Callbutton(130);
}


I replaced the input check with a counter to test in demo mode. Use the Callbutton(130) instead of exec.Stop, because Stop will stop the movement, but it will not set the Ismacrostopped.

[fsli]

Well, it's strange, but exec.Code really don't return before finishing the G1.

Then what's the point of including the while (exec.Ismoving()) ; idle loop in so many macros? Even your example that you posted today has it, and the default macros provided with UCCNC (M204 and M216, for example) use it as well.

[dezsoe]

Yes, this made me confused. I'm absolute sure that there are (were?) cases when the Code don't (didn't?) wait for the code to finish. After the holidays I'll ask Balázs about how it is now. When dhanger wrote that the macro doesn't get into the loop I wrote a quick macro to show that it goes into. It didn't. I ran a quick test with 1.2049 too, but with the same result. I'm also on holiday so I didn't have time to test more old versions (I have about all since 1.1111 on my PCs) so I wrote the timer version quickly. I'm also not sure that Code works the same connected to a controller (I don't have any with me), so I tested in demo mode. But I got very curious.