Machsupport Forum
Mach Discussion => VB and the development of wizards => Topic started by: flick on April 22, 2010, 10:16:45 AM
-
The value passed to Q seems to "cascade" down to R, and then persists if R is not specified in successive calls. Feature? Known issue? Already fixed?
-
I was playing around a little more with this today, and the cascading effect I thought I had seen yesterday is gone. The more I think about it, the more I think that I made it up by happenstance. Plus I was really tired. But the persistence is still there.
Whereas Param1() and Param2() always return -1 if P and Q, respectively, are left out of the macro call, Param3() will return whatever value was last used with R. It's even persistant between different macros.
-
I can confirm that. It seems to be a bug.
Test
'm1009 test macro
Message "" ¶m1 ¶m2 ¶m3
end
create macro then add params to the macro call. The values will show up in the mach message line. Then call the macro without params and it displays
-1,-1, what ever number that was in R.
-
I'd suspect that this is tied up with cypress enable's appaling stack handling which is and allways has been broken.
-
Is that also why we can't nest macro calls? It sure is tough to develop a general purpose macro library without nesting...
-
Is that also why we can't nest macro calls?
What happens?
-
HIYA Stirling, question ,there is a fellow doing probing of an engine intake ports. Can your crawler routine probe the inside of a 3d object such as a port?
-
HIYA Stirling, question ,there is a fellow doing probing of an engine intake ports. Can your crawler routine probe the inside of a 3d object such as a port?
Hi - It's basically a bed o' nails with the added benefit of only probing inside a prescribed boundary. As you know a standard or dumb bed o nails only probes inside a defined rectangle which can mean it spends an inordinate amount of time probing useless space. All I can sugest is your fellow gives it a whirl. Don't know if you've seen it but there's an Italian company in this thread www.machsupport.com/forum/index.php/topic,4352.msg97649.html#msg97649 (http://www.machsupport.com/forum/index.php/topic,4352.msg97649.html#msg97649) that has a couple of nice vids on their site and youtube of the routines in action.
Let me know how you get on.
Cheers
Ian
-
HUM there is really nothing to probe in the Z axis just a big hole. The area to probe would be in the X/Y directions and step down in z as it goes deeper into the port.
Your crawler routine works great but I don't think it will work in this application unless it could be modified to crawl the perimeter from the inside out then step down.
(;-) There IS a market for a PORT probing routine to do this IF you are interested.
I have seen your routine do the combustion chambers of the head, that IS a perimeter and bed of nails type of probing solution
Thansk
-
Is that also why we can't nest macro calls?
What happens?
Hrm, can't find it anymore, thought I'd read it wasn't allowed. Brain fart?
-
BR549 - hope you don't mind but I've replied to and copied your part of this thread to my probing thread. www.machsupport.com/forum/index.php/topic,4352.msg98537.html#msg98537 (http://www.machsupport.com/forum/index.php/topic,4352.msg98537.html#msg98537) Probably better to keep it in one place rather than mix toipics here.
Cheers
Ian
-
Hi Flick
Now you mention it I think I can remember it mentioned somewhere but can't recall the details. Either that or your "brain fart" is contageous - not a pleasant thought ;D
Cheers
Ian
-
http://www.machsupport.com/forum/index.php/topic,5806.10.html
This might point to it ?
-
From the aforementioned article by ART:
MACROS
Mach3 uses the Cypress VB engine to accept scripts and user macros. This is done
by a Macro thread, which responds whenever it sees that a CString variable "Macro"
has been set. Any script macro requested is first held till all movement stops and the
ring buffer is empty, then the macro command in translated to the proper file which is
then loaded and the text placed in the Macro variable. This has a maximum of 65000
characters. When the variable contains a text input, the Macro thread will
automatically run that script, then empty the variable, and the program will continue.
This is why a macro cannot call another macro. The threader only looks to one
variable for text and there is no secondary storage for another script. The code is a bit
weak there and will likely be strengthened over time as it’s a complex connection to
get just right. When a script is loaded certain constants are loaded with it such as
Sleep , the names of the signals, ( INPUT1 , OUTPUT1 ..ect. ),and the scripts may
avail themselves of those constant declarations.
-
Thanks Overloaded, it's gratifying to see some evidence that I'm not getting early onset alzheimer's. Now if I could just find my keys... ;)
-
Seconded. Thanks Russ.
Cheers
Ian
-
From the thread linked to in reply #12:
In Mach there is only room for One macro to run at a time, (NOTE: macro pump is compiled).
Seemed to imply that compiled macros can be nested. Can I compile my macros? How?
-
When you are ready to save your macro "CODE" from the code editor, Select save as then select COMPILE ".MCC"
NOW wether you can actually nest it is a good question(;-)
-
Well Compiling the macros did NOT help(;-) mach still looses control of the threading
BUT !!!
Please note that Ray L had nesting macros down to a science using Semaphores
So it can be done and not loose control of the threading.
Note: V4 is suppose to have that fixed(nestingmacros)
-
Is there some directive statement that we can give the interpreter that would be equivalent to "#include" in C? I'm thinking we could avoid nesting altogether by writing the entire macro in a Sub. The main sub would just be a wrapper, so that you could call it as M## in gcode, but when you wanted to use it in another macro you would #include the relevant file and call it directly, instead of using the code function (which, when you think about it, is a rather roundabout way of calling VB code from within VB code - why should I have to ask the vb interpreter to ask the gcode interpreter to ask the vb interpreter to run a macro ??? ).
But if it were that easy, somebody woulda thought of it already... right?
-
Note: V4 is suppose to have that fixed(nestingmacros)
There's a V4? I'm stuck with Tormach's current release, need a workaround.
-
Then try the semaphore approach it does seem to work. Do a search on this forum for semaphore Ray gives and example of how he did it.
-
If you don't actually want or need the parallel behaviour of the multiple macros, it seems a bit overkill to start messing with home rolled semaphores just to get a "sub call". Why not just put your library routines in... erm... a library i.e. a DLL?
Cheers
Ian