The G2/G3 arc command can be specified using either the R parameter to describe the radius or the I/J parameter to describe the center of the arc.

If using the R parameter, unless you describe an arc of exactly 180 degrees, there are exactly 2 arcs which can fit the description, one goes through an angle under 180 degrees and one goes through an angle under 180 degrees. Both clockwise. (Counterclockwise arcs suffer the same issue, of course.)

For example, moving between the two white circles (left to right) here spaced 10 units apart with a counterclockwise arc of radius 7.07, one can construct the shorter (red) arc which traverses 90 degrees or the longer (blue) arc which traverses 270 degrees. Both have the same radius, both start and end at the right points.

It appears as though RRF always chooses the longer of the two arcs. At least it does on my machine for the path I just constructed. I would have expected the shorter, since now it appears there is no way to traverse an arc under 180 degrees.

Is this the intended behavior? It seems like one should never use the R parameter for arcs given this ambiguity and use the (over-constrained) I/J parameters instead. Perhaps there should be another parameter which specifies which of the two arcs to traverse? Or perhaps just use the shorter of the two arcs?

The Marlin firmware doesn't define the behavior either, but their example has an arc of 90 degrees. I don't have a printer with Marlin on it anymore to test.

FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC FIRMWARE_VERSION: 3.1.1 ELECTRONICS: Duet 3 MB6HC v1.01 or later FIRMWARE_DATE: 2020-05-19b2

It appears in CNC a negative R value will correspond to the arc over 180 degrees and a positive one will correspond to the arc under 180 degrees. Seems reasonable.

https://www.cnccookbook.com/cnc-g-code-arc-circle-g02-g03/

In RRF, for my path, a negative R value has the same effect as a positive R value.

G0 X20 Y0 Z10 F6000

G2 X0 Y-20 R20
G2 X-20 Y0 R20
G2 X0 Y20 R20
G2 X20 Y0 R20

@bot Not a typo, just showing the path I'm using. I don't think RRF claims to support negative radii parameters in any capacity, but that's tangential to the original post.

For clarity, the following two paths produce the same motion on my machine:

G0 X20 Y0 Z10 F6000
 
G2 X0 Y-20 R20
G2 X-20 Y0 R20
G2 X0 Y20 R20
G2 X20 Y0 R20

G0 X20 Y0 Z10 F6000
 
G2 X0 Y-20 R-20
G2 X-20 Y0 R-20
G2 X0 Y20 R-20
G2 X20 Y0 R-20

Very much not a new thing:
https://github.com/TheLongRunSmoke/g1tog23

I saw in other posts that the distance is not user-configurable, and is actually not fixed, but it's hard to know if that is still accurate.

Still a bit disappointed G2/G3 isn't natively supported but it is what it is. I didn't verify the fix in the latest RC.

Running sudo /opt/dsf/bin/CodeConsole from the console seems to work.

Here's my code to log in using Python with the default user/pass. After this, sending commands works:

tn = telnetlib.Telnet(printer_ip)
print(tn.read_until(b"login: ").decode('utf=8', errors='ignore'))
tn.write(b'pi\n')
print(tn.read_until(b"Password: ").decode('utf=8', errors='ignore'))
tn.write(b'raspberry\n')
print(tn.read_until(b"$ ").decode('utf=8', errors='ignore'))
tn.write(b'sudo /opt/dsf/bin/CodeConsole\n')
print(tn.read_until(b"Connected!").decode('utf=8', errors='ignore'))

tn.write(b'M114\n')
sleep(1.0)
print(tn.read_very_eager().decode('utf=8', errors='ignore'))

I have a Duet3 6HC board connected with a Raspberry Pi. It works, I can print files, view the web interface, etc. Is there a way I can programmatically (Python) run commands remotely on this setup? I have it set up where I can telnet into the RPi, but obviously entering gcode commands in the console doesn't work.

I also have a Duet2 Wifi board where I can telnet into the board and just send commands to run them. I'm essentially looking for the same functionality on the Duet3 + SBC setup.

@MJLew said in G2/G3 arcs with R parameter traverse the longer of the two arcs:

The problem is not just when the r parameter is being used. Even with I and J I cannot achieve an arc of less than 180 degrees.

I can't reproduce this. The following moves through four 90 degree segments of a circle with radius 20 without issue:

G0 X20 Y0 Z10

G2 I-20 J0 X0 Y-20
G2 I0 J20 X-20 Y0
G2 I20 J0 X0 Y20
G2 I0 J-20 X20 Y0

@Grudairian said in Wiring problem:

Do you have an approach you would recommend?

Anything that gets rid of the 6A current limitation. If your heater pulls 40W, you're pulling over 3.33A from the 12V line. More because your step-up converter can't be 100% efficient.

Using directly soldered wires rather than the ATX connector is one solution. Just gotta be mindful of other current limits in the system.

The ATX connector pins are rated to 6A. I think you're just exceeding that limit, or getting close to it. The other connections (screw terminals) aren't the problem.

If you're using 150W, you're pulling at least 12.5A out of that pin. And since you're using a step-up converter, you would be even higher.

@bot Not a typo, just showing the path I'm using. I don't think RRF claims to support negative radii parameters in any capacity, but that's tangential to the original post.

For clarity, the following two paths produce the same motion on my machine:

G0 X20 Y0 Z10 F6000
 
G2 X0 Y-20 R20
G2 X-20 Y0 R20
G2 X0 Y20 R20
G2 X20 Y0 R20

G0 X20 Y0 Z10 F6000
 
G2 X0 Y-20 R-20
G2 X-20 Y0 R-20
G2 X0 Y20 R-20
G2 X20 Y0 R-20

It appears in CNC a negative R value will correspond to the arc over 180 degrees and a positive one will correspond to the arc under 180 degrees. Seems reasonable.

https://www.cnccookbook.com/cnc-g-code-arc-circle-g02-g03/

In RRF, for my path, a negative R value has the same effect as a positive R value.

G0 X20 Y0 Z10 F6000

G2 X0 Y-20 R20
G2 X-20 Y0 R20
G2 X0 Y20 R20
G2 X20 Y0 R20

The G2/G3 arc command can be specified using either the R parameter to describe the radius or the I/J parameter to describe the center of the arc.

If using the R parameter, unless you describe an arc of exactly 180 degrees, there are exactly 2 arcs which can fit the description, one goes through an angle under 180 degrees and one goes through an angle under 180 degrees. Both clockwise. (Counterclockwise arcs suffer the same issue, of course.)

For example, moving between the two white circles (left to right) here spaced 10 units apart with a counterclockwise arc of radius 7.07, one can construct the shorter (red) arc which traverses 90 degrees or the longer (blue) arc which traverses 270 degrees. Both have the same radius, both start and end at the right points.

It appears as though RRF always chooses the longer of the two arcs. At least it does on my machine for the path I just constructed. I would have expected the shorter, since now it appears there is no way to traverse an arc under 180 degrees.

Is this the intended behavior? It seems like one should never use the R parameter for arcs given this ambiguity and use the (over-constrained) I/J parameters instead. Perhaps there should be another parameter which specifies which of the two arcs to traverse? Or perhaps just use the shorter of the two arcs?

The Marlin firmware doesn't define the behavior either, but their example has an arc of 90 degrees. I don't have a printer with Marlin on it anymore to test.

FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC FIRMWARE_VERSION: 3.1.1 ELECTRONICS: Duet 3 MB6HC v1.01 or later FIRMWARE_DATE: 2020-05-19b2

@CaLviNx said in True Bed Leveling:

Really ? please tell me how can you be 100% of that without physically being there and laying the milled tool plate on a granite surface plate and physically measuring to see if it is warped or not

I'm going off of this picture by OP:

@ErwinH78 said in True Bed Leveling:


in which you can see the bed is clearly non-planar. A warped frame or non-planar XY motion could also cause this.

Since bed leveling only adjusts the best fit plane, it's not going to remove the one corner that is warped upward.