reading Pokeys pins

[ArtF]

Gary:

New version is online of Auggie. The "_close" added to any dialog handler's function name  will
tell it to close that dialog when the handler is called. Its like appending a call to OnOK or OnCancel.

  I'm not seeing any ill behaviors per say on this version running your file. IT does stop
after each peck drill, but the script calls StopProgram so Id expect that. The only other
stop is after a tool change and that's a safety of sorts. I will see if I can add a continue
script call to help if one wants to continue after an automated tool change.


Art

[gburk]

Art

The G code seems to run fine now no problems when first loading G code with m6..

I'm not sure how exactly you setup the _close, doesn't seem to work it I use dialog._close(); or dialog("_close")  in some of my stuff OnCancel is setup like
CDialog::OnCancel();  so not totally sure how game monkey is handlining it...

Can it be closed in the function called by the dialog.button press?.

Thanks gary

[ArtF]

Gary:

I used it in testing by simply renaming your Z touchoffbutton dialog handler
setting when you added the button to this..

WaitDialog.AddButton("Touch OFF Z_close","MyToolChange");

The button will still read "Touch Off Z" when displayed on the dialog,
and the script MyToolChange will be called, but the OnOK routine
which will close the dialog will be called when the MyToolChange Script
has completed its run.

  So if you change any buttons declaration to having _close added
to the buttons label, that buttons becomes an OK button with your label
and your script.

Art

[gburk]

Art

I Get it now and tried it and it does work.. But Always a But

Now when I run the g code and I get the m6 the dialog pops up but the g code keeps running, so the g code isn't stopping and waiting for the button press the g code continues to run even with the dialog waiting for the button press, the dialog does close when I hit the button..

Sorry I guess I just make problems

Gary

[ArtF]

Gary:

  Its likely due to some changes I made in the logic to keep things running unless told otherwise.
In your toolchange script, call StopProgram() and see if that fixes things. It should work like your
peck drilling does, it stops after its call due to the StopProgram() you put in the script. I
removed the toolchange autostop unless there is no tool change script, if none exists, it
stops on the M6, if a script exists, its up to the script to call StopProgram if it wishes the
program to stop. Unfortunately, a dialog opening is seen as the calling script terminating,
so its assuming your doing an auto tool change with no interaction, the calling script
is finished so it just continues. Add the StopProgram() call and it should stop.

  Downside is youll have to press run after your dialogs are complete. I will try to add a
continue() call, but its complex in there in its interactions so I'm trying not to hurt
scripts I or others have, so you may not have a continue real fast..Im still testing for
ramifications.

Art

[gburk]

Art

Will check that out,

Would it just be easier just to add a way to read the OK and Cancel buttons and then call a function depending on the choice?.

I put a Engine.StopProgram(); in the tool change dialog function but didn't have any affect g code sill keeps running with the dialog screen just waiting for input

thank gary

[ArtF]

Gary:

For techincal reasons, as the system creates OK and cancel, they really cant be easily hooked.
This makes them kinda useless in my view, better to simply label a button as "OK_close"
and turn off system buttons. Works the same really.

Ill check why that stop doesnt occur..

Art

[ArtF]

Gary:

For the life of me I cant repeat it. If I load all is fine, I press run and I can see internally
the program stop get set. Then a script tells the Z to G1 to 1.0, then another G1Z.125,
then the dialog appears and the program waits for a run command.

  Im not sure what script is telling it to go up, I just verified
its coming in from a script. It then immediately does a g1 to z.125 and stops for the run.

  So Im not sure exactly whats going on, Ill keep looking..

Art

[gburk]

Art

DoManualToolChange is sending the script to 1" then calls the wait dialog for tool change..

I tested it again with the same g code I sent you.. I hit RUN the code start running the Z retracts to 1" then the code continues to Drill pecking and my dialog pops up
and sits there but g code is still running doing the pecking never stops and wait for a button press.

Gary

[ArtF]

Gary:

Does it stop after each line of pecking the way mine does?

Art

[gburk]

Art

Just keeps pecking the g code doesn't stop does the 4 pecking lines then continues to the cutting the recess the dialog pops up at the m6 lines but the g code keeps running.

it was working ok in the last version of auggie just had the problem when g code loaded running m6 and then g code being rewinded to first line.
That's fixed..

Gary

[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