Hello Guest it is April 22, 2019, 04:51:15 AM

Author Topic: VB Is Laughing At Me....  (Read 15875 times)

0 Members and 1 Guest are viewing this topic.

Re: VB Is Laughing At Me....
« Reply #20 on: April 29, 2009, 02:39:29 PM »
Ray,
I like that reason - I've used it a lot over the years...  ;)

I am not sure how to find the state info to save - but I guess I'll go looking to see if/how it can be done.
I just got a probe - so I'm prowling around posted macros to see what other people have done & what'd avail I can plagerize. My old programming days make me like routines that leave things as they found it. Seeing your macros made me think about GCode states.

Hum, I guess the next steps for me are to
1) list the states I might alter
2) figure out how to get get what they are (I'm not sure mach has a way to do that, it may, I just don't know enough yet to know)

Some things I am not sure I would want to save and restore - like active canned cycles - might be safer to just always cancel them -

Here's an idea: I wonder it people would find it useful if mach had a "Push state" and "Pop state" facility...?
Some things I am not sure I would want to save and restore - like active canned cycles - might be safer to just always cancel them (?) - I need to noodle these things a bit.
(Input from others is welcome)

Dave


Dave,

I think having save/restore state functions built into Mach would be really nice - save a lot of potential grief.  I would think you could roll your own, but it would take some research.  What I've found writing macros for Mach is you spend most of your time figuring out what the OEM codes *really* do, and how they behave - Far too often, they simply don't do what their names imply.  Some actual documentation would work wonders here.  Fortunately, there isn't a great deal of state to preserve, so I would think in a few hours you could track down all the OEM codes needed, and write the functions.

Regards,
Ray L.
Regards,
Ray L.
Re: VB Is Laughing At Me....
« Reply #21 on: May 01, 2009, 03:11:46 AM »
Hi Ray,

I'm puzzled by your use of semiphores in the macro code.

As I thought about it, I think that Mach runs macros as a single thread. So I'm not sure how one could ever get the parallel execution of the macros that the semiphores seem to imply to me.

I'm also thinking that if this is necessary, there is a timing hole (since I don't see a way to get the DRO value used for the semiphore count and increment/decrement it in an atomic operation).

I suspect I have not understood an assumption your code makes...

Could you help me understand what you are protecting against with the use of semiphores in your macros?

Dave
« Last Edit: May 01, 2009, 02:37:47 PM by mvcalypso »

vmax549

*
Re: VB Is Laughing At Me....
« Reply #22 on: May 01, 2009, 02:13:50 PM »
DAve, I have always found it BEST rather than trying to record and restore every known state to just clean the slate and restart what is needed.  Most CNCs have a very good memory(;-) of states wheither yoou do or don't. Also seems to use less resources and less code required.

Just a thought, (;-) From a non programmer (;-) TP
Re: VB Is Laughing At Me....
« Reply #23 on: May 03, 2009, 06:48:27 PM »
Hi Ray,

I'm puzzled by your use of semiphores in the macro code.

As I thought about it, I think that Mach runs macros as a single thread. So I'm not sure how one could ever get the parallel execution of the macros that the semiphores seem to imply to me.

I'm also thinking that if this is necessary, there is a timing hole (since I don't see a way to get the DRO value used for the semiphore count and increment/decrement it in an atomic operation).

I suspect I have not understood an assumption your code makes...

Could you help me understand what you are protecting against with the use of semiphores in your macros?

Dave


Terry,

The primary purpose is to make execution sequential.  Without the semaphores, the high level macros could not tell when the low-level ones had completed, and would resume execution *before* the low-level ones were done.  In theory it should not happen, but I can assure you it did.  I could find no other way to make them work correctly.

Regards,
Ray L.
Regards,
Ray L.
Re: VB Is Laughing At Me....
« Reply #24 on: May 03, 2009, 08:24:36 PM »
Hi Ray,

I'm puzzled by your use of semaphores in the macro code.

As I thought about it, I think that Mach runs macros as a single thread. So I'm not sure how one could ever get the parallel execution of the macros that the semaphores seem to imply to me.

I'm also thinking that if this is necessary, there is a timing hole (since I don't see a way to get the DRO value used for the semaphore count and increment/decrement it in an atomic operation).

I suspect I have not understood an assumption your code makes...

Could you help me understand what you are protecting against with the use of semaphores in your macros?

Dave


Terry,

The primary purpose is to make execution sequential.  Without the semaphores, the high level macros could not tell when the low-level ones had completed, and would resume execution *before* the low-level ones were done.  In theory it should not happen, but I can assure you it did.  I could find no other way to make them work correctly.

Regards,
Ray L.

Ray,
FYI - it was me (Dave) not Terry that asked about the semaphore usage - Since Terry stated (proudly  :D ) not to be a programmer, I suspect Terry is not a semaphore kind of guy.  ;D

I'll believe that you found that you had to have them - and I admit that this worries me more than a little bit...

Since the cypress VB language offers no support for any type of critical section sync/locking mechanisms (at least not that I can find in the Cypress VB manual), this tells me that the use of VB level semaphores used can reduce the chance of failure, but not eliminate it (without lower level support for critical section locking, there are likely timing holes in the VB "semaphore code").

Not to play chicken little, but between nested macros, calls to Gcode for movement (which either falls thru or gets interrupted in the common wait for movement to end code), and no synchronization primitive support - this sounds like a recipe for dangerous, intermittent failures.

IF Mach is really mutli threading macro execution, then I fell rather distrustful of any nested macro scenarios.

To figure this out, I'd really like to know some key things, such as:

[I suspect these are Art or Brian questions... of course I get curious about this the week both Art and Brian were talking about vaction... :-(  ]

1) For Mach's gcode language, what modal group are user macros considered to be part of? (as given in the gcode modal group precedence table in the mach gcode reference chapters of the using mach manual).
This is important as there is no spec I can find that determines when a user M code word (i.e. user macro) executes within a block compared to other words in the block).

2) How does mach map execution threads to user macros?

Ray, did you ever see out of sequence operation within a single macro or only between nested macros?

Dave

vmax549

*
Re: VB Is Laughing At Me....
« Reply #25 on: May 03, 2009, 08:50:19 PM »
Semaphore ? That is one of those chocolate covered marshmellows right?  (;-)

A while Back Brian redid the VB and split it out into its own thread. He also revamped mach to make SURE it ran the macros to completion before turning it back over to control.

The old way manual" WARNS" not to nest macros (;-) as it is unclear of the results.

MAch does nesting very well in Gcode.   Macros ??? not brave enough these days to test(;-) BUT I guess I will now.

MACH handles macros much better since Brian redid the code.

AND you are correct I don't have a clue what a Semaphore is. BUT I bet I will tommorrow (;-)

User Macro should be in the same group as system macros (Mcode) I know that Mach will NOT let you run 2 on one line and gives the error  of both being in the same group


(;-) TP
« Last Edit: May 03, 2009, 08:57:29 PM by vmax549 »
Re: VB Is Laughing At Me....
« Reply #26 on: May 03, 2009, 10:54:30 PM »
Ray,
FYI - it was me (Dave) not Terry that asked about the semaphore usage - Since Terry stated (proudly  :D ) not to be a programmer, I suspect Terry is not a semaphore kind of guy.  ;D

I'll believe that you found that you had to have them - and I admit that this worries me more than a little bit...

Since the cypress VB language offers no support for any type of critical section sync/locking mechanisms (at least not that I can find in the Cypress VB manual), this tells me that the use of VB level semaphores used can reduce the chance of failure, but not eliminate it (without lower level support for critical section locking, there are likely timing holes in the VB "semaphore code").

Not to play chicken little, but between nested macros, calls to Gcode for movement (which either falls thru or gets interrupted in the common wait for movement to end code), and no synchronization primitive support - this sounds like a recipe for dangerous, intermittent failures.

IF Mach is really mutli threading macro execution, then I fell rather distrustful of any nested macro scenarios.

To figure this out, I'd really like to know some key things, such as:

[I suspect these are Art or Brian questions... of course I get curious about this the week both Art and Brian were talking about vaction... :-(  ]

1) For Mach's gcode language, what modal group are user macros considered to be part of? (as given in the gcode modal group precedence table in the mach gcode reference chapters of the using mach manual).
This is important as there is no spec I can find that determines when a user M code word (i.e. user macro) executes within a block compared to other words in the block).

2) How does mach map execution threads to user macros?

Ray, did you ever see out of sequence operation within a single macro or only between nested macros?

Dave


Dave,

I only saw the problem with nested macros.  I simply could not find any other reliable means of ensuring a macro ceased execution until *all* lower level macros completed.  If you look at how I did the semaphores, I don't think there is any way for the nested macros to complete out of order, unless a low-level macro executes non-sequentially, which I cannot believe is possible.  With the semaphore mechanism, when a lower-level macro is invoked, it cannot do anything else until *all* lower-level macros have completed execution.  I've run a lot of hours with these, and never seen a single hiccup.  I did see all kinds of really squirrelly behavior before I put this mechanism in.  It did behave exactly as if each macro was running in its own unsynchronized thread, as goofy as that sounds.

Regards,
Ray L.
Regards,
Ray L.
Re: VB Is Laughing At Me....
« Reply #27 on: May 04, 2009, 12:31:50 AM »

Hi Terry,
Well, it's sunday eve, I've just completed 4 days of working on the boat and playing with the mill... and I may not write books as Art says he does, but I feel a minor chapter flowing to my finger tips...  ;)

I'm afraid this topic will get complicated...

Semaphore ? That is one of those chocolate covered marshmellows right?  (;-)

Close enough for some kinds of work!  ;D

A while Back Brian redid the VB and split it out into its own thread. He also revamped mach to make SURE it ran the macros to completion before turning it back over to control.

The old way manual" WARNS" not to nest macros (;-) as it is unclear of the results.

Yes - I remember wondering about that - in particular because I had been bit by my attempts to nest macros several years ago.
I am beginning to suspect that what mach does is to run a single macro as a single, sequential thread. However, if a macro calls another macro, I suspect that the 2nd macro gets its own thread (I'm not positive, but that would explain what Ray is seeing). I'm guessing that when the 2nd macro is called, mach just sees a macro start - and hence the 2nd macro runs asynchronously to the 1st macro.

If this is what is happening, we are now in the world of multi-tasking, multi-threading, multi-processing programming - topics that are not for the faint of heart and (IMHO) not suited for VB as a language tool.

...AND you are correct I don't have a clue what a Semaphore is. BUT I bet I will tommorrow (;-)
Uh, I hesitate to point you here - but if you really want to get the concepts, you can try
http://en.wikipedia.org/wiki/Semaphore_(programming)
for an intro.

[personal note: I got a kick out of this reference as it mentions algol68 - the base for the languages I used for writing operating systems for Burroughs mainframes in the '70s - dang that takes me back a ways...]

User Macro should be in the same group as system macros (Mcode) I know that Mach will NOT let you run 2 on one line and gives the error  of both being in the same group

This is the one that is the hard topic. I fear I must claim that what you have said is to simplistic to be correct (I'm not meaning to be offensive, it's just that life is not that simple for this topic)

In the prior (1.84) mach manual (section 10.6), the section on gcode reference gives the table of groups for the mach Gcode language. The tables appear to be a partial copy from the orig NIST (old EMC?) documents. Alas, this section of the prior manual appears to have been considered reference material and did not make it to the latest Mach "install and config manual". I'm still hoping that the rest of the documentation will get updated also.

See, not all Gcode words or mcodes belong to the same group. The group determines what words can be in a block together ( a block is what most people think of as a line of gcode in Mach)  - and what order the words within a block are executed. Not all mcodes belong to the same group - so there is no single "system macros" group in the (incomplete) formal syntax in the mach manual.

In fact, not all mcodes are equal within a block - for example: some are specified to execute at the start of a block, some at the end of a block.
(Art and I had some detailed  discussions of this a couple of years back and he fixed some bugs wrt to this ordering).

If you want more info and an explanation of these details, I suggest SMID's CNC programming book, chapter 8 and 9 in the 2nd edition (not sure of the ref for the 3rd edition). SMID is Fanuc, not Mach - but the concepts are well explained in the book - better than I can do here on the fly.

A key problem is that the available mach language syntax documentation is incomplete. So, when I hit something like this, it is real hard to figure out what mach thinks should be happening (I usually know what I think mach should be doing, but that does not mean mach agrees with me!).

With that as background, the problem at hand is that mach invented these user macros thingies (another tech term  ;) )- and I know of no documents that spec how they relate to the more common M and G codes wrt execution ordering etc.
I usually avoid this topic by never using a user written macro except as a standalone word within a single block of gcode.

I guess I had forgotten that the macro threading was redone - so early in this thread, I was assuming a single thread and could not see why Ray needed the semaphores. Now that I see that there is some level of parallel execution possible, I see potential problems. Not only do different macros seem to run in different threads, but I am wondering about what happend when a macro used VB to call into the gcode interperter... You know that sign that says "warning, there be dragon's here..."?

All this leads me to want to know the details of the language spec and how macros where inserted into the syntax & group priority.

I have a suspicion that timing holes due to multi-threading may be the cause of occasional machine weird behavior - or maybe not - I can't really say without learning more from Art/Brian.

Finally, using semaphores requires that some operations (getting semaphore counts and changing them) be accomplished in a single, atomic, non-interruptable operation. Alas, that is a facility that VB does not supply. This is the reason I am skeptical that Ray's nested macros will **** always**** work correctly. (Not Ray's fault BTW, it's a programming limitation of VB).

Dave





vmax549

*
Re: VB Is Laughing At Me....
« Reply #28 on: May 04, 2009, 11:27:31 PM »
DAve thanks that adds to the edumacation.

I have often questioned the way MAch handles Macros and gcode mixed as both seemed at one time to go seperate ways at times. Since the rewrite VB has behaved quite well as best I can tell. No real surprises in VB lately

IF we had true conditional gcode there wouldd be little to use VB for. But brian explained why it won't work in MACH as is. It had to do with the way mach handles the VB doing gcodes verses the straight gcode. I THINK(;-)

HOPE fully in the future rework of mach these things will be fixed and MAch will run as the conventional controllers do.

(;-) are you sure Art invented the macro??  programable Mcode and gcodes have been arounfd for a while now(;-)

(;-) tp

Re: VB Is Laughing At Me....
« Reply #29 on: May 05, 2009, 12:26:38 AM »
(;-) are you sure Art invented the macro??  programable Mcode and gcodes have been around for a while now(;-)

(;-) tp

Hi Terry,
Whoops, I probably should have been more specific - I didn't mean that Art invented the concept of a user macro, but I did think he invented Mach's macros and the use of VB in mach as the user macro implementation language.

The history as I've heard it (in 2nd & 3rd hand bit and pieces) is that Mach (or whatever mach was called originally) and EMC are descendants of the NIST RS274 gcode interpreter.  I don't remember the NIST interpreter including user defined M codes (though it's been a while since I found and first read the NIST documents).

So I **assume** Art added the Mach user macro facility. Who ever added it, had to decide how integrate the facility into the existing gcode language definition - what I'd like is to know the syntax spec that was used to do that (assuming such a document exists).

It would be fun if someday when Art is in a verbose mood, if he would jot down an outline of Mach's history.

Dave