--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi AZ,
>
>
> I think the GCode Subroutine technique would be the most logical and straightforward approach.  It isn't clear whether that GCode syntax is acceptable to you or not.
>
> G0 is actually not coordinated motion.  Each axis moves independently as Jerk limited motion which in most cases is not a straight line but will be faster and smoother than a G1 motion.
>
> CheckDoneXYZABC();   will only work with independent motion.  But with back-to-back G0 there will be zero time between moves and trying to jamb in a feedhold right at that instant probably isn't going to work well.
>
> I think the program I attached to the previous email is a better approach than the technique you described.  It checks "InPosition" on a more continuous basis.  The Check, Delay, Check approach you describe has a flaw where two glitches of "InPosition" might be occasionally accepted.
>
> Even though you don't have a Z axis that moves in a controlled trajectory, a workaround could be to define an dummy Z axis without anything connected (Output Mode = No Output).  Then you could use something like a canned drill cycle and the dummy Z motion could be easily detected by your C program and would indirectly introduce a delay that FeedHold could also be used to Stop.
>
> To throw an error Message Box see KFLOPtoPCCmdExamples.c 
>
> HTH
> Regards
> TK
>
>
>
> ________________________________
> From: "az9633@..." <az@...>
> To: DynoMotion@yahoogroups.com
> Sent: Sunday, March 10, 2013 10:49 AM
> Subject: [DynoMotion] Re: In position bit
>
>
>  
> Hi Tom.
>
> Thanks for your suggestion. I believe your example assumes I have a K flop controlled Z axis but all I have is a solenoid that drops a cylinder to a prox then raises the cylinder to a prox at which time I want the motion to continue to the next position in the G code program.
>
> I'm considering running a C program called by an M code at the start of the motion program. The motion program will be coordinated G00 or G01 motion. This Called C program would:
>
> Watch the X,Y trajectory complete bits CheckDoneXYZABC()
>
> Activate Feedhold (like on the CNC screen but I can't find a bit that does this)
>
> Then would monitor the double LastFollowingError until it's within my determined value
>
> Then Delay_sec (double sec) for determined time.
>
> Then monitor the LastFollowError to see if it's still within range
> [If this is not within range then to back to start of suroutine and execute again. If this does not complete within 2 seconds, output an error bit and stop program from continuing.]
>
> If FollowError is within range then:
> Then output "down output" bit
> Wait for "Down prox" input
> output "Up output" bit
> Wait for "Up prox" input
> Release the feedhold bit and go back to top of subroutine.
>
> Do you think this subroutine could detect the Checkdone and activate a Feedhold before the program goes on to the next move?
>
> Can an M code stop the processing of the subroutine and allow it to start again with an M Code?
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi AZ,
> >
> > How about using a GCode Subroutine like below?
> >
> > I can't think of a good way to hold off the motion without putting something in the GCode.
> >
> > I suppose a C program could be running and watching the xy motion and as soon as it detects the xy trajectory come to a stop immediately issue a hardware feedhold.  Then it could watch and wait for the IN Position status, then release the feedhold.  The Z drill motion would then occur.  Then it would wait until it saw some xy motion, and then repeat.  A Virtual IO bit could also be used as a condition for doing anything.
> >
> > Regards
> > TK
> >
> >
> >
> >
> >
> > G21 G0 X0 Y0 Z0
> > M98 P100 #1=100 #2=200 (Call the Subroutine)
> > M98 P100 #1=110 #2=200 (Call the Subroutine)
> > M98 P100 #1=100 #2=220 (Call the Subroutine)
> > M2 (Stop)
> >
> > O100 (Subroutine Label)
> > F400
> > M100
> > G0 X#1 Y#2
> > M101
> >
> > G1 Z-1
> >
> > G1 Z0
> > M99
> >
> >
> > ________________________________
> > From: "az9633@" <az@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Saturday, March 9, 2013 3:14 PM
> > Subject: [DynoMotion] Re: In position bit
> >
> >
> >  
> > Hi Tom:
> > Thank you for your response and I'm sorry my description was a bit convoluted. My application is point to point XY table microstepper with encoders but in the future could be servos.
> >
> > It has a punch or drill head that I want to activate at the end of each completed move but only if the axes are verified to have stopped within a designated window that could be much smaller than an expected in-motion following error. This is what the motion-complete-in-position bit would do.
> >
> > This bit would be used to prevent erroneous punching in the case where correct final positioning is prevented or delayed by high friction or oscillations due to imperfect mechanics like loose couplings or dry gibs etc. The longer cycle times will give the operator a heads up to get the maintenance crew involved to fix the problem without ruining a lot of parts.
> >
> > The punch cycle could be activated with an M-code at the end of each move but because each move will require the M code, programming could get tedious. I'm trying to make the programming simpler by activating the Punch mode with an M code at the start of the program and simply programming the positions.
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi AZ,
> > >
> > > It isn't exactly clear what your requirements are.  I assume you are using Servos with encoder feedback to KFLOP?
> > >
> > > Are you doing coordinated motion?  It seems you are using GCode?
> > >
> > > Normally the "In position" is not really an issue because a motion trajectory is chosen such that the servo error (following error) is always very small throughout the motion.  So when the trajectory finishes the system is already  in position.  If the motion fails because it hits something or is somehow disabled then the following error will trip and stop the system.
> > >
> > >
> > > But if you feel you still do need such a thing I've attached an example that will turn on and off an IO (KFLOP LED) whenever the following error is below a specified tolerance for a specified duration.
> > >
> > > I don't think you need to worry about stopping when in feedhold because the feedhold itself will stop any progress.
> > >
> > >
> > > It is possible to cause coordinated motion to stall waiting for an external event with very accurate synchronization.  See:
> > >
> > > http://www.dynomotion.com/Help/KMotionCNC/SynchronousIOCommands.htm
> > >
> > > Or another simpler way is to use a MCode that executes a program that waits for something.  This method will always wait properly but involves Windows and the PC so there may be some occasions with some additional delay.
> > >
> > > To implement a watchdog you might toggle a bit in a loop.
> > >
> > > HTH
> > > Regards
> > > TK
> > >
> > >
> > >
> > >
> > >
> > > ________________________________
> > > From: "az9633@" <az@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Saturday, March 9, 2013 3:39 AM
> > > Subject: [DynoMotion] In position bit
> > >
> > >
> > >  
> > > Maybe I'm missing something that's already available but here's my question.
> > >
> > > My X Y application needs to know when a motion command has been completed and the axes are in the commanded position and stopped unless stopped by a feedhold, limit switch or end of program. Ideally I would also need an in-position tolerance of a number of encoder counts for an amount of time (.1 to .2 sec) before setting the bit.
> > >
> > > I will be utilizing a thread started by an M code to look for this bit and respond to it. This thread will continue to run through multiple axis moves until it's reset by another M code or end of program. This thread will reset the bit and wait for the next setting of it by the next motion completion. Another M code will stop this thread when it's not needed
> > >
> > > Do you have an example code that will do something like this?
> > >
> > > Another question: While the thread is responding to the bit, the motion must stop until it is allowed to continue by this M code thread.
> > > How should that be done?
> > >
> > > I also would like to implement a external watchdog output from the K flop to an external timer to monitor for lockup. Or is there something like this already available on the K flop?
> > >
> > > Thank you.
> > > AZ
> > >
> >
>