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