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!
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