reading Pokeys pins

[ArtF]

Gary:

Thanks, Ill check it out.

Ive found a few problems so far, one was reading digital pins, one was probe syncing. Gcode syned properly
but it waits internally for the probe, scripts werent, I find under the new code, this makes it work properly synced.

GlobalSet("FeedMaster",0);
Engine.GCode("G38Z-10F50");
block("MotionStill");
Engine.GCode("G1X5");

  The block is necessary as the script doesnt know the other axis end positions for the g1x5 move.
The block makes sure its still, and that makes the end probe position sync up.

  The FeedMaster,0 is there because the reason your feedrate is sometimes not working is that
the feedrate override is sometimes not working right. Im working on it now as well. Setting
it to zero manually makes your program feedrates work. It may be late week before Im done,
I seem to have a found a nest of snakes Id like to kill in there..

Art

[gburk]

Ok Art

Thanks sorry, looks like I opened a can of worms.

Would you rather I  use the G38 over G31?

G38.2 G38.4 a little less coding my be able to eliminate the "ProbeInvert"

Gary

[ArtF]

Gary:

  I may end up adding support for probe pullout, but Ill wait till I see what all these changes do.
I have recoded the sync after probe as well as sync after zero axis. Its a lot of changes so I may
just release it with this done to see how it reacts before I add more. Ill see if
I can get it out tomorrow or Wed.  Im getting much better results so far but Im only
running my own script tests, we'll see how you do. :)

Art

[gburk]

Ok Art

Thanks, was only kidding about g38.2 g38.4 got distracted by a gran kit running around and never got to add that to the message..

and forgot to go back and edit it oops..

not sure how different our scripts are but for the most part mine did work except for the touch plate probing... and jogging the zeroing axis..

I did try to fix the windows10 auto reboot, auggie still reboots after I close it sometimes not sure what else I can change in windows 10,
so far auggie seems to be the only program on my computer that does this..

and it does it on both computers I have it on they have different cpus one intel and the other amd, but both run windows 10


Gary

[gburk]

Art


GlobalSet("FeedMaster",0); I added this to the probe script, don't think it fix's the problem it a strange one I tried things differently this test..

I ran the z probe g31 z-1 F5 then retract to g0 Z+ZstartPos F30 it worked good in simulation, now instead of jogging, I manual entered a 0.1 in the Z axis DRO
then ran the probe again  it probed to 1 and retracted ok to 0.1 but the feed rates were off it showed 3.3 and then 33 on retract, so now I entered 0.2 in the dro
and the feed rate changed again now it was 6 and 36 on retrack.. strange that changing the DRO value would effect the feed rate..

Gary

[ArtF]

Gary:

>>g0 Z+ZstartPos F30

  You mean you used g1 right? go wouldnt respect the feedrate, it would go full out
and just change the feedrate.

Art

[gburk]

Art

yep G1 and had another typo it was 5.3 not 3.3 Feedrate it was always a littler higher than the value I had in the engine,gcode..

Gary

[ArtF]

Gary

Ahh ok. I had assumed the error was the one I foudn where sometimes the F word was
ignored. The LED on FeedMaster was out so it should have worked in the GCode
but was ignored.  This version has a lot of changes, should be out tomorrow and
we'll see how the syncing goes..

Art

[gburk]

Art

Of course I didn't think the whole feed rate thing though and said it only went higher, then I remembered I never tried it changing the DRO in the - direction so gave it a shot entered a -0.1 and the feed rate that had 5 in the gcode changed to 4.5 so it it does go down if you enter a neg value in the Z axis DRO..

Also I have noticed in the multi line mdi it only seems to run the first line for me..
I entered G0 X1 line 1 G0 Y1 line 2 but only line 1 runs no matter how may times I hit the Run button.

Gary   

[ArtF]

Gary:

  I just uploaded version 3.65 , lets see how it does on all these things. Theres quite a bit
of new code and calls to ensure syncing in scripts. The only rule is the need for a block
on motionstill after a probe call. There is also a known bug that in GCode MDI you cannot probe
unless a G0 is the next move, this is being investigated.

  Be cautious, with this much code chang eI worry about unintended consequences...

Art

[gburk]

Thanks art

Will give it a shot tonight when it cools down alittle..

So no new script calls functions variables  just use what I have been using..

in the MDI I didn't use the probe call just the GO on each line and only would run the first line...

Gary

[gburk]

Art

Did al little testing, its some what confusing to me, so I will try my best to explain..

The probeinvert keeps it setting now when rebooting..

Tested the probe in the MDI one line G31 Z-1 F10, second line G0 Z0 F30, started to probe with dro's set to 0 so it probed till touch plate hit and stopped, ran the second line and it retracted back to start position 0..

Ran with the probe button and got mixed results, sometimes it would only probe down a real short distance and then retract not hitting probe, one thing I did seem to find if I ran it first in the MDI then the button script it did probe down and retract ok.. but never the same results more that once or twice. then it would go back to the old way and hit plate and not retract it would dive into plate..

It still seems to me that the system is getting lost as to where it is, not sure if its still between the mach cord and work, but it seems to get thrown way off even though the DRO's are zeroed

Also I ran into a problem with the MDI at a point, it seemed to stop working the script button would still run and axis move but the G31 Z-1 in the MDI stop working no axis movement..

I think you are close with the probing..

I also ran simulator mode and had a lot of problems in that mode same as machine mode  but I took it a little further and was finding that if I loaded a gcode file and ran it, it would run maybe 1/4 or more though the file then auggie would crash, and I would get the dialog with a bunch of error lines and when I close out the dialog auggie would shut down also, I tried 2 different gcode files and both crashed auggie. tried it 4 times and crashed 4 times, I used the same gcode files in that last version with no problems. also was having major problem like before with jogging it seems to loose position when axis zeroed..

I also get a message after I run the jog script, then try to jog with the jog buttons I get the message wrong state for jog on axis.
If I hit estop and then estop on it works again..

Let me know where I have you confused, and I will try to explain that area better...

I thinking maybe we should just try to get the axis's to be in sink with the dros first then go from there. this seems to me to be messing things up somewhat.
mostly with scripts. the script gcode moves seem to be way off.. and feed rates still off..

you may want to pull this version from the web site just incase running gcode may be a problem..

Gary

[ArtF]

Gary:

  Ill be running a lot of code tomorrow on my laser so I wont pull it till
I have. Your pretty much the only one running Gcode driven scripts so
our tests shouldn't affect anyone else.

  I would stay away from simulator mode, theres too many things not
hooked into it, such as probing, all bets are off in sim mode if you
use a probe as it may well confuse it badly. So lets stay on actual
hardware till we know whats going on.

Ok, so lets take it a touch at a time so I can try to figure out whats up,
I cannot duplicate your hardware and Im simulating a probe with a button
so we need it to be simple tests.

>>Tested the probe in the MDI one line G31 Z-1 F10, second line G0 Z0 F30, started to probe with dro's set to 0 so it probed till touch plate hit and stopped, ran the second line and it retracted back to start position 0..

OK, so thats good, no problem there.

>> The probeinve rt keeps it setting now when rebooting .

  This too is good, that fix seems to work.

>>sometimes it would only probe down a real short distance and then retract not hitting probe

  This one bothers me, it shouldn't be possible unless some script code is causing the probe to be interrupted
somehow.  My probe always goes down till I hit the button, then stops. This is all controlled by the pokeys
BUT I can see if the sync if off before the probe call, it may go down a short amount as it doesnt really know
the correct starting position, so something prior to the probe would have to be screwing the sync. Perhaps
zeroing the Z axis maybe. Though I added code to try to ensure that cant happen.

This is all too scattershot though, I need you to make a script that fails that I can easily test and we know it
will fail. Something like... run this script  call , jog left once at .01 and then the probe in the script doesnt
go down. Lets get this down to one example, that I can easily test with set parameter. Its best if ,as you describe
you can show me how to make the probe not go down all the way, in that scenario I shouldnt even have
to press the button. Lets get it to display one problem so I can kill it and then move to the next ..and so
on, I find Im having trouble duplicating your issue because I dont follow your workflow.

  If I can make it fail, its usually easy to fix, the problem is Im fixing what looks like it may fail..instead of what
does fail. The probe invert I could see so it was easy to fix.

  So if Im following you, I can zero my DRO's, then use the probe button and it doesnt always go down
all the way? Is this while running code and after an M6 hit, or just the pressing the probe
button in standby?

Im thinking if th eprobe doesnt go down all the commanded distance the only possability
is the engine isnt synced, we just need to figure out whats unsyncing it..

Art
 

 

So can you give me a scenario and a script that fail?




 

[ArtF]

Gary:

  On reflection on this, Id like for you to try an experiment for me,
can you reproduce the problem without triggering the probe at all.
So put the device at a good height. Make a simple GCode program..
like

G0X0Y0
M6
G0X10Y10
G0x0y0
m30

  Then, in the m6 dialog run, test your buttons. Can you make the probe not go down far
enough..if so I can reproduce it by following your instructions. I should
be able to fix whatever we find, and then we can see if the probe hit
works after we make sure no-hit scenarios work. Im just trying to cut
down on the possible things that can be biting us.

Art

[gburk]

thanks art

Will test it on the machine later today.

As for the probe testing its always been tested with the probe on screen button and scripts, not with the M6 dialog so lets say the M6 call isn't in play endless I am running a gcode file..

I did reinstall the last version of auggie last night and had no problem running the same gcode file in simulator mode. but as you request I will try all testing now in machine mode..

Will get back to you later, I had a feeling you would want to throw in the towel after my last message.. :o

Gary