Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: HimyKabibble on August 11, 2011, 09:29:12 AM
-
For, well, forever, I've had problems with my machine doing weird and unpredictable things from time to time. Lately, for whatever reason, it's been much worse, and has really been driving me crazy. Here's the kind of stuff I'd see:
1) At random, one axis would stop jogging. Jogging any other axis would get the "dead" one to come back to life
2) MDI would sometimes stop working
3) Occasionally, the machine would make un-commanded moves, or turn the spindle on, or off, by itself.
4) It would sometimes simply stop in the middle of a program run, as though someone had hit FeedHold
5) More often, the machine would refuse to make a move, by jogging, MDI or a macro, then spontaneously do it at a later time!
6) Jogging in continuous jog mode would sometimes give VERY jerky motion
7) A few times, I would command a probe in one axis, but the machine would actually probe in a different axis, or even multiple axes!
8) It would sometimes ignore SingleBlock, and run the program normally WHILE SingleBlock was still lit
9) Yesterday was the weirdest one of all - I tried to edit a button script, and within the VB editor window, if I selected some text, instead of the text being selected, the Z axis would go through a 1-2 second sequence of moves. This was absolutely repeatable!
And more...
I've suspected for several days the problem was somehow related to macros not running correctly, and somehow getting buffered up within Mach3. When I saw that last one, it became crystal clear that there was something really wrong within Mach3 itself, so I contacted Brian, with the result that he quickly found a serious problem in Mach3, related to the button code. In his words: "the base Button code was never meant to be able to handle Macros". He found some thread un-safe code in there, but he's now corrected the problem, and sent me a test build to try out, which I will be doing today. This could explain a LOT of the problems I've had over the years.
I'll report back after testing. This could be a major step forward in making macros more stable and predictable.
Regards,
Ray L.
-
Never had a prob myself Ray but my macros are simple affairs ;D hope Brain has found the issue for you and likely it will also help others.
Hood
-
Lost Mach syndrome been there done that one.
(;-) TP
-
Brian has found, and fixed, several problems already this AM. I'm about to test what I think will be the final test build (at least until I find the next bug.... :D). In addition to the threading issue, we also found that if you do Edit->SelectAll, followed by Edit->Delete in the button script editor, rather than deleting the selected code, it actually executes the macro! In addition, Edit->Undo has, apparently, NEVER worked! Both of those problems are now fixed as well.
I have to give Brian kudos - He has never failed to jump immediately on any problem I've found (and there have been many), and he's almost always come up with a fix in short order. I"m cautiously optimistic fixing these issues will make a very significant difference in the reliability and stability of my machine. It seems (so far....) to have fixed the many issues I've been having with jogging lately.
Regards,
Ray L.
-
I have to give Brian kudos - He has never failed to jump immediately on any problem I've found (and there have been many), and he's almost always come up with a fix in short order.
Have to agree with you Ray, if you can find a sure fire way for Brian to see the problem there then he can usually get it fixed and quickly. He has been busy the last day or so , fixed a couple of issues I found in Rev4 and sorted yours as well, he must be having fun ;D
Hood
-
Well.... One step forward, one step backwards. The worst of the problems are solved, but the fix seems to have uncovered, or created, a new problems, and I've run into a SmoothStepper problem as well. Jogging now seems to be working well, except for step mode - whenever I change axes in step mode, the very first step will step both the selected axis, AND my A axis! After that first step, all is well, until I change axes again. Brian will take a look at that tomorrow.
The SmoothStepper is now randomly throwing errors, causing Mach3 to shut down. It seems to be receiving an unexpected command. We've tossed that one to Greg, to hopefully explain what the error code means. I was forced to update both the USB driver and Plug-in for the SS to be able to run the new Mach3 executable, so there's no going back now. Unfortunately, having the SS throw up is worse than having the flaky jog-related problems, so I got no work done today. Hopefully Brian will have an "Aha!" moment in the AM, when he looks into this new issue.
Still, great progress today, and having buttons work more reliably through VB will definitely be of great benefit to many of us.
Regards,
Ray L.
-
Another day of incremental progress.... Brian has made a few more changes in the button code, but the odd A axis behavior has, unfortunately, gotten worse. The A axis now takes a step on the first move following an active axis change through my pendant, and it now also takes a step at the start of every move in any probe (G31) operation. On my machine, the A axis is the knee, and I using probing on the quill (Z axis) to set tool length. Each time I do this, the knee ends up moving by about 0.005". Not good.... In addition, doing an axis select on the pendant sometimes causes jogging on the pendant to simply stop working. Changing jog mode in-screen gets it going again. My jerky continuous jog also reared it's ugly head again today, clearly caused by some VB process that lost its mind, as hitting ESC (which kills all active VB processes) got the jog working smoothly again. Brian is still working hard on this, but unfortunately it doesn't happen on his machine! Very odd....
Regards,
Ray L.
-
Ray, Which V are you using? I've never had any of these issues - I've stuck with R3.042.020 as I've found this to be darn near completely stable and I've used plenty of complex macros. A few issues with the Brain editor but that's about it.
as hitting ESC (which kills all active VB processes)...
Personally I believe it SHOULD, but it doesn't - neither does hitting RESET - well not in the above V anyway.
Ian
-
When I was doing the lathe and because I am crap at VB I often had things hanging and Esc sometimes worked, sometimes didnt. In the end I put a button on screen with DoOemButton(322) in it and that seemed to work fine. Dont have it now as all is working with the turrets etc but it was handy at the time ;D
Hood
-
I'm with Stirling - using the same version, and no trouble with macros at all.
I'm very leery of the 3.043 versions, after I found that my M6 macro doesn't work in the current lockdown (although Brian fixed it for the development versions).
If it aint broke, don't fix it - seems to apply doubly to Mach3. Don't upgrade unless you absolutely need to. :)
As for killing macros... If I need to stop a macro in progress, I like to shut down Mach3 and reboot the PC, as I do get some strange results if I don't.
-
Ray, Which V are you using? I've never had any of these issues - I've stuck with R3.042.020 as I've found this to be darn near completely stable and I've used plenty of complex macros. A few issues with the Brain editor but that's about it.
as hitting ESC (which kills all active VB processes)...
Personally I believe it SHOULD, but it doesn't - neither does hitting RESET - well not in the above V anyway.
Ian
Ian,
Version doesn't matter - these bugs have been in there for many, many years. I first found them in 3.042.020.
Regards,
Ray L.
-
I am holding at V.020 BUT there is an earlier verion that is almost rock solid BUT the later versions Changed the way Modio works SO there is not an easy way to go that far back. It was the version before Art changed the Modbus and I had to reflash the modio to make it work with the newer version.
I also REboot IF I have to crash out of a macro for the same reasons listed.
Ray you are not alone(;-)
(;-) TP
-
Major progress today! Brian has finally reproduced, on his system, the odd behavior I have of the A axis moving when it shouldn't, like when I do a probe in Z. This currently causes my Z axis to move on the order of 0.005" every time I set my tool length. There is definitely a bug in there, in the math related to applying fixture offsets, which causes Mach3 to think the machine is in a position other than the position its actually in. He's working feverishly on understanding the root cause right now, so he can fix it.
He's also ordered a pendant similar to mine, so he can run my macropump "driver", to understand the jogging issues I have.
Regards,
Ray L.
-
Good news! Brian has fixed the problem that was causing erroneous moves on my A axis, so we're down to just a single problem now - macros sometimes going rogue, and causing jerky jogs, ignored jogs, ignored MDI commands, and a host of other anomolies. Brian is still working on these issues, and I have no doubt he'll have a fix shortly.
We're close! And I think these issues will help explain a whole host of irreproducible problems I, and others, have experienced over the years, and should especially go a long ways toward making extensive use of macros, as some of us do, much more robust .
Regards,
Ray L.
-
Sorry Comment deleted by me.
(;-) TP
-
Brian and I are continuing to beat on this, and finding increasingly smaller, and more obtuse,but nonetheless significant, issues. There is still an apparent problem with VB scripts hanging around, and causing problems. Brian is working on "instrumenting" this, to track down the root cause. We've tracked down some unexpected side-effects of some functions (like the fact that sending Mach3 a Continuous Jog Stop (OEM buttons 334-339) will cause G0, G1, G2, G3, G31 to misbehave. If you have a VB button, it is quite easy to get two instances of the script to run simultaneously (not good...), with often odd, and unpredictable, results. I believe these things, in aggregate, go a long way towards explaining the capricious and unpredictable nature of screenset and VB programming in Mach3, so I think we'll all be much better off once they're cleaned up.
My machine did something truly bizarre a few days ago - It got itself into a mode where, when doing a probe in Z, instead of doing the correct sequence (fast probe down, retract, slow probe down, retract) it would do a fast probe UP a short distance, then RAPID UP into the limits! Even a re-start did not fix it! A few hours later, it started working right, all by itself.
Regards,
Ray L.
-
HIYA RAY one thing to please remember to fix. In a Mcode that contains CB and code"Gcode motion code" MIX It is imperative that the macro stays in SIMPLE order of execution WITHOUT having to resort to extra wait states,symaphores and such. That means FIXING While Ismoving(), Isloading, etc so they WORK 100% without fail. I suggested a new function a while back.
SusWhileDo() that could be a big help.
Multithreading is Great but NOT if you cannot control it. With motion codes it MUST behave as it is a huge SAFTEY concern.
Good Luck, (;-)TP
-
Ray - I have a feeling I'm going to be howling at the moon - but can I please urge some caution.
Sending continous jog stops: If you want to change Mach to prevent the results of this then "maybe" that's fair enough. But to be honest if you send continuous jog stops then that IMHO is just crap programming. FWIW I know how this has come about because I've written pendant code. Proper programming prevents this. Anyway - like I said "probably" not a big deal to change this.
Now the one that really worries me.
Getting two instances of code running if you hit a button twice is not the least bit surprising nor if you understand that is it unpredictable. In fact it's perfectly normal in any threaded windowing environment. Moreover it can be useful - IF you know what you're doing.
You've stated earlier that Brian is good at responding to user requests and I would agree. However, I'm going to play devil's advocate and say that sometimes IMHO he's TOO good. When a user brings up what he considers to be "an issue" - I find myself wondering if enough time and thought is given before a "fix" is implemented. I get a nasty feeling here that a little too much "shooting from the hip" is going on.
Ian
-
HIYA IAN, Are you picking on me again? (;-) LOLOLOL
OK I am taking the stand for the CNC MACHINIST and no one else that uses MACh3 for whatever motion control. This is not for CB applications not pertaining to actual CNC machine use. I have very little problem using the CB for creating OTHER stuff it works very well
I need a Macro system for Mcodes that BEHAVES exactly like Gcode does. Run it live , run it from a buffer, run it from down the street, I don't care. BUT MAKE it behave as Gcode does. Simple and 1 line at a time execution if required. IF it takes adding in a header to identify it as a Mcode that is ok too. Use # parms or named Parms I don't care. Just provide a LIST of the params. Think MacroB here, it is not always pretty but darn it it works 99.99999% of the time.
I AM a cnc machinist NOT an ADVANCED system programmer. I should NOT have to learn a new Advanced programming language just to be able to create and use a Mcode to do my work. The basic conditionals + params + math will work just fine.
Thank You, End of rant (;-) TP
-
Hi Terry - picking on you? - absolutely not. FWIW I know you're a machinist with more experience than I can dream of.
Group hug over, you raise an interesting point about macro programming in Mach. Maybe if I understand you correctly, then it SHOULD be much simpler and more proscriptive.
I remember many years ago having a discussion with a fellow programmer who didn't like C. He argued that it was just too easy to screw a machine up and that C++ and Ada and their ilk helped prevent that. I argued that C allowed you to get into the very guts of a system but with freedom came responsibility. We never did agree.
So you know what? maybe you're right. Mach is not a programming environment - it's a machine controler and maybe macro capability and flexilbility should reflect that.
Ray - Please ignore my previous post.
Ian
-
HIYA RAY one thing to please remember to fix. In a Mcode that contains CB and code"Gcode motion code" MIX It is imperative that the macro stays in SIMPLE order of execution WITHOUT having to resort to extra wait states,symaphores and such. That means FIXING While Ismoving(), Isloading, etc so they WORK 100% without fail. I suggested a new function a while back.
SusWhileDo() that could be a big help.
Multithreading is Great but NOT if you cannot control it. With motion codes it MUST behave as it is a huge SAFTEY concern.
Good Luck, (;-)TP
Terry,
First, what the heck is "CB"??
I agree with what you said, and that is part of the point. What we're finding is there are all kinds of behavioral "quirks", and inter-dependencies that often defy logic. Even Brian is having a hard time wrapping his head around things. There are an awful lot of "features" that appear to have been added over the years in very "unclean" ways, leaving them with side-effects, or non-intiotive modal dependencies. That's the kind of thing we're trying to wring out. Behavior should be simple, logical, and, most of all, consistent. Often, that's not the case. When I see state LEDs that show the wrong state, or find something that works in MDI, but not in a script, or vice-versa, there's something wrong somewhere.
Regards,
Ray L.
-
Hi Terry - picking on you? - absolutely not. FWIW I know you're a machinist with more experience than I can dream of.
Group hug over, you raise an interesting point about macro programming in Mach. Maybe if I understand you correctly, then it SHOULD be much simpler and more proscriptive.
I remember many years ago having a discussion with a fellow programmer who didn't like C. He argued that it was just too easy to screw a machine up and that C++ and Ada and their ilk helped prevent that. I argued that C allowed you to get into the very guts of a system but with freedom came responsibility. We never did agree.
So you know what? maybe you're right. Mach is not a programming environment - it's a machine controler and maybe macro capability and flexilbility should reflect that.
Ray - Please ignore my previous post.
Ian
Ian,
I AM a professional programmer, and when I struggle trying to get simple functions behaving correctly, and logically, something is wrong. If this were a software developers IDE, I'd be more inclined to agree with you that the programmer should handle it, but the vast majority of people working with Mach3 at the macro level are NOT programmers, and could not possibly be expected to isolate, much less work around, the issues I've been finding. It's often taken Brian and I working together for hours to root-cause each of these issues, and in most cases there is some shaky code at the heart of it.
As for multiple concurrent scripts not being a problem - let me tell you how I discovered that one - I have a Z probing script I use for setting Z offsets after a tool change. The script does a fast probe, a back-off, a slow probe, and a final back off. If I double-click the button (which can easily happen by accident), I get two instances of the script running concurrently, wit NO coordination between the two, so it will do something different each time it happens. In one case, one script may run to completion, then the other will run. In the next case, I may see two fast probes, followed by a back-off and a slow probe, followed by another back-off, followed by another back-off, followed by another slow probe, and a final back-off. I should not have to write my script in such a way that it can deal with all that, I don't care what the target audience is, that is not a well-behaved system, and I see no real advantage to working that way. Better the default is NO concurrent execution, and in the truly rare and pathological case where the user feels he NEEDs to have it (and I would argue he's starting with a bad concept if he feels that way), let him write the code to do it. That way one person suffers, and the vast majority can have, a simple, logical, well-behaved system that does what they need with minimum fuss, and no expertise in multi-threaded programming and concurrency required.
Regards,
Ray L.
-
And, honestly, were these things not getting fixed, I would already be using a KFlop, because I've had a hard time getting my real work done with all the problems I've been having the last month or two.
Regards,
Ray L.
-
HiGuys, First off let me say how MUCH I appreciate both of you. By following your examples of code AND by you SHARING it with us I have been able to work in CB ( Cypress Basic) and do things I have NOT been able to master over the years.
I am missing the programmers LOGIC gene from my DNA. I can get lost in the simplest loop of code. Thru both of you and others I have developed a library of code functions that I use over and over again in various applications. There are things I do that take days to make work that you could do in 5 minutes. BUT I do get it worked out.
Also A thousand thanks to ALL that worked on the Mach Programmers Bible. IT is something to be proud of. PS there are a few more things I have found that need to be added.
Brian you got to know I love ya buddy who else would put up with us. Well Art did till we drove him crazy(;-)
SO I will climb off the box now and let it be.
(;-) TP
-
Ray - In my earlier post I believe I was just asking for some caution. There's a world of difference between de-bugging and "dumbing down". I believe in my post to Terry that you've quoted I then went some way to accepting that some of the latter may be in order for the "greater good". I do think however that killing off concurrency for the reasons you've stated is a bridge too far. JMHO.
Ian
-
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.
-
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
-
Following this with great interest guys.
Ray,
What version are you using please ??
Thanks,
Tweakie.
-
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.
-
Ian,
"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."
The whole time I've been involved with Mach3 (about 8 years now....) every time I've reported a problem, several people on the forums have jumped on me and pointed fingers at my computer, my macros, my machine, sunspots, whatever. For many years I was running with a 400MHz PC, and the guys on the Yahoo forum would immediately blame the slow PC for my problems. In all those years, not ONCE - not one single time - has a problem, once root-caused, been traced to my machines, my macros, or my PC. In every, single case, without exception, the source of my problems has been tracked back to a bug in Mach3, a bug in the SmoothStepper, or some architectural issue, like the current ones. Unless you can find fault with my one-line "Code("G0 X0 Y0")" button script, because NOTHING else of mine is running when I induce these behaviors. None of my macros are EVER used when the machine is running - I've learned the hard way to keep the he11 away from the control panel when a program is running.
When I do find a problem, one of the first things I do is go to a dead stock system, and reproduce it. If I can't, THEN I start looking at my configuration, and track down WHAT is inducing the problem, get clues about HOW the issue is occurring, then figure out how to induce it in a stock system. I am nearly always able to do this. In some cases, there are perfectly reasonable things I'm doing in my macropump, or a macro, that uncover weaknesses in Mach3, and in nearly every case Brian, once he understands the issue, is surprised by what's happening, and agrees it should not be happening. Even he is still learning about the inner working of the code he's inherited.
Regards,
Ray L.
-
Ray - I'm getting a little lost here. I've never critisized in any way your quest to improve Mach. The only time I thought we were really diverging was when you appeared to imply you would like to get rid of "concurrency". If that's not what you meant then we're "on the same page".
I stand by the quote in your last post. PLEASE PLEASE PLEASE read it again - I'm NOT critisizing YOUR macros. I'm simply saying that if something in YOUR macros is EXPOSING a LOOPHOLE in Mach then that may be a better clue to what's wrong rather than pooring over Mach source code. What's wrong with that?
For example: You stated earlier about sending a constant stream of JogOffs. If Mach then screws up general motion commands it shouldn't - it SHOULD be able to cope - BUT THAT SAID - sending a constant stream of JogOffs is NOT a clever thing to do. Period. It's akin to a Dos attack on a web server. Only in this case it's an attack on the driver or the smoothstepper or whatever.
Ray - if you're going through my posts looking for an argument then say so and I'll back off.
Now, in a more cooperative mood.
Yes - your code snippet screws my system - you are right and I was wrong.
FWIW, if I understand you correctly, the THC requirement looks like it was completely misunderstood. YES - the Z needs to be controllable in real-time along side a running gcode program - BUT NOT BY GCODE.
Similarly, the output control I suspect was Art's "special" way of activating a laser WHILST motion was in "constant velocity" - an E code if I remember correctly. Yuk!
Like you Ray - I'm a pro - and it sounds like a classic mistake has been made over and over again. The user will ask for an implementation of something - and I will say - don't tell ME how to change the system to do something that will do what you THINK you want. Tell me what you want to achieve and I'LL tell YOU how I'LL specify it.
Question: Can you let me insert gcode into the buffer so I can do THC?
Answer: FO - now tell me what you ACTUALLY want to HAPPEN and I'll tell you how I'LL do it - if it's feasable.
Finally - your macro. Personally I would boiler plate it a bit more. One example: You code "G90" but don't wait on isMoving(). This I've found CAN lead to problems - yes I know it shouldn't - but it CAN. It's not just movement commands that need it IN MY EXPERIENCE - as Terry would say - your milage may vary.
Ian
-
Ian,
I'm not trying to pick a fight, and I"m sorry if it seemed that way. I just want to make sure you know where I'm coming from, since you seemed to be objecting to some of the changes Brian was making on my behalf. I think we're actually pretty much on the same page here. I agree spamming Mach with JogOffs is not good, and it was inadvertent, but who would've ever guessed it would cause G31 to misbehave???
I certainly never suggested doing away with concurrency, but right now, you get it whether you want it or not, and protecting yourself from it often takes a LOT of effort, and, as I'm finding, sometimes even then is not possible to make it really bullet-proof. That's exactly the opposite of the way it should be. Operation should be simple, obvious even, and robust, so even a newbie can make basic operations work easily. Then, if you WANT multiple threads and concurrency, a means of getting it should be provided, but ONLY when asked for. That way, it works easily for the novices, and it provides the advanced features us more advanced users want. Everyone wins. But now, trying to take advantage of seemingly simple and straight-forward functions can lead to hours of needless debugging. One thing I've learned in 30+ years of designing chips, boards, and software for complex systems is: If it's complicated, you haven't designed it right. When debugging becomes like squeezing a balloon, and making a small change in one area makes something in a seemingly unrelated area break, then you're working with a badly architected system.
Yes, now that I truly understand how G-code makes it from a script into the motion engine, I would absolutely surround every, single G-code command with While Ismoving loops. Years ago, when I wrote that code (That was actually my very first Mach3 macro), I foolishly believed that G-code commands all went into the same execution queue, and would, at least, always be executed in order. Silly me! I also thought IsMoving would actually indicate that the machine was moving, and not simply that there were still G-code commands waiting in the buffer, and would have no meaning when executing a G90! Where do I get these crazy ideas? :-)
Regards,
Ray L.
-
Ray - good luck with your endeavours - I'm sure we'll all benefit from them.
Cheers
Ian
-
Similarly, the output control I suspect was Art's "special" way of activating a laser WHILST motion was in "constant velocity" - an E code if I remember correctly. Yuk!
Ian,
Just because you don't want to use it does not mean it is Yuk!.
I was really happy with the operation of the combination E1P0 / E1P1 until a Mach revision screwed it all up. :'(
Tweakie.
-
Just because you don't want to use it does not mean it is Yuk!.
I was really happy with the operation of the combination E1P0 / E1P1 until a Mach revision screwed it all up. :'(
LOL - just when I thought it was safe to get back in the water...
Oyoyoy! - I wasn't saying Yuk! to the REQUIREMENT - I was saying Yuk! to the method of IMPLEMENTATION. The very fact that the IMPLEMENTATION was so easilly broken in subsequent releases kind of makes my point I think. That is exactly the point that Ray and I have been banging on at each other about until we realized we weren't a gazillion miles apart after all.
Cheers
Ian
EDIT: To be fair, this requirement is probably a bit of a doozy to implement and possibly the E code idea is not as bad as some IMPLEMENTATION methods we've discussed. The requirement as we know is to somehow switch on the laser DURING movement. It has to be able to come on/off during any CV blending that's going on without affecting it AFAIK. Clearly a CB macro via M code is inapropriate in it's current implementation. I THINK the way it's been done is that Mach is fooled into thinking it's a (albeit zero length) motion code and CV therefore includes it in the "blender". Please don't kill me if I'm wrong ;D
-
Thanks Ian. ;D ;D
(The big advantage of the E code was that it would switch the selected output pin concurrent with the start (or end) of axis movement).
Tweakie.
-
Guys after careful thought I believe that the current macro/CB system is a blessing AND a curse. Not many other controllers GIVE the OP this much POWER and flexability. That could be GOOD and that could be BAD.
I can SEE the NEED for both systems Mcode and CBmacro . I have moved all motion Mcodes that I could over to SUBprograms BUT it has problems as well (;-).
I think the only GOOD solution to this is to patch it up as best as can be done . THEN it will be what it will be. I fear any attempt at a major retrofit will just BUST everything in a backwards compatability manner and do little to make it better.
SO maybe the new MACHv4 can start fresh and provide a Mcode enviroment AND A SEPERATE CBmacro enviroment. That way we still have the best of each world.
Just a thought(;-) TP