Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: HimyKabibble on March 21, 2009, 09:26:37 PM
-
I'm writing a bunch of Mach macros lately, to automate common tasks. But I'm finding myself scratching my head at times. The below code does not execute correctly. It calls the M900 macro, which works perfectly when called directly from button scripts. The M900 macro uses DRO 1105 to tell it which axis to probe (0=X, 1=Y, etc.), and DRO 1106 tells it which direction to probe (1=Plus, -1=Minus). When I run the code below, the M900 macro does run, but it gets the wrong parameters - I'm telling it to probe X in the Plus direction, and that is what is displayed by the code below, but the same printout code in the M900 macro shows the parameters it receives tell it to probe Y in the Minus direction. How can this be?
MacroParameter1DRO = 1105
MacroParameter2DRO = 1106
EdgeFindMacro = "M900"
XProbeDirection = GetDRO(MacroParameter1DRO)
' Probe first in X
SetDRO(MacroParameter1DRO, 0)
SetDRO(MacroParameter2DRO, XProbeDirection)
' Show the parameters we're passing
AxisName = Chr(Asc("X") + GetDRO(MacroParameter1DRO))
If GetDRO(MacroParameter2DRO) = 1 Then
Direction = "+"
Else
Direction = "-"
End If
Code "(Probing " & AxisName & Direction & ")"
Sleep 1000
' Set the "busy" LED
SetUserLED(200, 1)
Code EdgeFindMacro
' Wait until EdgeFindMacro completes, clearing UserLED 100
While GetUserLED(200) = 1
Sleep 100
Wend
Regards,
Ray L.
-
Hey Ray,
Your not calling the DROs correctly to load the inforamtion, also there are two types of DROs in Vb
UserDROs and OEMDros(some OEM dros just use the Set or GetDRO: (changes in bold)
MacroParameter1DRO = GetUserDRO(1105)
MacroParameter2DRO = GetUserDRO(1106)
EdgeFindMacro = "M900"
XProbeDirection = GetUserDRO(MacroParameter1DRO)
' Probe first in X
SetUserDRO(MacroParameter1DRO, 0)
SetUserDRO(MacroParameter2DRO, XProbeDirection)
' Show the parameters we're passing
AxisName = Chr(Asc("X") + GetUserDRO(MacroParameter1DRO))
If GetUserDRO(MacroParameter2DRO) = 1 Then
Direction = "+"
Else
Direction = "-"
End If
'Code "(Probing " & AxisName & Direction & ")"
Code ("Probing Axis: ") & AxisName & " Direction" & Direction
Sleep 1000
' Set the "busy" LED
'SetUserLED(200, 1) 'Uleds are from 1000-2255
SetUserLED(2000, 1)
'Code EdgeFindMacro
Code "(EdgeFindMacro)"
' Wait until EdgeFindMacro completes, clearing UserLED 100
While GetUserLED(2000) = 1
Sleep 100
Wend
-
Poppabear,
I've tried that, and, if anything, it made things worse. My understanding (perhaps wrong....) is that UserLEDs have OEM codes from 1000 up, buy if you use Get/SetUserLED to access them, you use the number - 1000. On the DROs, GetDRO seems to work with ANY DRO number, whether OEM or User. I do wish this stuff was actually documented, as the information available is cryptic, and often contradictory.
Regards,
Ray L.
-
HIYA RAY, Welcome to the been laughed at by MACH club. (;-)
Could you give a brief explanation of what you need the macro to do.
Do you need DROs? Do you have them on a page for veiwing or could Vars be used.
I "think" I see your problem but need an explanation of what you think the code is suppose to do to verify it.
NOTE: There may be an easy way to do it.
Just a thought, (;-) TP
-
OK, I did some experimentation, to see how these things really work. Here's what I've found:
For LEDs, unless I'm missing something, the only Set method we have is SetUserLED. SetLED and SetOEMLED just throw syntax errors. Similarly, GetLED seems to not throw a syntax error, but also doesn't seem to actually do anything. GetOEMLED and GetUserLED appear to be identical, other than their names. Either seems able to read any LED, and both appear to expect "User" LEDs to be numbered above 1000.
For DROs, I see no difference between SetOEMDRO/GetOEMDRO and SetUserDRO/GetUserDRO, and both appear to expect "User" LEDs to be numbered above 1000. Any DRO written by one, can always be read by the other. SetDRO/GetDRO has me a little confused, as it seems to access a different "space" from the other two. i.e. - A DRO written by SetOEMDRO or SetUserDRO cannot be read by GetDRO, and vice-versa.
So, what, exactly, is the difference between all these, and why are there seemingly identical functions with different names?
Regards,
Ray L.
-
HIYA RAY, Welcome to the been laughed at by MACH club. (;-)
Could you give a brief explanation of what you need the macro to do.
Do you need DROs? Do you have them on a page for veiwing or could Vars be used.
I "think" I see your problem but need an explanation of what you think the code is suppose to do to verify it.
NOTE: There may be an easy way to do it.
Just a thought, (;-) TP
Terry,
I *think* I have it working, and the problem does appear to be confusion over when/where/how to use the various LED and DRO functions. Near as I can tell, there is no reason to ever use SetDRO/GetDRO. I believe whatever they can do, can be done through SetOEMDRO/GetOEMDRO or, just as well, SetUserDRO/GetUserDRO. Likewise, I was led astray by some of the information on the Wiki, which suggested using SetUserLED/GetUserLED use LED numbers from 0 to 255, which is not correct.
Regards,
Ray L.
-
(;-) Ray the syntqx has been modified over the years to fit some purposes only known by ART. Maybe one day he will take time to write the wizards manual for MACH.
UNless you need to SEE the dros on a screen I do NOT use them to store values. I use SYSTEM Vars instead. We also have VARs 500-600 that are persistant if needed.
What I found using DROs is somewhere that DRO may end up being used by something else as well AND IT WILL MAKE YOU PULL YOUR HAIR OUT trying to figure out where the phantom values keep coming from.
I have had it happen enough to know better know.
Let me know if you can't get it to work correctly .
Just a thought(;-) TP
-
Terry,
Thanks, it is all behaving now. I've written a whole pile o'macros today, and all are now working fine. I wrote nice, clean macros for doing edge, corner and center finding, and aligning a vise, or similar object, to the table, as well as one for re-mapping buttons on the ShuttlePro on-the-fly.
I get the impression there was an intent there to re-think the macro interface, and make it more regular and consistent. That would explain the User/OEM stuff. But obviously only the interface was defined, with no supporting functionality, and the existing macros use a mish-mash of different methods of access. There's a whole section in the "manual" listing deprecated functions, most of which are used in the macros that ship with Mach.
Regards,
Ray L.
-
(;-) Ray the syntqx has been modified over the years to fit some purposes only known by ART. Maybe one day he will take time to write the wizards manual for MACH.
UNless you need to SEE the dros on a screen I do NOT use them to store values. I use SYSTEM Vars instead. We also have VARs 500-600 that are persistant if needed.
What I found using DROs is somewhere that DRO may end up being used by something else as well AND IT WILL MAKE YOU PULL YOUR HAIR OUT trying to figure out where the phantom values keep coming from.
I have had it happen enough to know better know.
Let me know if you can't get it to work correctly .
Just a thought(;-) TP
Terry,
I'm confused about what you call "System Vars". You mean using SetParam/GetParam? The documentation makes it sound like those are limited to pre-defined variables. Is that wrong?
Regards,
Ray L.
-
HIYA RAY, No I use the get/setVAR Or some call them Gcode Vars or some call them System vars. Last I remember there are about 10,320 of them out there. Some are used for Gcode, some for SYSTEM functions and some are persistant( user use) some are for retaining fixture settings etc.
I'll try and find a listing of the Param & Vars available for us. That way we can at least write it down somewhere.
I use macros a lot myself to automate functions such as Bolthole circles, probing, Cord rotation, S/n engrave (consectutive), Cutting circles, thread milling, etc.
There is also a side of GCODE call parametric programming that you would probably like as well.
It would be NICE to start a MACH TOOLBOX online to store usefull macros for us to swap ideas. (IF you are interested) (;-)
Just a thought (;-) TP
-
OK there is a list of some Numbered parameters(VARS) I think we should get the wordage correct. There rest of the world knows them as system parameters I don't know why we call them VARs.
Upper range(system) starts at about 5000 and goes up they are listed in the mach manual section 10.1 illistration
500-600 are user parameters and are persistant
Gcode Parameters start at 1
-
HIYA RAY, No I use the get/setVAR Or some call them Gcode Vars or some call them System vars. Last I remember there are about 10,320 of them out there. Some are used for Gcode, some for SYSTEM functions and some are persistant( user use) some are for retaining fixture settings etc.
I'll try and find a listing of the Param & Vars available for us. That way we can at least write it down somewhere.
I use macros a lot myself to automate functions such as Bolthole circles, probing, Cord rotation, S/n engrave (consectutive), Cutting circles, thread milling, etc.
There is also a side of GCODE call parametric programming that you would probably like as well.
It would be NICE to start a MACH TOOLBOX online to store usefull macros for us to swap ideas. (IF you are interested) (;-)
Just a thought (;-) TP
Terry,
I'm always happy to share what I've done. I've sent many of my drawings and DXFs out to lots of people.
I kinda like the macros I did yesterday. I made them hierarchical, so there's virtually no duplicated code. I have a single edge finder macro, that provides the core functionality for all the others, then higher-level ones that use that one to perform all the other functions, so most are just a few lines of code. So, for instance, I have 5 macros for edge finding (X+, X-, Y+, Y-, Z-), then one that finds the mid-point between two edges, and one that uses that one for doing center-finding in holes and pockets. Lots of very simple, very small files, but lots fo good functionality. Most important of all *NO* frickin' button scripts!
Regards,
Ray L.
-
Terry, the toolbox is a good idea. I can set up a child board of VB and make it like the members docs board so that only mods and admin can post the donations to leave it very clean. Only a brief description of what the script does, how to use it and the code in a text attachment. What do you think? I may be able to add pools that all members could vote as to how useful, accurate, etc. the script is. Will have to look more at the pool option if you think it is a good idea.
Brett
-
Brett,
Here's something to get you started - the macros I wrote yesterday.
Regards,
Ray L.
-
I'll start digging out the old macros and get them cleaned up. I have a good probing array macro for inside /outside probing a 2d object. Heck I think I even wrote the manual for it(;-)
I think it will be a great idea. Examples of code are a great way to help others learn to create their OWN macros for their specific needs.
Would also be nice to include the actual macro.m1s for those that cannot do the coding.
(;-) TP
-
Would also be nice to include the actual macro.m1s for those that cannot do the coding.
Exactly Terry. If this isn't started by Saturday, please bump this thread for me.
Thanks,
Brett
-
Bret the ball is in your court(;-) I have already started cleaning up macros and writing "how tos" for them. I noticed there wa a MACH TOOL BOX showed up in the downloads section as a dautherboard is that where we are supppose to drop them off??
(;-) TP
-
Hi Ray,
I took a look thru your probing macros this evening - I like the general modularity.
I do have a question: I applaud the programming principal to save state on the way in and restore it on the way out of the low level macros. I see the code doing this for inc/abs mode and feed rate. However, the macros issue GO codes - which is modal change to the control - so the control will be in a G0 rapid state when the macrso exit (even if it was not when the macro was entered).
Is there a reason you did not grab the rapid/feed movement state up front and then also restore it on the way out?
Dave
-
Hi Ray,
I took a look thru your probing macros this evening - I like the general modularity.
I do have a question: I applaud the programming principal to save state on the way in and restore it on the way out of the low level macros. I see the code doing this for inc/abs mode and feed rate. However, the macros issue GO codes - which is modal change to the control - so the control will be in a G0 rapid state when the macrso exit (even if it was not when the macro was entered).
Is there a reason you did not grab the rapid/feed movement state up front and then also restore it on the way out?
Dave
Dave,
There is a reason, though it's not a very good one - I just didn't think of it! :-) I whipped those very quickly ( just a few hours), and they're the first significant Mach macros I've written.
How do I detect the current G0/G1 state?
Regards,
Ray L.
-
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
-
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.
-
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
-
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
-
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.
-
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
-
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
-
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.
-
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
-
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
-
(;-) 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
-
IT would be nice if Art would just write a book(;-)
I think we are just now hitting the limitations of how it was acutally done. I believe art had to bend the laws of windows to make it all work with the LPT port.
NOW that a lot of users are reaching the power user levels of cnc those limits are becoming a roadblock.
Also with the advent of low cost controller boards it is time for Brian to think about expanding MACH into the next generation where the limits of the LPT driver do not exist.
THen if needed the lpt could be used as a plugin like all other controllers.
BUT that is going to take some time and energy. Brian will have to commit to finishing up and capping the features of MACH3 then let mach mature as a great low cost solution for the hobby/lowend cnc world.
THen Brian will have the time to commit to a new MACH solution.
I know easier said than done(;-)
Just some thoughts, (;-) TP
-
Hi Guys:
Just got back from Vacation.. Ill try to answer some of your questions..
History:
Mach started as EZ-CNC, a very bad program that used a timing loop as its timer.. ( for x = 1 to x..) type of thing. Pretty bad.
It was then I was challenged to do a timer for Windows that coudl do 8Khz, so I wrote the main virus to do the Windows takeover and timing.
It worked OK, and in the end became Master1, internally used only and b y the time I got it right, ( for Win98) it was MAster5. There was no XP at the time.
As XP started to Beta, I foudn I could do 20Khz in XP, and much more stable, so I wrote Mach1. IT has unique dual screen selection, with a top and bottom selector,
and it was getting popular as I determined a screen designer was necessary. SO it became Mach2, the first of the Screen design versions. That became VERY popular and
started the entire development path. It was based on EMC's RS274 interpreter, as well as the Cannon methodogy and the trajectoiry planner. BUT, since I used a very special
buffereing algorithm, the trajectory planner became very much different very quickly and became integrated into the Main components of Mach3's screen control and staging
loops. The RS274 stayed pretty much the same as EMC with the exception of various features that were requested and many canned cycle changes.
As Mach2 became too complex to update very well, it morphed to Mach3, its current version name, but quite different from the current code base as it is today. Todays code
contains allot of class redefinitions, and doesnt work the same way in terms of flow as the original. Things such a s VB macr's , Brains, and variosu interpreter functions makes its interpreter
quite different from EMC in operation.
VB macro's now, work much different than even a year agao, they are more linear now, and in fact one I think can call another with no semaphore requirement, as MAch3 only processes them one at a time.
Easy to say though as you can fool almost anythign if you hav eenough power, and I always tried to gove as much as I could. Brian has continued that philosophy,
Plans are underway to see a divorce from PP reliance and create a more monolithic program with the PP as a simple plugin. Obvious advatanges there, unknown time frames though..
Yell if your curious, Ill fill in details as I can.. Im on a dozen projects so I cant evaluate code or trace macro's for you, but I can tell you anythign I know of the internals and how they may
interact with your logic ..
thx
Art
-
VB macro's now, work much different than even a year agao, they are more linear now, and in fact one I think can call another with no semaphore requirement, as MAch3 only processes them one at a time.
Art,
Gotta strenuously disgree with you on this one. Try the folliowing - create two macro files:
M1000.m1s:
Message "M1000.m1s Start"
Sleep 2000
Code "M1001"
Message "M1000.m1s Done"
M1001.m1s:
Message "M1001.m1s Start"
Sleep 2000
Message "M1001.m1s Done"
Sleep 2000
Then type M1000 into MDI. If nested macros execute sequentially, as you suggest, and as logic would suggest, the status line should show "M1000.m1s Start", then "M1001.m1s Start" two seconds later, then "M1001.m1s End" two seconds after that, then, finally, "M1000.m1s End" two seconds after that. That ain't even remotely what happens....
I put the semaphores in my macros because I simply could not get it to work any other way. This really should be fixed, or at least documented.
Regards,
Ray L.
-
OK, I gotta ask. What is a semaphore?
-
OK, I gotta ask. What is a semaphore?
http://lmgtfy.com/?q=semaphore
-
OK, I gotta ask. What is a semaphore?
Please see reply #27 earlier in this thread...
Dave
-
Ray:
According to my Win7 installer, I have somethign liek 20 hours till I can do a test on this on my system.. :) , so what DOES happen? Im curious?
Art
-
Ray:
According to my Win7 installer, I have somethign liek 20 hours till I can do a test on this on my system.. :) , so what DOES happen? Im curious?
Art
Art,
It does exactly what you'd expect it to do if the M1001 macro is launched in a separate, parallel thread. The messages come out:
M1000.m1s Start
M1000.m1s Done
M1001.m1s Start
M1001.m1s Done
Regards,
Ray L.
-
Ray:
yeah, I should have expected that. See its the way it buffers commands. When M1000 starts, that macro can add whatever it likes to the stream, BUT the macro commands added dont get done untill
Mach3 identifies that the first macro is finished, then the secondary command buffer runs whats in it, so while M1000 does add the command M1001 to the secondary command buffer, it wont actually
execute the command until it senses the M1000 has completed, then the M1001 will run as its holding in the secondary buffer...
I suspect this is conditional for macro calls only. Code calls for other Gcode commands will ( or should ) execute immediatley before the next command in the VB macro runs. I do think work is being done
to change this and Ill tag this to discuss with Brian to see where it s going to go. There are some tricky technical reasons for that.. I just cant recall them at the moment, but I may be able to explain it better
when I discuss it with Brian, he's really the expert on where thats at, he did the multi threading of the VB,and very well I might add, but I think the macro calling macro was special for a very good reason.. Ill see if I can find out what that was for you.. Im a little rusty yin that section at the moment as I havent studied up on the new threading algorithms. Has somethign to do with the non-grouping of user macros as I recall..
Art
-
Ray:
yeah, I should have expected that. See its the way it buffers commands. When M1000 starts, that macro can add whatever it likes to the stream, BUT the macro commands added dont get done untill
Mach3 identifies that the first macro is finished, then the secondary command buffer runs whats in it, so while M1000 does add the command M1001 to the secondary command buffer, it wont actually
execute the command until it senses the M1000 has completed, then the M1001 will run as its holding in the secondary buffer...
I suspect this is conditional for macro calls only. Code calls for other Gcode commands will ( or should ) execute immediatley before the next command in the VB macro runs. I do think work is being done
to change this and Ill tag this to discuss with Brian to see where it s going to go. There are some tricky technical reasons for that.. I just cant recall them at the moment, but I may be able to explain it better
when I discuss it with Brian, he's really the expert on where thats at, he did the multi threading of the VB,and very well I might add, but I think the macro calling macro was special for a very good reason.. Ill see if I can find out what that was for you.. Im a little rusty yin that section at the moment as I havent studied up on the new threading algorithms. Has somethign to do with the non-grouping of user macros as I recall..
Art
Art,
It would be really nice if there were a way to call a named macro, rather than just execute an M-code macro. It would sure help make it easier to do more structured, readable macros.
Regards,
Ray L.