Script/GCode interface
Posted: Wed Jan 13, 2016 5:04 am
How was Lunch? :)
Well, before we get to involved in the operations of the scripts, we should probably have a
clear understanding of what , exactly, the scripts are meant to do. Broadly, the answer is
everything, but the object is to hide that from the end user. Other than the GCode subsets
of script the user may wish to learn, the running of the program, though pretty much
all script, should be pretty much opaque.
Recently, as I explained in the YouTube video, I added the GCode library, this allows
you to add GCode or M Codes to the language of the input file. Natively, Auggie knows
very few M Codes, and not all the G Codes. Ive instantiated as a system only the basic
ones. However, any G code or M Code not understood triggers a script call to a
function named GCodexx where the xx is the number you called in the GCode..
so a
G162 in the GCode file, will call : GCode162 as script function name.
Now if no such script exist, a message is printed on the toolpath and a log entry
is made. The file will run regardless as you may have turned off that GCode to
stop a behavior you don't want. This allows you to check a library to turn it on or off
and turn on or off or swap the meaning of a G code or M Code. It is quite
possible to have G code libraries named for a particular machine type, and select the
one that matches the device.
The commands you add to or use from the G code libraries are not the only ones
available to the running program, basically any legal script call or function
can be put in the G code file , so long as it is between { }'s
for example , as of next update anyway, the following would be quite legal..
...
G1X100Y5Z5
{Notify("ToolChange will be coming up in about 3 minutes.");}
G1Z-.1
...
...
{Warn("ToolChange will be coming up in about 1 minutes.");}
G1X4
..
{Alert("ToolChange in a few seconds.");}
Notify just puts text in the tool path screen, Warn and Alert do as well,
but also add a sound of urgency from the sound system. These commands
all show up in the auto type mechanism so their not hard to remember.
The idea here is to add enough GCode and MCode scripts to allow generic GCode to
run, and to allow embellishment of the code to make it do things that Auggie will have
the power to do. So most scripts a user writes will add a capability or simply be calls
of scripts pre-written and already in the libraries to add to the GCode.
There is a Contours facility which will appear as a library shortly as well, which allows a user
to add points to an unlimited amount of profiles, and save them as dxf's, or use them as toolpath
lines, much like a G2 or G3, but beziers , defined shapes and such will also be possible.
Methods like this will allow for things like constant burning of ever changing serial numbers
and such.
The system now sends signals on any used signal that changes in either pokeys, so you
may now block on any of over 110 signal names. To have a script service a pin on the Pokeys,
just make sure its enabled. You may now have a script such as
global ServiceIOPin15 = function()
{
while(1)
{
block("IOPin15");
//do what you wish to happen
// on pin15 change here.
}
}
And start the process in the main screen init script with
thread( ServiceIOPin15 );
this will send the ServiceIOPin15 script off running on its own,
waking up only when pin15 on the IO Pokeys changes state..
What you do of course ifs up to you. This works for Analogue,
Digital (in and out) Encoders and counters.
This means you have pretty much full control of over
100 pins of IO mixed in various ways.
Enough for now, I thought Id try to clarify a bit what the flow of the system is
designed to be.
Thx
Art
Well, before we get to involved in the operations of the scripts, we should probably have a
clear understanding of what , exactly, the scripts are meant to do. Broadly, the answer is
everything, but the object is to hide that from the end user. Other than the GCode subsets
of script the user may wish to learn, the running of the program, though pretty much
all script, should be pretty much opaque.
Recently, as I explained in the YouTube video, I added the GCode library, this allows
you to add GCode or M Codes to the language of the input file. Natively, Auggie knows
very few M Codes, and not all the G Codes. Ive instantiated as a system only the basic
ones. However, any G code or M Code not understood triggers a script call to a
function named GCodexx where the xx is the number you called in the GCode..
so a
G162 in the GCode file, will call : GCode162 as script function name.
Now if no such script exist, a message is printed on the toolpath and a log entry
is made. The file will run regardless as you may have turned off that GCode to
stop a behavior you don't want. This allows you to check a library to turn it on or off
and turn on or off or swap the meaning of a G code or M Code. It is quite
possible to have G code libraries named for a particular machine type, and select the
one that matches the device.
The commands you add to or use from the G code libraries are not the only ones
available to the running program, basically any legal script call or function
can be put in the G code file , so long as it is between { }'s
for example , as of next update anyway, the following would be quite legal..
...
G1X100Y5Z5
{Notify("ToolChange will be coming up in about 3 minutes.");}
G1Z-.1
...
...
{Warn("ToolChange will be coming up in about 1 minutes.");}
G1X4
..
{Alert("ToolChange in a few seconds.");}
Notify just puts text in the tool path screen, Warn and Alert do as well,
but also add a sound of urgency from the sound system. These commands
all show up in the auto type mechanism so their not hard to remember.
The idea here is to add enough GCode and MCode scripts to allow generic GCode to
run, and to allow embellishment of the code to make it do things that Auggie will have
the power to do. So most scripts a user writes will add a capability or simply be calls
of scripts pre-written and already in the libraries to add to the GCode.
There is a Contours facility which will appear as a library shortly as well, which allows a user
to add points to an unlimited amount of profiles, and save them as dxf's, or use them as toolpath
lines, much like a G2 or G3, but beziers , defined shapes and such will also be possible.
Methods like this will allow for things like constant burning of ever changing serial numbers
and such.
The system now sends signals on any used signal that changes in either pokeys, so you
may now block on any of over 110 signal names. To have a script service a pin on the Pokeys,
just make sure its enabled. You may now have a script such as
global ServiceIOPin15 = function()
{
while(1)
{
block("IOPin15");
//do what you wish to happen
// on pin15 change here.
}
}
And start the process in the main screen init script with
thread( ServiceIOPin15 );
this will send the ServiceIOPin15 script off running on its own,
waking up only when pin15 on the IO Pokeys changes state..
What you do of course ifs up to you. This works for Analogue,
Digital (in and out) Encoders and counters.
This means you have pretty much full control of over
100 pins of IO mixed in various ways.
Enough for now, I thought Id try to clarify a bit what the flow of the system is
designed to be.
Thx
Art