GoPara(); //this function will run in parallel in the system
Is the GoPare() needed (and what is it doing)?
I was of the impression that the call thread() would make the function MyDROUpdate execute on a new thread. Maybe combined with a yield() to force a context switch.
>>Is the GoPara() needed (and what is it doing)? I was of the impression that the call thread() would...
Its really just a matter of my not explaining this well as yet. If you were to call
thread( MyUpdateLoop);
in a screen init script and never call it from Gcode, then the
GoPara(); would not be required. But having it there, allows it to also be used in a
Gcode program without the thread command. So while, when placed in a screen script,
it isnt used, when placed in the Gcode, its a way to tell the system not to hold program
flow while that script runs.
To put it another way, imagine you wish to only run a particular update loop
in the context of a particular type of Gcode program. As in
The script StartSpindleMonitor is run , but as its in Gcode, its assumed
the following move to G0X0Y0 will be held back until the script completes.
After all , a script may intend to make a great deal of motion to do a task required
before the following Gcode.
By starting the script with GoPara(); it tells the GCode processor to start the Spindle
monitoring, but continue with Gcode without waiting. So GoPara(); is really just a
way for you to say "Run this in Parallel, not in sequence. ".
This has no real meaning when called from a button or screen script, and will
be ignored. SO whether you call a routine directly,
DoLoop();
or Thread it off into space..
thread(DoLoop);
or ,make it run from Gcode in parallel with a GoPara inside..
global DoLoop = function() { GoPara(); ...
depends on how you want that script to operate. Auggie
allows pretty much complete control and these allow you to
decide just how a script will behave.
My goal here is to allow the designer to control program flow in
various ways, since one can have up to 11 axis in total if one includes
3 axis in the secondary pokeys, it may be important to have many parallel
processes at play. Commands like thread() and GoPara() as well as
the various block signals will, once fully implemented allow a person
with an understanding of how the system execution flows, to make a very
complex logical relationship to the machine and its operation.
"So the GCode:
G1X10Y10
G1Z5
{ thread( StartSpindleMonitor() ); }
G0X0Y0"
...Would be legal and run StartSpindleMonitor() in parallel with in Gcode?"
No. While "thread" will start SpindleMonitor under its own parallel system,
unless GoPara() in is that script, the Gcode will wait for it to finish..
Think of it this way..
A script is itself like a small Gcode program, if, in its line by line execution,
it see's a call like thread(myroutine), it tells the system to run myroutine()
but not wait for the result.
Gcode, is like a string of scripts, and if, in its linear run of command, it runs
a script. That script is given an ID number, the system is told to wait till that scriptID
is complete before running the next GCode line. GoPara(), when it is interpreted,
asks the system to zero the Script ID its waiting for, stop waiting, store the ScriptID
in an infinite array called ParallelThreads, ( who's DRO on the screen shows how many
are in it.), and the Gcode continues immediately upon seeing the GoPara().
This is important, because the Gcode will continue as soon as it see's GoPara(), so where you
place it in the script can be ( but not always is) important. If you need to do something
important before the Gcode continues, put the GoPara in the script after the
important thing is done.
The StopPara's button on the screen, stops all parallel threads. It might be called also
by a script in an M30 call, thus stopping any number of parallel threads you may have
started in the run of the program. Since you can use logic to start such scripts,
the number running may be unknown, so StopPara would stop all threads the program started.
This too is important because you may not know beforehand how many threads and
which ones may be running at end of program.
If indeed CallMySpindleMonitor() started, which would only happen
if the spindle is under 500 RPM, and it had GoPara in it, then thats another
thread in the parallels list, but the designer of the program would have
no prior knowledge that it WILL run, just that it may. SO at the end, a
call
to StopParas would kill all that happen to run..
( I havent given you a script command to kill Paras yet, you need to press the button.)
Art
Last edited by ArtF on Fri Jan 22, 2016 1:23 pm, edited 1 time in total.
I see - things are more complex. Forgot about keeping track of thread IDs and managing them in Gcode.
Trying to get a picture of the internal architecture
As to the FreeAxis, they work any of them can be speed or postion based, you canot switch their mode while moving them.
So set them once and dont change them unless they are stopped. Mode 0 is position, mode 1 is speed. When in speed
any speed set is in units/min . Any not in speed mode, are considere d to be in position mode. Any speed axis is ignored
for a FreeFeedT o move. I will be adding a vector3 based call for getting the x,y,z of the free axis in one call.
Is it possible to get the position of a Free speed axis?
Auggie is getting quite stable Rarely crashes (usually around not being connected to pokeys, when it thinks it should). Amazed at the progress every time you surface.
Sorry about that , I remember I promised you a method, Ill look at that this morning.
As you can imagine, Im at that stage where Auggie is spreading capability in multiple
directions, so Im constantly getting hijacked as I find bugs ( or get them reported) that impact performance in
one direction or another.
The next major step is the Augmentation facility for controlling outputs in the same time stream
as the step output. I wont start that till I clear up the many items on my list to make it stable and easier
to use.
Stability is quickly getting there, the ones I see are usually related to the network losses, as
if the pokeys disappears, some of the pointers go bad, and I haven't tracked that down yet.
Ill see about adding a method today to store the speed axis location before I zero it. I zero it,
so that the other axis's see a zero in a speed slot , that way Cartesian coordinates work fine
while speed axis are in operation..
For a secondary pokeys I could add that, but the primary pokeys is under buffered control, this means
it runs a motion loop every 5ms or so that keeps it refreshed. It means everything I do in there, I pay a small
penalty for in time.. so I tend to keep it clean.
Now, every few ms it updates the indexes anyway, but zeros the speed one. What Ive done is create a shadow
copy called TruePositions that keep strack of the real indexes in realtime. Im adding an Engine.GetTruePos and a Engine.GetAxisPos to the code, so you can pull any of the 8 coordinates in either mode.
Rarely crashes (usually around not being connected to pokeys, when it thinks it should). Amazed at the progress every time you surface.