reading Pokeys pins

[gburk]

Art

Sorry I take that back, I went back and reran the g code it still rewinds but now on the first Press of the RUN button  the code then hits the m6,  it then rewinds the g code. but does the z move to .125 and then to 1"  then the tool change dialog pops up. and I am now back to the first line of g code

Now I have to hit the RUN button  z moves to .125 then the code runs to the same m6 call z moves to 1" again and the tool dialog pops up
but now the g code doesn't stop keeps running though all the pecking lines even with the tool change dialog waiting for a key press..

Hopefully this is a little clearer I stumble on words ???

And almost forgot the reason the pecking seems to stop is I have a sleep in the script made it easier to read the prints on the screen..


Gary

[ArtF]

Ill rerun my tests Gary, my pecking stops entirely, but the script has a
call to StopProgram() so mine stops and never restarts. Its possible
my scripts ara bit different than yours at this point, but Ill try a few runs to see
where that move to 1" is coming from, I only traced it till I saw it came from
a script.
  Ill narrow it down a bit more.

Art

[ArtF]

Gary:

  A new version is online 3.62-debug , this is a much larger file as it
is compiled in debug mode.

  What I find here is the file stops as it should at the m6, as well as the
pecking stops it due to the programStop() in there. (At least on mine.)

  Now testing this is hard here, because while I have your scripts, my system
isnt set as your in many ways, and I use a debug version as I test your scripts on
a 56e connected by USB and for some reason my system wont run the 56e on usb
in release mode, only debug. (My compiler is using usb for arduino config
and I suspect its interfering in my testing. )

  I found I had autotoolchange unchecked here, so it was the manual tool
change script that was causing the Z to go to 1 after the dialog opened.
I checked auto and that stopped and the file simply stops.

SO I need to know if debug and release work the same, let me know what
this one does. Also, in testing I did see a failure immediately after load on
the first press of run the line numbers didnt track. Im looking into that
but I noticed after rewinding and restarting it worked as expected. So
theres a bug in there somewhere. Im still looking.

Art

[gburk]

Art

Ran the debug version with the g code a couple time...

on the Run press it runs to m6 rewinds doesn't stop starts running again from first line and never stops running at any m6...

and I miss understood you on stopping in the pecking I thought it was stopping during pecking not when it was exiting the pecking script
yes I still have the programStop() in mine I also have it in the manual tool change but has no effect anymore with the g code the script runs hits the programStop() but doesn't stop just keeps running.

Not sure maybe that could be broken now?..

also noticed one difference in the debug ver when I booted auggie the blue script led was lit so i assume some script was running it didn't shut off till i hit stop

Will test some more..

Thanks gary



 

[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