Hello Guest it is May 13, 2024, 05:29:54 PM

Author Topic: P, Q, R parameter  (Read 12797 times)

0 Members and 1 Guest are viewing this topic.

Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: P, Q, R parameter
« Reply #10 on: May 03, 2010, 05:55:20 AM »
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 Probably better to keep it in one place rather than mix toipics here.

Cheers

Ian

Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: P, Q, R parameter
« Reply #11 on: May 03, 2010, 05:59:04 AM »
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
Re: P, Q, R parameter
« Reply #12 on: May 03, 2010, 06:48:03 AM »
Re: P, Q, R parameter
« Reply #13 on: May 03, 2010, 07:24:22 AM »
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.

Offline flick

*
  •  15 15
    • View Profile
Re: P, Q, R parameter
« Reply #14 on: May 03, 2010, 11:55:58 AM »
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...   ;)

Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: P, Q, R parameter
« Reply #15 on: May 03, 2010, 12:12:04 PM »
Seconded. Thanks Russ.

Cheers

Ian

Offline flick

*
  •  15 15
    • View Profile
Re: P, Q, R parameter
« Reply #16 on: May 03, 2010, 12:50:37 PM »
From the thread linked to in reply #12:

Quote from: poppabear
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?

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: P, Q, R parameter
« Reply #17 on: May 03, 2010, 03:54:12 PM »
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(;-)

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: P, Q, R parameter
« Reply #18 on: May 03, 2010, 05:05:16 PM »
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)
« Last Edit: May 03, 2010, 05:20:02 PM by BR549 »

Offline flick

*
  •  15 15
    • View Profile
Re: P, Q, R parameter
« Reply #19 on: May 03, 2010, 07:46:49 PM »
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?