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?

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.