As described earlier, I have a probe I used to set the Z after changing tools.  
The Probe Z button calls an MDI which calls a .ngc g-code file which uses the 
G38 probe routine.

What I realized is the Feedrate Override mucks with the probe cycle.  The probe 
cycle needs to operate at a consistent speed, but Feedrate Override is being 
used, sometimes resulting in terribly slow or fast probes.

What are the options here?  The g-code can't ignore or set the Feedrate 
Override, can it?

All I could think of was tying the Probe Z button to a HAL which copies FO to a 
backup net "FeedOverride_Back" on rising edge, writes FO=1.0, and copies back 
on falling edge of is-auto.  This sounds super-convoluted.  

Also, important question to know overall- how could that work?  If I have a a 
rising edge of Probe Z button, and I both copy FO to FeedOverride_Back AND 
write FO=1.0 concurrently, is there a way to predict what gets stored in 
FeedOverride_Back?  This sounds like it's two separate threads, and you don't 
have a guarantee as to which executes first.  

e.g. Feedrate Override is 0.2.  Does FeedOverride_Back always get 0.2, or could 
FO=1.0 execute first so both Feedrate Override and FeedOverride_Back = 1.0, and 
the 0.2 value is lost forever?

Would it make sense to get sneaky and, inside the G-code for the probe, divide 
the desired F-parameter by the current Feedrate Override, e.g. desire F10, 
write F10/[some way to get Feedrate Override=0.2] = 50 which will result in a 
feedrate of 10 due to the 0.2 multiplier?

Danny


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to