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
reading Pokeys pins
Re: reading Pokeys pins
Any chance that's because your acceleration settings are too high?gburk wrote: The only problem I seem to be having is if I use RapidTo or FeedTo the system seems to loose it position's
Kirk
Re: reading Pokeys pins
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
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
Re: reading Pokeys pins
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
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
Re: reading Pokeys pins
Art
Thanks will try it out and let you know how it go's
Gary
Thanks will try it out and let you know how it go's
Gary
Re: reading Pokeys pins
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
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
Re: reading Pokeys pins
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
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
Re: reading Pokeys pins
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
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
Last edited by gburk on Sat Jul 06, 2019 1:17 am, edited 1 time in total.
Re: reading Pokeys pins
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
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
Re: reading Pokeys pins
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
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