There is a quirk with G93 in one specific case that causes trouble. G93 for reasons unknown enforces a minimum feedrate of 0.1 units / min:
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/interp_inverse.cc#L65 ... length = find_arc_length(x1, y1, z1, cx, cy, turn, x2, y2, z2); rate = std::max(0.1, (length * block->f_number)); enqueue_SET_FEED_RATE(rate); ... This causes trouble because of how LinuxCNC understands feed rates / motion distances <http://linuxcnc.org/docs/2.5/html/gcode/machining_center.html#_a_id_sub_feed_rate_a_feed_rate>. As long as there is any XYZ motion longer than 1e-7 inches, the length of the motion is computed solely in terms of XYZ distance, and the ABC axes move at whatever feed is necessary to be in phase with the XYZ motion. An extreme example: N1 G20 G0 X0 Y0 Z0 A0 N2 G93 G1 Z-0.01 A[360*5] F1.0 (1 minute for 5 revolutions) The "length" in move N2 is 0.01 in. Based on the code above, the natural feed rate for this would be 0.01, but it's forced to be 0.1, or 10x higher than you'd expect. I think a smarter approach would be to check if the effective feed rate is too small (like below what a machine can actually execute) and throw an error, rather than silently "fixing" it like this. -Rob On Mon, Sep 14, 2020 at 10:44 AM Gene Heskett <ghesk...@shentel.net> wrote: > On Monday 14 September 2020 10:24:49 Scott Harwell via Emc-users wrote: > > > Andy > > I agree this seems more trouble than needed, but if you can get > > working G code for an example it should help in fixing the post. > > > > Could it be a problem with axis wrap (going past 359.999) in the > > formatting? I understand you can program multiple turns on the rotary > > axis but what dose the next move expect for an endpoint after rollover > > on actual position? From A0 to A720 is two rotations but is the next > > line for two rotations A 720 or A1440? > > > > Scott > > In my setups, others could be different, but angles are absolute using > home as a zero reference. > > Homeing on a rotary however is to the home switch, you can run it 45000 > degrees as in this thread, but it will rehome to 0, or whatever offset > from the switch is programmed, in under a turn. > > To answer the question, if you have run it to 720 previously, then a cmd > to go 1440, will turn it two more turns and conversely a cmd to > goto -1440 will turn it 6 turns in the opposite direction. > > > > On Monday, September 14, 2020, 4:30:45 AM CDT, andy pugh > > <bodge...@gmail.com> wrote: > > > > On Mon, 14 Sep 2020 at 04:38, Scott Harwell via Emc-users > > > > <emc-users@lists.sourceforge.net> wrote: > > > I found this it might help. > > > Scott > > > Rapid Rotary > > > > Along the same lines, there is a filter file here that automatically > > converts XY UV G-code to G93 based on which end is bigger. > > https://forum.linuxcnc.org/38-general-linuxcnc-questions/35141-a-head- > >scratcher-for-me?start=10#120524 > > > > The only reason I mention this is that it runs automatically as the > > G-code file is opened, rather than being a separate application. > > (And, to be fair, this isn't an option for RapidRotary as it needs to > > be able to query the working radius) > > > Cheers, Gene Heskett > -- > "There are four boxes to be used in defense of liberty: > soap, ballot, jury, and ammo. Please use in that order." > -Ed Howdershelt (Author) > If we desire respect for the law, we must first make the law respectable. > - Louis D. Brandeis > Genes Web page <http://geneslinuxbox.net:6309/gene> > > > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users