On Wednesday 20 August 2014 05:36:07 andy pugh did opine
And Gene did reply:
> On 20 August 2014 09:33, Marius Liebenberg <[email protected]>
wrote:
> > What will be the best way to handle a timeout or delay of several
> > seconds in a component?
>
> It depends on how many waits there are.
>
Can it not depend on the state of an input pin to terminate the delay?
If such a tally is available, then I would be inclined to start the wait
by using edge detectors to flip a flip-flop, then when the condition that
caused the wait to begin has cleared, or another condition indicating its
safe to proceed, clears the flipflop allow this command to proceed.
Similar to what I was doing to change direction on my lathe spindle for
executing a G33.1 in a peck cycle. I used edge detectors to detect the
motion modules change in direction status, setting a flipflop, stopping
the motor, and the output of a wcomp watching spindle velocity to clear
it, synthesizing a stop until it was close to stopped and safe to apply
power in the new direction.
It was more complex than that however as I was also zeroing out the speed
requested to the pid module so that when it was safe to apply power in the
other direction, the limit2 and mux2's to achieve that, all started at a
10 rpm command, and ramped back up to the requested speed at less than
belt striping accel rates.
Given that the end of a needed wait can be detected, there are several
ways this cat can be safely skinned. This particular method had a fatal
flaw that could be generated by a gcode command, it was possible to have
the pid.output change signs in the event of a s-speed from high to low was
encountered. Suffice to say having the spindle, at 1500 rpms, be switched
to 200 rpms, and the overrun changed the pid sign, the controller only
survived 3 cycles of that as it was stopping and reversing it about 1/2
turn & then instantly going back up to the new speed. All I can say is I
was damned glad my chuck wasn't a screw on model. But the huge cast iron
flywheel/fan/pulley on the motor IS. No clue why that didn't unscrew
other than I had put it back on with red thread locker when I had it apart
a year ago.
> If it is only a single wait, or at least very few, then just have a
> wait-state
>
> long long wait_until;
> ...
> switch (my_state){
> ...
> case N:
> wait_until = rtapi_get_time() + 7e9;
> my_state = 12;
> break;
> case 12:
> if (rtapi_get_time() > wait_until) my_state = 13;
> break;
>
>
> If you need to wait in many places, then have a second variable to
> hold the "next state" and "timeout_state" to return to after a
> dedicated waiting state.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
