Macros And Buttons - Strangeness Abounds....

[stirling]

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

[HimyKabibble]

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.

[stirling]

Ray - good luck with your endeavours - I'm sure we'll all benefit from them.

Cheers

Ian

[Tweakie.CNC]

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.

[stirling]

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 

[Tweakie.CNC]

Thanks Ian. 

(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.

[BR549]

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