539
« on: August 25, 2011, 09:21:21 AM »
Guys,
For several weeks now, I've been using current development builds Brian has given me. But I find it hard to believe version has much impact on some of these problems, as they are fundamental architectural issues in Mach3, confirmed by Brian, so I believe they have been there a long time. Scripts are, by design, allowed to "inject" G-code into the buffer at ANY time, as no mechanism exists in Mach3 to prevent it. It was done because there are a few cases where it is apparently necessary - the example Brian gave was THC, where the users needs to be able to adjust Z position while a program is running (though I would provide an explicit THC offset that operated much like FRO and SSO).
I have v3.042.020 (about two and a half years old, IIRC) running on my laptop, and I can easily demonstrate these problem on that. My machine is running a derivative of 3.043.047, and has all the same issues. Try this:
Create a button, and assign to it a button script "Code("G0 X0 Y0")". Now load and run a program, and as it's running, click that button. You'll see that within a few seconds, the X/Y DROs go to zero, but the program continues running, completely unaware. This is with a plain-Jane install, nothing special, no modifications of any consequence. Absolutely 100% repeatable here, on all my machines, including my big mill with the SmoothStepper.
Ian,
I'm not saying get rid of the flexibility. I'm saying leave it where it makes sense, and does not hinder system integrity and reliability. Implement ALL features in a rational, robust, consistent manner, which is not the case currently. The above issue is a perfect example. One person will argue that being able to asynchronously inject G-code into a running machine is useful (see the THC example), but I say it's the wrong way to do it, and while providing *a* means of accomplishing the desired function, it creates hazards which will cause far more problems than it solves. The correct way to handle that is to provide an explicit mechanism that cleanly implements the desired feature without the undesirable side-effects. Another example Brian gave way that someone may want to change some output pin while a program is running (why, I don't know....). OK, perhaps so, but I would argue G-code is not the way to do that. Instead use the VB functions that allow outputs to be explicitly set and cleared. There should be one, and only one G-code input buffer, and there should be strict rules about who can push things in there, and when. Instead, there are currently multiple buffers, and new ones can be created at will through VB, and each VB script is run in its own thread, so there is absolutely no coordination between those threads, resulting in the kinds of odd behaviors I see on a daily basis.
My Z probing script is attached. You'll find there is absolutely nothing unusual in it that could possibly explain what I'm seeing. And, EVERYTHING I've reported here has been confirmed by Brian. My script is launched by an on-screen button that directly executes the script (NOT via a button script - the M-code is assigned to the button in the screen editor). I have no doubt Brian will get this all cleaned up, and the (sometimes seemingly mythical) v4 will be a HUGE step forward, as Brian is working very hard to clean up these architectural issues, and create order out of the chaos.
Regards,
Ray L.
Guest
Show Posts