reading Pokeys pins

[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

[ArtF]

Gary:

Thx, Ill see if I can reproduce..

Art

[gburk]

Art

Sorry again seems like that's all I say to you ???

anyway I think the major problem was running the debug version...
I think I said when I first started with the debug ver that when booted in simulator mode that a script was stuck running and the script blue led keep flashing
when I hit Stop the script would stop but I would get the message scrip stopped with errors check log.. I am going to assume that script was messing things up.

So I went back to the last version of auggie no DEBUG, now it seems to be running Ok...

The only problem I seem to be having is if I use RapidTo or FeedTo the system seems to loose it position's
If I boot and the machine and work DRO's are set to 0.0 I run the script with Rapid or FeedTo and then Rapid or FeedTo back to 0.0 the machine cord's and work cord's change the machine may now be at .029 and the work at 0.029 and the more I run it the more they change and I always zeroed out the axis's before running again..
Also I start getting weird values when I read GetAxisPos the first run it shows 0.0 now when I run it again I get unreadable values looks like 0.e0100 not exactly like that but you get the picture..

Now if I replace the Rapid and FeedTo with Engine.GCode(gcode); it seems to run A lot better I don't seem to get weird numbers back from GetAxisPos when I zero out the axis's before I rerun the script it seems to always show 0.

So not sure if it's me but this is my results..

Also is there a way to run FreeAxis With Engine.Gcode(); or similar?  so far the only way I seem to be able to move the FreeAxis's is with the FreeFeed or FreeRapid.

Thanks gary

[Mooselake]

The only problem I seem to be having is if I use RapidTo or FeedTo the system seems to loose it position's

Any chance that's because your acceleration settings are too high?

Kirk

[ArtF]

Gary:

Ill check the Rapid and Feedto to see why their different than Gcode..
and Ill re-release with release version, now that we've tested the debug.

  The reason you see that script is that one exists in the standard saved screen.
One of the panels calls a script that fails and then ignores it. I havent been
able to update the panel yet in the release, so if you enter in debug it logs it,
otherwise it doesn't. Its from an old panel and Ill see if I can update that
file in next release, Ill try for one this weekend. 

Art

[ArtF]

Gary:

  I found the crash was due to no tool number being set, it was defaulting to tool #-1267 for some reason.. who knew.. I made it default to zero. No more crash.

  I cant find any real difference between rapidTo and Gcode calls for a rapid, but if it
works better Id stick to GCode. Unfortunatly in the case of the freeaxis, there is no gcode
interpreter assigned, just a planner which is fed by freeFeed and Freerapid.

New version is online to fix the crash and it may also explain weird numbers in
some circumstances..

Art


Art

[gburk]

Art

Thanks will try it out and let you know how it go's

Gary

[gburk]

Art

Defiantly Seems a lot better I went back and tried RapidTo and don't seem to be losing place between the mach dro's and the work dro's
Only time it seems to mess up if you hit Estop then the mach dro's stop there and if you zero out the work dro's, then I hit tool1 button and the mach x dro is sitting at 2.0 and the tool1 button is script is set to send the x to 2.0 it doesn't move and the x work dro is sent to 0...

I don't see a command to set the machine cord dro's to a position.. only to get the truepos .

also if for some reason you hit the EStop say after the x y z have moved and its moving axis 6 and 7 everything stops as should be..
But if I hit EStop again the code doesn't run the 6 and 7 axis were Estop was hit but does continue running the script from the next line I have a rapidto there to return to the original position.. I would think you would have to hit RUN also in case you need to jog out of the way, kind of catches you by surprise Hit EStop and starts running right away, maybe hit EStop and should kill the script so you could start over... not sure how you have it setup.. or if i'm looking at the logic wrong.. most of the time I am..

Thanks gary   

[ArtF]

HI Gary:

  No , you have it right. There are very few safeties in the FreeAxis, it was a second planner
I tacked on because I could for running other motors or frequency channels.
  The only way to set machine coords is in a homed axis, same as Mach3,
Only homing will change the machine coordinates. Various offsets are available
in the normal axis, I'm not even sure if they apply to freeaxis. Im a bit rusty
on some of the specifics of those interactions as I never use them with lasers.

  Glad its working better anyway.. that tooloffset default could have been a
problem in many things.

Art

[gburk]

Art

Yes it does seem to be running better even with the rapidto, also I don't seem to be having the rewind on the first m6 call, I did end up removing the Enabling the RUN call so after the tool change dialog I just hit RUN and it seems to continue ok...

Now do you think it will matter much if I do a RapidTo() 2.0 and it stops at 1.994 it seems to do this on a regular basis but if I rapidto() back to 0.0 right after that it does stop right at 0...

checked the same code with Engine.GCode and it didn't stop at 2 either stopped at 1.994..

Thanks gary

[gburk]

Art

Came across another problem maybe me don't know its a strange one and tried many time to get past it with no go..

So I have the tools buttons tool1 thought tool16

So I copied and pasted the code from tool1 to each tool function one at a time and compiling them as I do each one
Now I pasted the code to tool4 and I get compile errors..
I cut the code from tool4 and it compiles again no errors, so now I start pasting code into tool4 one line at a time and compiling it, so when I pasted about 10 lines and compile no I get the compile script error again I remove the last line and it compiles again.
So I typed a Rem line //testing error and compile it again and get compile error.

No matter what I type on the last line I get compile error...

So one though was the scripts may be limited to how many lines can be compiled...

Any thought on this I know its a strange one.

Gary

[ArtF]

Gary:

There may be a limit to a scripts size based on the language interface. I havent hit
one yet and Auggie deals with all Scripts as single CStrings() , which have a defined
limit of over 2 billion characters. However, monkey script itself may have some internal
limitation I am not aware of.
  Any idea of the number of characters you have when it fails? Is this failing in the Script
window on a run, or when checked back into the libraries?

Art