reading Pokeys pins

[ArtF]

Gary:

New version online that also logs your decoded GCode line.. so send me a log of where it screws up if you would..

Art

[gburk]

Art

Here is the new log with not running the script then running the script..

Also i was thinking and wanted to run this by you..
The reason i have in my mind about having to run a g0 or g01 before say two g31's , like run  g31 X- it triggers the probe and if i have a G31 for the next call it doesn't move, i'm thinking the second G31 see's the probe as triggered and does't move correct ?

Gary

[ArtF]

Gary:

  Probably correct. If the pokeys is commanded to do a probe to
a logic level already in effect, no motion will happen and the pokeys will send the
message its finished and it will be as if the probe happened, and stopped.

  the following log items are weird. The F10 G91 .. line is from your script, and the F10 is completed,
but from somewhere, a feedrate to 2.0 is commanded and completed. Im not sure where the 2.0 came from.

The 22.5 is similar, I see the command coming in, and getting completed, but Im not sure where its coming from..
Is 22.5 used anywhere in the program?

>>18:22:636  F10 G91 G31 Y-0.2
18:22:636  Command Feerate to  10.0000
18:22:636  Command Feerate to  2.0000
18:22:667  Set Feerate to  10.0000
18:22:667  Set Feerate to  2.0000
18:23:245  Y- Probe Hit Now Centering Y 
18:23:245  F35 G90 G01 Y0.633708
18:23:245  Command Feerate to  35.0000
18:23:245  Command Feerate to  22.1798
18:23:277  Set Feerate to  35.0000
18:23:277  Set Feerate to  22.1798

Art

[gburk]

Art

The only feed rates in the script are 10 and 35

no 2 or 22

What i see when running
18:23:277  Set Feerate to  35.0000 this is correct feed rate from g code
18:23:277  Set Feerate to  22.1798 this is the feed rate displayed in the onscreen free rate DRO
But i have seen when i have a 40 in the fast feed rate g code for the onscreen DRO to display 80..

but all get corrected when RUN script first

As you question The line F10 G91 ..
the f10 shows 10.000 from the g code  and the onscreen display shows 2.0000
it seems when you are doing the 2 prints its reading the  G code and the onscreen value.
endless you just are reading the onscreen DRO and it changes from 10 to 2 so fast i can't see it..
I don't see any feed rates other that 10 and 35 in the script g code they are read form a DRO so never get changed endless i change the DRO value..

Gary

[ArtF]

Gary:

  Seems the DRO must be sending data after it gets an update command from the system
when the script demands a change.. but its the wrong data.. Ill investigate based on that..

Thx
Art

[gburk]

Art

Thanks as for the probe logic it seems to a problem, for me at least, if you are wanting to probe a small hole,
and you hit the probe and do a g1 back off, its hard to make sure you don't back off to much and hit the other side of the hole..

I have started to rewrite the scripts to do a G31 back off "ProbeInvert",1 then a G31 or g1 from there, works ok with the Z probe, working on the X now..
I think this should get me to an open probe state and i can go from there..

Any thoughts on a better way.?

Gary

[gburk]

Art

It just looks like When auggig boots and reset's scripts, or if you check back in script, its doing some thing just a little different then when compileing the script in script RUN editor.

I was also noticing besides the feed rate being off, so are the Screen Axis dro's not much to worry about but off, then when you RUN the script the feed rates are right and so is the Axis dro's are also right on..

Gary

[ArtF]

Gary:

    >>Any thoughts on a better way.?

I guess one way is to check the pin status to see if its hit, I repaired that as well so if you ask
the digital level of that probe pin you should get the right answer, it was broken but now reports
if the pin is high or low. Its a way to check if you backed off enough..but youd need to be carefull
that you didn't back off clear to the other side.
  The safest way for sure is to probe to side, reverse probe level , probe off, reverse level again,
then probe to other side. You could do a pin check every probe to be sure of if its in "hit" or not
based on level.

>>its doing some thing just a little different then when compiling the script in script RUN editor.

  Yeah, I'm still trying to understand why the differences.. though the home showed a clue, I was checking to make
sure no one homed while running a program, this made a script home fail because during a script, it sensed a program
was indeed running so it ignored the call. SO I removed that safety, ( Do NOT home by button during a run, it would actually try now..)

I suspect something similar somewhere, where I tried to make it safe in context of running vs idle and my
logic was faulty as I didn't include scripts in my considerations. Im checking to see where I did that..

Art

[ArtF]

Gary:

Version d is online now. Auggie will drive you nuts with feed-rate messages, but their put onscreen for this test
so I can figure and prove exactly where they are coming from. It may be some sort of init failure on my part
in the scripting. (Scripting is incredibly complicated in its interactions with the system and the bugs your finding are
evidence of non-use since I wrote them, so this is all a test of how logical I was thinking when I wrote much of this
and I do apologize for some of the interactions. Things like probing I added just in case, but had no intentions
at the time of actually using them. I kinda marvel at the internal complexity of this beast now...and I thought
I took timing liberties with Mach3, Auggies internals make Mach3 look like a game of solitaire )

 
  So now when you command a feedrate change it will generate many messages that will show me the logical
flow from routine to routine and call to call, engine to engine and thread to thread.. It will tell me if its from a
script, or the DRO, when it was injected any why.  I suspect this is mostly the result of one bad logical
assumption on my part during development , I just cant quite grasp it yet, but feel we're close. :)

  Repeat the issue so you get those weird numbers, send me the log and I think Ill be able to say
with some certainly where the heck those weird numbers came from. Ill then turn down the priority
from 1 to 2 so they log only and do not print to screen. I use a priority system to determine if something
is printed, which leads me to another request, if your seeing a message too often that you feel
is disrupting to you, let me know and I can easily set it to a lower priority.

Thx

Art

 

[gburk]

Ok Art

Will test it out later, and get back to you.

I did decide to go with probe hit probe then G31 back off till released once released i should be able to use another g31 to probe to other side,
and not have to use a G0 g1 to move off.. and take the chance of crashing..

So rewriting the scripts :o

Gary   

[gburk]

Art

Here is a couple logs the 2 that are have a name Norun were not run in the script run window, the other i did run a probing script first,
funny thing is it doesn't matter which probing script i run anyone seems to fix it them all..

Also not sure how you setup the prints, but the last print seems to run in a loop till i exit or estop auggie.

Gary.

[ArtF]

Gary:

New version uploaded to stop that loop.. Im still tracing the flow..

Art

[ArtF]

Gary:

Think I found it. My version was defaulting to feedmode of FEED/Min while yours was
defaulting to TIME_INVERSE , a strange mode thats used for constant speed. It was only partially
defaulting to that however, so it was making up weird feedrates depending on Z and spindle speed.

  Tended to only happen when a script Gcode was sent..

This version will either fix it or tell me why. Its online now.

Art

[gburk]

Art

Think you will be happy,
Ran 4 or 5 probes, and feed rates looked good
here is the error.txt file

Gary

[ArtF]

Gary:

Thx, it explains a lot. I run in debug mode for technical reasons here, it zeros variables. Release doesnt
and this particular value, FeedrateMode wasnt being init'd..

Ill keep my fingers crossed.

Art