Hello Guest it is November 22, 2019, 10:15:52 AM

Author Topic: Macros And Buttons - Strangeness Abounds....  (Read 11049 times)

0 Members and 1 Guest are viewing this topic.

Re: Macros And Buttons - Strangeness Abounds....
« Reply #20 on: August 23, 2011, 06:52:44 PM »
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.
Regards,
Ray L.
Re: Macros And Buttons - Strangeness Abounds....
« Reply #21 on: August 23, 2011, 07:02:20 PM »
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.
Regards,
Ray L.
Re: Macros And Buttons - Strangeness Abounds....
« Reply #22 on: August 23, 2011, 07:03:53 PM »
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.
Regards,
Ray L.

Offline BR549

*
  •  6,916 6,916
    • View Profile
Re: Macros And Buttons - Strangeness Abounds....
« Reply #23 on: August 23, 2011, 08:58:13 PM »
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

Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: Macros And Buttons - Strangeness Abounds....
« Reply #24 on: August 24, 2011, 11:08:52 AM »
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
Re: Macros And Buttons - Strangeness Abounds....
« Reply #25 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.
Regards,
Ray L.

Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: Macros And Buttons - Strangeness Abounds....
« Reply #26 on: August 25, 2011, 03:55:14 AM »
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
« Last Edit: August 25, 2011, 04:10:30 AM by stirling »

Offline Tweakie.CNC

*
  • *
  •  8,009 8,009
  • Super Kitty
    • View Profile
    • Tweakie.CNC
Re: Macros And Buttons - Strangeness Abounds....
« Reply #27 on: August 25, 2011, 04:17:42 AM »
Following this with great interest guys.

Ray,

What version are you using please ??

Thanks,

Tweakie.
Success consists of going from failure to failure without loss of enthusiasm.  Winston Churchill.
Re: Macros And Buttons - Strangeness Abounds....
« Reply #28 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.
Regards,
Ray L.
Re: Macros And Buttons - Strangeness Abounds....
« Reply #29 on: August 25, 2011, 12:54:22 PM »
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.
Regards,
Ray L.