Hello Guest it is March 28, 2024, 02:01:08 PM

Author Topic: run amuck on STOP  (Read 6676 times)

0 Members and 1 Guest are viewing this topic.

Re: run amuck on STOP
« Reply #10 on: October 27, 2006, 01:53:37 PM »
I can't say for sure if it has done it on the first time or not, but I believe it has. Except for the example below, I always try to rewind to a predictable X, Y, & Z starting point, and for the most part, it will start on track to the proper location. Each time the stop event has happened, the head was traveling along the desired path. It is just that hitting stop does more than raise and stop. Both X and Y are getting new values that are not on the path.

Even in the example below, after a successful stop, Start would harmlessly cause the tool to circle around at the safe height and in the correct location, and then with the next DOC iteration, plunge to the next cutting level and continue cutting the circles in the proper location. Because I was cutting air, I didn't violate any DOC rules that would have broken bits on a real job, so I didn't worry about finding a safe starting point. The point is that the tool was always on a valid path at the time a STOP was pressed.

All of the things you are saying are true, I probably shouldn't use STOP the way I do, and the risk of screwing up the job may increase as a result, however with that said, Stop MUST NOT pick up bogi X, Y, & Z values no matter how improperly anyone uses Stop. The meaning of STOP shouldn't change no matter how many times it has been used before.

I have been writing control code for many years and I have learned that a predictable response to an input is paramount. The STOP event smacks of nested interrupts clobbering registers. Preemptive interrupts, like STOP, are especially difficult to write because we tend to allow them to execute at critically bad times in the code (like when the registers are being updated).

Whatever the problem is, you will eventually find it, as I have often said, "hidden under a rock".
Pixel Tamer