reading Pokeys pins

[gburk]

Art

I think I found the problem with the m6 its my ERROR in script, I was trying to have the g code continue to run after my tool change dialog was closed with the button press so I didn't have to hit the run button after the dialog box was closed so I had stuck a    //GlobalSet("Execute",1); in there when it exited the manual tool change script I REMed it out now it stops at the dialog box and M6, SORRY MY BAD

The G code still Rewinds on first M6, but if you stop the G code and rewind it, Then it runs fine so seems like happens only on first run of G code..

So no that I don't seem to be able to use    //GlobalSet("Execute",1); or I need to put in a different part of code, any suggestions as to how to make the g code continue after I close the dialog without having to press RUN also??

And the blue led only flashes in simulation mode not in engine, you may have it setup that way
I get there error in the error file
25:13:150  Simultion Mode Active
25:13:150  Changing Enabled state of one or more motors
25:13:150  Pokeys section inited.
25:19:649  error (3) parse error

Gary

[ArtF]

Gary:

>> M6, SORRY MY BAD

  Never a big deal.. :)

>> //GlobalSet("Execute",1);

  Awesome, you figured out how to make it run anyway, I had forgotten
that command. OK, so basically you want that to happen after the dialog
is closed, or at least while its closing, so Id add it to the end of whatever scripts
are named with _close in their name tag. You just need to figure out what the
final thing your doing is, and put the  GlobalSet("Execute",1); at the
end of that. I think that should work.

  I'm still searching for why the startup error. Too many changes lately so
Im probably leaving some variable unset.. Ill grok it eventually.

Art

[ArtF]

Gary:

Just a note, Ill release the proper release compilation on next update,
that will make the program much smaller, though space doesn't really
matter to most anymore in days of terabyte drives.

  Auggie is both experimental and free so it has no real development
pressure on it so dont feel bad about all the versions, each one typically
makes it run a bit better in the end. I appreciate all the testing you did
to find the problems you found. :)

Art

[gburk]

ART

Thanks
>> M6, SORRY MY BAD

>>  Never a big deal.. Smiley

Felt bad and stupid that I had you trying to figure out something that wasn't there..

I thought I had the  GlobalSet("Execute",1); after the StopProgram but it wasn't stopping I will double check and get back to you...

Thanks gary

[gburk]

Art

I'm fairly sure the is the script M6 Starts and Ends with but as it is the Stopprogram doesn't stop maybe you see something im messing up

global DoToolChange = function( tool )
{
    //XcurPos = (Engine.GetAxisPos(1));
    //YcurPos = (Engine.GetAxisPos(2));
    //ZcurPos = (Engine.GetAxisPos(3));
    currentPos = AxisCurrentPos();
    print("currentPos X = " +currentPos[0]);
    print("currentPos Y = " +currentPos[1]);
    print("currentPos Z = " +currentPos[2]);
    sleep(.5);
    GcodeReturnToPos = ("G01 X"+currentPos[0]+" Y"+currentPos[1]+" Z"+currentPos[2]+"F10");
    Engine.GCode("m9");
    Engine.GCode("m5");
    block("MotionStill");
    if (GlobalGet("AutoManualDRO") == 1)
    {
    DoAutoToolChange( tool );
    Engine.GCode(GcodeReturnToPos);  //Move axis to safe posistion's
    block("MotionStill");   
    return;
    }
      else
      {
        DoManualToolChange( tool );
        print("Change done");
        //Engine.GCode(GcodeReturnToPos);  //Move axis to safe posistion's
        //block("MotionStill");
      };
    print("Change now to Tool " + tool + "requested");
    Engine.StopProgram();
    GlobalSet("Execute",1);
};

all the scripts are just rough drafts, figured not worth polishing up till most of it runs though OK.. make sense

I tried moving the  Engine.StopProgram(); and GlobalSet("Execute",1); to different positions in the script but doesn't stop  running seems like as long as there's a  GlobalSet("Execute",1); in the script it over rides the  Engine.StopProgram();..


Gary

[ArtF]

Gary:

>>Engine.St opProgram ();
>> GlobalSet("Execute",1);

  You can think of GlobalSet("Execute",1) as the opposite of StopProgram();

  Your stopping it, but then telling it to press the Execute button. This starts it again
unless its in a state where it cant. You should use one or the other, but not both.

Using GlobalSet("xxx",1) with any button named "xxx" is the same as pressing the button.

Art

[gburk]

Art

So if I wanted to stop the program from running when I call the tool change dialog, and when I press for Example the Z button and do a Z_close
then exit the dialog now I would like the program to continue running, without having to press the RUN button.

I did figure Exicute,1 and stop program where the opposite's, that's why I thought it would work, so if I am getting this correct now, StopProgram() doesn't in reality stop execution at that line,  even though I sent the StopProgram() it still runs the next line of code the Exicute,1 acts like I never had the stopprogram() line there
so the program keeps running. and never Stops.
At least that's how it reacts in my script..

Gary

[ArtF]

Gary:

Just for archival purposes, Ill add a small explanation of how this all works
when scripting..

Imagine we have Gcode as follows

G0X0Y0
M6T7
G1X6

 this will eventually parse to as follows

G0X0Y0 //move to 0,0
T7 { run script for tool number change , run first due to system priority over an m6}
M6 { Run script for tool change, but also the stoprogram variable is auto set to true. }
//will wait for execute now as programstop was set internally as a tool safety
g1x6 //move on next execute.

Somewhere around 10 times a second Auggie does a routine called SyncOps
internally. This is when it executes scripts for a time slice, executes special
commands like StopProgram or Execute or any button name set to 1.

Normally, execution of any script tells Auggie to wait for that script
to finish before going to the next one. So if, say in the M6 script,
you do a .StopProgram(), the variable StopProgram internally is set
to be executed on next syncops. If you then add a GlobalSet("Execute",1),
the variable Execute is set to true for next SyncOps.

 You have no way of telling in what order such commands will
excute. They may not be in the order given as they are queued until the
next SyncOps. So its possible it may execute(), then stop() internally
as opposed to stopping, then executing.

 So, a stopProgram() should be the last command in the script.. or a yield()
should be done after the command, this pauses the script until the next
syncops. A yield() really only exists for this purpose, its kinda like a flush()
operation to be sure everything system-wise has been interpreted.

 If you need the script to continue after the StopProgram(), you may want to
call a GoParallel(), which then detaches that script from the running program
allowing it to stop, but your script to be running.

 Its possible during the process of stopping a program, it may decide to kill
running scripts in some circumstances. It will not terminate a Parallel script
until an Estop or program end I believe.

 This is all very complex in there ( I dont know what I was thinking... )
so unknown interactions can happen in some situations. When things
get weird, try adding yields after system commands to see the effect, it
sometimes helps, if it doesn't, remove it as being unnecessary.

Art


 
 

[gburk]

Art

I think I get it's like pulling and pushing from to the stack.

GoParallel() was one thought but it also seems to have a time restraint so not sure if that will work but I will try it out..

The problem with having to get things done at any speed may be a problem. when I open the tool change dialog who knows how long it would take to jog the axis's change the tool retouch off the tool and then exit the dialog  and continue the g code..

I will test out the yield() also...

Thanks for the expiation it was very clear..

Gary

[ArtF]

Gary:

Kinda like a stack, but the highest priority will be done first in the case of syncing commands like
stop or start.. Id do a program Stop as you make the dialog, and add the Execute,1 to the dialog that handles the final step before you exit. If youve added moves they will be completed before
the program actually starts. It wont start till all moves are done .. So as you make the toolchange dialog, add the stop, then a yield(), then allow the dialogs to do their thing but in the final script
do the execute,1 .. that should work.. but then should is a big word..


Art

[gburk]

Art

I think that's the way I had it Stop when creating dialog in the start of the function, then execute.1 when leaving the tool change function and that should bring you back to the g code, the problem I was getting any time you called the script, and were in any of the script functions being used by the m code call it always seemed like execute.1 took preference over the StopProgram and just by passed it like wasn't there..

I think I will just change the dialog to say when finished press the RUN button...

Gary

[ArtF]

Gary:

In checking, I told to stop the program even if a script exists
in a tool-change. So the stop Program shouldn't be required. Just an
execute,1 in the final button call of the dialog.

It may be that the system sees a script still running from the previous run.
(The script your currently in..) and is refusing the RUN button being pressed
as its waiting for a script to complete.
So it may be necessary to do a GoParrallel(),Yield() at the start, that way
the execute wont see any scripts currently running.

  The GoParrallel will remove the script from the running scripts list, probably
best to simply add that at the start of your toolchange script so it starts up
as a system script, is removed from the running program stack, the Yield()
after the GoParrallel will ensure the program is stopped, waiting for an
execute when your script tells it to. Then in your final script of the tool
change, put the execute,1 at the end of it. The program now having nothing
to do at that point and seeing no scripts in the program stack should
be in a state where it will accept a press of the run button.

Art

[gburk]

Art

Tried the GoParrall, yield() at the the start of the tool change script M6 and put the Execute,1 at the last line returning to the g code...

the dialog pop ups but the problem is the code doesn't wait for you to exit or close the dialog before continuing, so the dialog is sitting on the screen waiting for some action Z_close or any dialog button press, but the script keeps running till it hits the Execute.1 and g code starts running again before you had a chance to jog axis and change the tool, or close the dialog.

It will stop as long as I don't have a Execute,1 anywhere in the script
I assume it still has run all the way though the scripts but its now waiting for the onscreen RUN button to be pressed..
I think that must be built into auggie.. but when I have Execute,1 anywhere in the scripts then  I no longer have to hit the RUN button..
and the g code starts running.



Thanks Gary 

[gburk]

Art

Been messing with the tool changer button scripts and if I use the Rapid moves I get strange behavior the x y z don't move but axis 6 and 7 do

I changed the rapids to Feedto and Freeto that seems to work better, I also have a Engine.GCode move to return to the x y z start positions that I have zeroed out at start but the x y z seem to always return to .0330 not sure why.. here is a couple lines of code that seems to work, also when using the rapids and it was running rapids on the FreeAxis when I hit the EStop the Free axis keep running..

    Engine.FeedTo(SafeX, SafeY, SafeZ, null);
  //Engine.GCode("G0 X"+SafeX+" Y"+SafeY+" Z"+SafeZ);
  //Engine.RapidTo(SafeX, SafeY, SafeZ); // move at current feedrate to safe position
  block("MotionStill");
  //yield();
  Engine.FreeFeed(null, RackMovein, RackRotate, null);
  //Engine.FreeRapid( null, RackMovein, RackRotate, null);
  block("FreeStill");
  //block("MotionStill");

Gary

[gburk]

Art

Ran into another problem, if I boot auggie and enable EStop then press the tool change button tool1, I get a crash I attached the screen capture of auggies error message, auggie shuts down when I close the error dialog..

But if I boot auggie enable EStop and then RUN the script in the script window I don't get a crash when I hit tool1 button..
This is a strange one...

Gary