Home › Forums › TinyG › TinyG Support › G3 support for negative R
- This topic has 13 replies, 3 voices, and was last updated 11 years ago by
vane.
-
AuthorPosts
-
October 17, 2013 at 5:06 pm #4814
vane
MemberHello,
I’m running tinyg firmware 0.95. I’m having problems with generated g-code that contains G3 codes with negative R. Is this particular g-code supported? The wiki isn’t clear about itOctober 18, 2013 at 1:42 am #4822Makerboost
MemberWhat kinds of problems are you experiencing?
October 18, 2013 at 7:33 am #4824MemberCorrect me if I’m totally off base, but shouldn’t negative radius create a G2 code instead?
If you wanted a G3 code, but you’re inverting the radius, then you’re telling it to go CW instead?
Long day at work, so my mind is not working at peak efficency 😉
-
This reply was modified 11 years, 1 month ago by
Makerboost.
October 18, 2013 at 8:37 am #4826alden
MemberG3 should work with negative Rs. Can you post or make available the Gcode you are having problems with and some description of the problem?
@Makerboost : For a discussion of negative R see here:
http://www.cnccookbook.com/CCCNCGCodeArcsG02G03.htmOctober 18, 2013 at 9:41 am #4827MemberAh, my mistake. Thank you for the informative link!
October 21, 2013 at 10:58 am #4839MemberHello,
Sorry for the late reply (vacation). I can use any negative R example really.
Like this in CoolTerm:G17 F300 tinyg [mm] ok> G2 X10 Y15 R20 tinyg [mm] ok> posx:0.004,posy:0.019,vel:149.997,momo:2,stat:5 .............................. posx:9.921,posy:14.958,vel:300.011 posx:10.000,posy:15.000,vel:0.000,stat:3 g0 x0 y0 tinyg [mm] ok> posx:9.393,posy:14.090,vel:2781.455,momo:0,stat:5 posx:3.844,posy:5.766,vel:7258.114 posx:0.067,posy:0.101,vel:806.456 posx:0.000,posy:0.000,vel:0.000,stat:3But now when I try this:
G2 X10 Y15 R-20 tinyg [mm] err: Arc specification error: G2 X10 Y15 R-20Here is a dump of my settings:
$$ [fb] firmware build 380.02 [fv] firmware version 0.95 [hv] hardware version 7.00 [id] TinyG ID 1H4973-HSY [ja] junction acceleration 2000000 mm [ct] chordal tolerance 0.001 mm [st] switch type 0 [0=NO,1=NC] [mt] motor disble timeout 60 Sec [ej] enable json mode 0 [0=text,1=JSON] [jv] json verbosity 3 [0=silent,1=footer,2=messages,3=configs,4=linenum,5=verbose] [tv] text verbosity 1 [0=silent,1=verbose] [qv] queue report verbosity 0 [0=off,1=filtered,2=verbose] [sv] status report verbosity 1 [0=off,1=filtered,2=verbose] [si] status interval 100 ms [ic] ignore CR or LF on RX 0 [0=off,1=CR,2=LF] [ec] expand LF to CRLF on TX 0 [0=off,1=on] [ee] enable echo 1 [0=off,1=on] [ex] enable xon xoff 1 [0=off,1=on] [baud] USB baud rate 5 [1=9600,2=19200,3=38400,4=57600,5=115200,6=230400] [gpl] default gcode plane 0 [0=G17,1=G18,2=G19] [gun] default gcode units mode 1 [0=G20,1=G21] [gco] default gcode coord system 1 [1-6 (G54-G59)] [gpa] default gcode path control 2 [0=G61,1=G61.1,2=G64] [gdi] default gcode distance mode 0 [0=G90,1=G91] [1ma] m1 map to axis 0 [0=X,1=Y,2=Z...] [1sa] m1 step angle 1.800 deg [1tr] m1 travel per revolution 36.540 mm [1mi] m1 microsteps 8 [1,2,4,8] [1po] m1 polarity 1 [0=normal,1=reverse] [1pm] m1 power management 1 [0=remain powered,1=shut off when idle] [2ma] m2 map to axis 1 [0=X,1=Y,2=Z...] [2sa] m2 step angle 1.800 deg [2tr] m2 travel per revolution 36.540 mm [2mi] m2 microsteps 8 [1,2,4,8] [2po] m2 polarity 1 [0=normal,1=reverse] [2pm] m2 power management 1 [0=remain powered,1=shut off when idle] [3ma] m3 map to axis 1 [0=X,1=Y,2=Z...] [3sa] m3 step angle 1.800 deg [3tr] m3 travel per revolution 36.540 mm [3mi] m3 microsteps 8 [1,2,4,8] [3po] m3 polarity 0 [0=normal,1=reverse] [3pm] m3 power management 1 [0=remain powered,1=shut off when idle] [4ma] m4 map to axis 2 [0=X,1=Y,2=Z...] [4sa] m4 step angle 1.800 deg [4tr] m4 travel per revolution 1.250 mm [4mi] m4 microsteps 4 [1,2,4,8] [4po] m4 polarity 0 [0=normal,1=reverse] [4pm] m4 power management 1 [0=remain powered,1=shut off when idle] [xam] x axis mode 1 [standard] [xvm] x velocity maximum 10000.000 mm/min [xfr] x feedrate maximum 10000.000 mm/min [xtm] x travel maximum 220.000 mm [xjm] x jerk maximum 5000000000 mm/min^3 [xjh] x jerk homing 10000000000 mm/min^3 [xjd] x junction deviation 0.0100 mm (larger is faster) [xsn] x switch min 1 [0=off,1=homing,2=limit,3=limit+homing] [xsx] x switch max 0 [0=off,1=homing,2=limit,3=limit+homing] [xsv] x search velocity 3000.000 mm/min [xlv] x latch velocity 100.000 mm/min [xlb] x latch backoff 2.000 mm [xzb] x zero backoff 3.000 mm [yam] y axis mode 1 [standard] [yvm] y velocity maximum 10000.000 mm/min [yfr] y feedrate maximum 10000.000 mm/min [ytm] y travel maximum 220.000 mm [yjm] y jerk maximum 5000000000 mm/min^3 [yjh] y jerk homing 10000000000 mm/min^3 [yjd] y junction deviation 0.0100 mm (larger is faster) [ysn] y switch min 1 [0=off,1=homing,2=limit,3=limit+homing] [ysx] y switch max 0 [0=off,1=homing,2=limit,3=limit+homing] [ysv] y search velocity 3000.000 mm/min [ylv] y latch velocity 100.000 mm/min [ylb] y latch backoff 2.000 mm [yzb] y zero backoff 3.000 mm [zam] z axis mode 1 [standard] [zvm] z velocity maximum 300.000 mm/min [zfr] z feedrate maximum 600.000 mm/min [ztm] z travel maximum 100.000 mm [zjm] z jerk maximum 50000000 mm/min^3 [zjh] z jerk homing 100000000 mm/min^3 [zjd] z junction deviation 0.0100 mm (larger is faster) [zsn] z switch min 0 [0=off,1=homing,2=limit,3=limit+homing] [zsx] z switch max 1 [0=off,1=homing,2=limit,3=limit+homing] [zsv] z search velocity 600.000 mm/min [zlv] z latch velocity 100.000 mm/min [zlb] z latch backoff 2.000 mm [zzb] z zero backoff 3.000 mm [aam] a axis mode 3 [radius] [avm] a velocity maximum 172800.000 deg/min [afr] a feedrate maximum 172800.000 deg/min [atm] a travel maximum -1.000 deg [ajm] a jerk maximum 5760000000 deg/min^3 [ajh] a jerk homing 5760000000 mm/min^3 [ajd] a junction deviation 0.0500 deg (larger is faster) [ara] a radius value 0.1989 deg [asn] a switch min 1 [0=off,1=homing,2=limit,3=limit+homing] [asx] a switch max 0 [0=off,1=homing,2=limit,3=limit+homing] [asv] a search velocity 600.000 deg/min [alv] a latch velocity 100.000 deg/min [alb] a latch backoff 5.000 deg [azb] a zero backoff 2.000 deg [bam] b axis mode 0 [disabled] [bvm] b velocity maximum 3600.000 deg/min [bfr] b feedrate maximum 3600.000 deg/min [btm] b travel maximum -1.000 deg [bjm] b jerk maximum 20000000 deg/min^3 [bjd] b junction deviation 0.0500 deg (larger is faster) [bra] b radius value 1.0000 deg [cam] c axis mode 0 [disabled] [cvm] c velocity maximum 3600.000 deg/min [cfr] c feedrate maximum 3600.000 deg/min [ctm] c travel maximum -1.000 deg [cjm] c jerk maximum 20000000 deg/min^3 [cjd] c junction deviation 0.0500 deg (larger is faster) [cra] c radius value 1.0000 deg [p1frq] pwm frequency 100.000 Hz [p1csl] pwm cw speed lo 1000.000 RPM [p1csh] pwm cw speed hi 2000.000 RPM [p1cpl] pwm cw phase lo 0.125 [0..1] [p1cph] pwm cw phase hi 0.200 [0..1] [p1wsl] pwm ccw speed lo 1000.000 RPM [p1wsh] pwm ccw speed hi 2000.000 RPM [p1wpl] pwm ccw phase lo 0.125 [0..1] [p1wph] pwm ccw phase hi 0.200 [0..1] [p1pof] pwm phase off 0.100 [0..1] [g54x] g54 x offset 0.000 mm [g54y] g54 y offset 0.000 mm [g54z] g54 z offset 0.000 mm [g54a] g54 a offset 0.000 deg [g54b] g54 b offset 0.000 deg [g54c] g54 c offset 0.000 deg [g55x] g55 x offset 75.000 mm [g55y] g55 y offset 75.000 mm [g55z] g55 z offset 0.000 mm [g55a] g55 a offset 0.000 deg [g55b] g55 b offset 0.000 deg [g55c] g55 c offset 0.000 deg [g56x] g56 x offset 0.000 mm [g56y] g56 y offset 0.000 mm [g56z] g56 z offset 0.000 mm [g56a] g56 a offset 0.000 deg [g56b] g56 b offset 0.000 deg [g56c] g56 c offset 0.000 deg [g57x] g57 x offset 0.000 mm [g57y] g57 y offset 0.000 mm [g57z] g57 z offset 0.000 mm [g57a] g57 a offset 0.000 deg [g57b] g57 b offset 0.000 deg [g57c] g57 c offset 0.000 deg [g58x] g58 x offset 0.000 mm [g58y] g58 y offset 0.000 mm [g58z] g58 z offset 0.000 mm [g58a] g58 a offset 0.000 deg [g58b] g58 b offset 0.000 deg [g58c] g58 c offset 0.000 deg [g59x] g59 x offset 0.000 mm [g59y] g59 y offset 0.000 mm [g59z] g59 z offset 0.000 mm [g59a] g59 a offset 0.000 deg [g59b] g59 b offset 0.000 deg [g59c] g59 c offset 0.000 deg [g92x] g92 x offset 0.000 mm [g92y] g92 y offset 0.000 mm [g92z] g92 z offset 0.000 mm [g92a] g92 a offset 0.000 deg [g92b] g92 b offset 0.000 deg [g92c] g92 c offset 0.000 deg [g28x] g28 x location 0.000 mm [g28y] g28 y location 0.000 mm [g28z] g28 z location 0.000 mm [g28a] g28 a location 0.000 deg [g28b] g28 b location 0.000 deg [g28c] g28 c location 0.000 deg [g30x] g30 x location 0.000 mm [g30y] g30 y location 0.000 mm [g30z] g30 z location 0.000 mm [g30a] g30 a location 0.000 deg [g30b] g30 b location 0.000 deg [g30c] g30 c location 0.000 deg tinyg [mm] ok>I use a (commercial) g-code generator from work, and I can’t for the life or me make it not generate G2-G3 Rs (positive or negative)
October 21, 2013 at 6:50 pm #4840MemberTry returning to g0 x0 y0 before attempting the negative arc. Entering the second arc command was trying to draw a 360 degree arc in radius mode – same start and end points. Radius mode is not supposed to be used for arcs more than about 180 degrees, or they lose too much accuracy. The system tries to compensate the best it can, but at some point it gives up and throws an arc specification error.
October 21, 2013 at 7:09 pm #4842MemberThe log I posted contained a return to 0. The commands were copied from the same coolterm session. So omitting the verbose responses, they went like this:
G17 F300 G2 X10 Y15 R20 G0 X0 Y0 G2 X10 Y15 R-20… with the error reply for the last command. In fact, even after a fresh reset (coordinates at 0 0 0), I can’t find a combination of -R values that work (they all give the same error).
Just to rule it out, can you confirm that my example works for you, or give me a sequence of g-code that eventually contain -R that works for you?
ThanksOctober 21, 2013 at 8:52 pm #4843MemberI ran your test on build 380.02, and 380.08, which is the current master branch. Both fail the way you have experienced. The test I ran that worked was on the development branch – build 396.03. So you ave discovered a bug in the earlier revisions. We can walk you through a firmware upgrade or swap out your board.
October 22, 2013 at 9:16 am #4845MemberAlden, I’ve loaded this binary https://github.com/synthetos/TinyG/blob/dev/firmware/tinyg/Debug/tinyg.hex via avrdude/bootloader, and negative Rs look like they work now. Is that a a sufficiently up-to-date binary (I suspect it was compiled with debug option on, given the URL)? I will compile the project myself at some point (to poke my nose in a little), by I’m a little busy atm. If you have a fresher binary please push it, and post a link.
Thanks again for the supportOctober 22, 2013 at 12:45 pm #4847MemberThe hex file you loaded (build 396.03) is the current file in the dev branch. Dev is used for development and testing. Once things are relatively stable in dev they are moved to edge, where they are tested some more, then finally to master for general release.
The hex you got was not a “debug” hex, per se – in that it did not have any extra debugging code – that’s just where the complier puts things.
Build 396.03 should actually be pretty stable as I’ve been incrementally moving things along in dev. You should stick with that until there’s an edge push – probably some time in the next few weeks. Please let me know if you have any problems with it.
October 24, 2013 at 9:50 am #4857MemberI’ve made some simple tests using G2/G3 and R. I don’t know if this is normal, but there are dramatic differences between R arcs and IJ arcs of the same dimensions. Example: a 50mm 90deg arc expressed with R diverges from the same IJ arc with ~7mm. The R arcs are way flatter than they should be.
On the brighter side, I’ve managed to make my g-code generator to generate only IJ arcs, which work just fine, so this issue is concluded for me.October 24, 2013 at 10:07 am #4858MemberThanks for doing these tests. I’m glad the issue is closed for you.
It’s a known property (of Gcode) that radius arcs suffer from accuracy errors; which is the reason center arcs are always recommended. Usually this is only obvious on arcs with larger angular travel – and error blows up completely for 360 degree arcs (cannot be drawn).
Separately, center arcs are supposed to be specified with the center falling on the normal line bisecting the chord spanning the arc endpoints. As mentioned before, there is some tolerance in the arc algorithm if this is not exactly true. If the center is too far off the line the arc will err out with a specification error. So it’s possible that the differences between R and IJ arcs is due to the fact that the R will (or should) compute the exact centerline and the IJ center may be off. I don’t know if this is happening here.
What angles are you testing? Can you copy and paste some Gcode? I’d like to know if the R arcs are within tolerance or if I still have work to do on R arc generation.
Thanks
October 24, 2013 at 12:35 pm #4859MemberA basic example:
g0 x0 y0 f300 g2 x30 y30 i30 j0 g3 x0 y0 r30This should make a clockwise quadrant from (0, 0) with ij, and return to (0, 0) counter-clockwise with a R quadrant. The quadrants should ideally be identical. In reality, they are visibly distinct (at most 2mm+ apart), only their ends coincide. I’m sure it’s easy to reproduce, otherwise i would take a pic of an engraving test i made.
Again, I’m not sure that 90 degrees is not too big an arc, but some g-code example i saw in a tutorial was making a circle out of 4 G2+R quadrants, so it seems this should be acceptable precision-wise -
This reply was modified 11 years, 1 month ago by
-
AuthorPosts
- You must be logged in to reply to this topic.
