Ray - Maybe I'm not so good at getting my point accross or maybe it's something else.
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.
I absolutely agree. You get no argument from me at all on the above.
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.
I absolutely agree - This is totally unacceptabe.
HOWEVER... A while back I asked you which VERSION you were using and unfortunately you dismissed my question out of hand. I can tell you for a FACT - that this does NOT happen with my version. It has NEVER happened and no matter how I try to screw things up I CAN NOT make this happen. I AM NOT SAYING THIS DOESN'T HAPPEN TO YOU. What I AM saying is that this is NOT just a SIMPLE case of something that has NOT been thought about and MISSED in the general Mach development process.
if I was involved in bug tracking Mach I can tell you it would be of great interest to me that this is NOT a problem that affects everyone. IS IT A VERSION THING OR IS IT THE RESULT OF SOMETHING YOU'VE DONE? This is NOT to somehow BLAME you. NO MACRO HOWEVER IT'S WRITTEN SHOULD BE ALLOWED TO ADVERSELY AFFECT THE MAIN SYSTEM IN THE WAY YOU DESCRIBE- It's a question that MAY HELP FIND THE PROBLEM.
An aside... I remember the first time I installed XP when it first came out. I nearly fell off my chair laughing when during the install whilst chuntering on about it's improvements it proudly announced words to the effect of "Now if a program crashes it will not take the Operating System down with it" - About bloody time I thought - to me that's an absolute fundamental that I would EXPECT from any decent OS and here's MS saying it as if they'd just thought of it.
So I'll re-state...
NO MACRO HOWEVER IT'S WRITTEN SHOULD BE ALLOWED TO ADVERSELY AFFECT THE MAIN SYSTEM IN THE WAY YOU DESCRIBE.
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.
Again - I agree absolutely - this is unacceptable.
HOWEVER... I'd refer you to my answer above. THIS DOES NOT,HAS NOT and I CAN NOT make this happen with my system. I've tried it Ray - I've screwed with things in a deliberate attempt to try to REPRODUCE this behaviour and I can't. It behaves ROCK SOLID. This would make me suspicious of the macros you use to see how they manage to find a LOOPHOLE in the system. THEN FIX THE LOOPHOLE.
What legitimate use is there for these unpredictable behaviors?
Absolutely no use whatsoever.
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.
I absolutely agree.
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.
Now this is where we start to diverge...
You appear to be blaming the flexibility of Mach and proposing that the solution is to get rid of (some of) that flexibility. I'm saying KEEP the flexilbilty but FIX it PROPERLY.
A perhaps poor analogy if I may... Your car's breaks don't work properly and concerned for your safety. Do you a) Fix the breaks or b) Take the turbo off so that you can't go very fast?
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.
I completely understand.
Ian
Guest
Show Posts
