Guest
Show Posts
541
General Mach Discussion / Re: Macros And Buttons - Strangeness Abounds....
« on: August 24, 2011, 08:40:18 PM »
Ian,
Here's how I look at it - How the machine behaves should be absolutely, 100% predictable. Right now, it's not. I had a conversation with Brian this afternooin, and encouraged him to think about what the "philosophy" of Mach3 should be. Obviously, in the early days, there were all kinds of things added, kinda willy-nilly, sometimes without a lot of thought about the side-effects and hazards that might be created. Those are, in large part, the things that make Mach3 seem rather unpredictable and unreliable at times. As you say, sometimes features were added because one user asked for it, but sometimes a new feature ends up breaking something someone else is doing. I believe the fundamental problem is there are few clearly defined rules as to how Mach3 works, and we've all been forced to find our own, often very ugly, work-arounds. Personally, I'd like to see consistent, predictable behavior ALL the time. Right now, it just ain't so.
Here's something I learned today that surprises me - You can start a G-code program, and while it's running, you can launch a VB script that ALSO executes G-codes, and you have NO WAY to know how the machine is going to react. I had assumed that when you run a program, that running other G-codes would be locked out, but it's not. So, for example, if I accidentally bump my touchscreen, and activate the button that sends all three axes to 0, it WILL happen at some point in the execution of the running program! To me, that is incredibly dangerous, and I have a very hard time coming up with any valid reason for someone to NEED to execute G-code commands WHILE a program is already running.
Here's another example. If I hit my Z probe button, it executes an M-macro to do the probing. If I accidentally double-press that button (not hard to do with a touch-screen, BTW), then I have TWO instances of the M-script running in parallel, but they will NOT run nicely - i.e. - one instance completes, then the other one runs. That, at least I could live with. Instead, they run somewhat randomly - one executes a bit, then the other, then the first one again. And each time it happens, the result will be different.
What legitimate use is there for these unpredictable behaviors? These are the kinds of things that make is all tear our hair out, when trying to get seemingly simple functions to work reliably. If the system were more regular, predictable, and consistent, we'd have FAR fewer problems, and FAR better reliability. And we wouldn't have some people for who everything always works fine, and others, like me, that run face-first into a problem that gets us side-tracked for hours every other time we turn our machines on. One of the great strengths of Mach3 is supposed to be that it is so easily configurable and adaptable to the users needs. But it is precisely in that configurability that all the monsters lurk. Even simple configuration changes can have completely unknowable (to us) side-effects that result in scrapped work, broken tools, or worse.
I now use my machine for paying work, and I NEED consistency and reliability, and I don't have it. Right now, I'm not even close. Having a well-defined philosophy for how Mach3 operates, and how it is expected to be used would help a LOT. Right now, it's just the wild west out there, and every time I try something new, I end up with a new problem to debug.
Regards,
Ray L.
Here's how I look at it - How the machine behaves should be absolutely, 100% predictable. Right now, it's not. I had a conversation with Brian this afternooin, and encouraged him to think about what the "philosophy" of Mach3 should be. Obviously, in the early days, there were all kinds of things added, kinda willy-nilly, sometimes without a lot of thought about the side-effects and hazards that might be created. Those are, in large part, the things that make Mach3 seem rather unpredictable and unreliable at times. As you say, sometimes features were added because one user asked for it, but sometimes a new feature ends up breaking something someone else is doing. I believe the fundamental problem is there are few clearly defined rules as to how Mach3 works, and we've all been forced to find our own, often very ugly, work-arounds. Personally, I'd like to see consistent, predictable behavior ALL the time. Right now, it just ain't so.
Here's something I learned today that surprises me - You can start a G-code program, and while it's running, you can launch a VB script that ALSO executes G-codes, and you have NO WAY to know how the machine is going to react. I had assumed that when you run a program, that running other G-codes would be locked out, but it's not. So, for example, if I accidentally bump my touchscreen, and activate the button that sends all three axes to 0, it WILL happen at some point in the execution of the running program! To me, that is incredibly dangerous, and I have a very hard time coming up with any valid reason for someone to NEED to execute G-code commands WHILE a program is already running.
Here's another example. If I hit my Z probe button, it executes an M-macro to do the probing. If I accidentally double-press that button (not hard to do with a touch-screen, BTW), then I have TWO instances of the M-script running in parallel, but they will NOT run nicely - i.e. - one instance completes, then the other one runs. That, at least I could live with. Instead, they run somewhat randomly - one executes a bit, then the other, then the first one again. And each time it happens, the result will be different.
What legitimate use is there for these unpredictable behaviors? These are the kinds of things that make is all tear our hair out, when trying to get seemingly simple functions to work reliably. If the system were more regular, predictable, and consistent, we'd have FAR fewer problems, and FAR better reliability. And we wouldn't have some people for who everything always works fine, and others, like me, that run face-first into a problem that gets us side-tracked for hours every other time we turn our machines on. One of the great strengths of Mach3 is supposed to be that it is so easily configurable and adaptable to the users needs. But it is precisely in that configurability that all the monsters lurk. Even simple configuration changes can have completely unknowable (to us) side-effects that result in scrapped work, broken tools, or worse.
I now use my machine for paying work, and I NEED consistency and reliability, and I don't have it. Right now, I'm not even close. Having a well-defined philosophy for how Mach3 operates, and how it is expected to be used would help a LOT. Right now, it's just the wild west out there, and every time I try something new, I end up with a new problem to debug.
Regards,
Ray L.