G02/G03 commands yes or no, or do I miss something else?

Mostly Printed CNC - MPCNC Troubleshooting
1

I fired my second MPCNC up today, as I brought the controller with me from the first build, I did not expect any troubles, and there was none.
I updated that deviation setting from 0.05 to 0.1, and went for the crown.
The first test went pretty slow around corners, same as I knew from my first build.
On the second test I disabled the G02/G03 in Estlcam and it goes much faster around corners.
Are the G02/G03 commands to be avoided as a rule of thumb, or are I missing some major update in my firmware. I use the dual endstop version with Marlin 2.??.
As mentioned b4 I changed the deviation setting, b4 that my last change was the laser delay.


2

I would love for you to run that same test with the current 412 version of the firmware. I am trying to just get above the arc threshold with the tuning.

3

Grrr, forum ate my post, so now just the filed, did the update to ā€œ412ā€ but results pretty much same.

Marlin-MPCNC_Dual_412_CSaen_build-2.7z (2.92 MB)

Marlin-MPCNC_Dual_412_CSaen_build-2.zip (2.86 MB)

4

It made it to my email:

1 Like
5

Can you try M503 (reports EEPROM settings) and post the results here? If you have not deliberately tuned your accelerations and there is nothing you are attached to, you can also try M502 and M500. The EEPROM settings are not overwritten when you update firmware, I learned a while ago first-hand. It is probably not your acceleration settings, but this would rule it out.

6

Also for fun I plotted the gcode in Excel, and it highlights the points where the arcs start/end. It is interesting that some of these points coincide with the jerky points in your movement, but Iā€™m not sure what to conclude from it. Maybe someone else will have more insight.

[attachment file=117656]

excel_crown.png
excel_crown.png939Ɨ638 54.9 KB

1 Like
7

Here we go. Iā€™m not so sure that the EEPROM settings are not overwritten.

It seems that the new acceleration values (400) are stored, they were ā€œ#define DEFAULT_MAX_ACCELERATION { 600, 600, 100, 2000 }ā€ in my previous version (402)

>>>M503
SENDING:M503
echo: G21 ; Units in mm (mm)
echo: M149 C ; Units in Celsius
echo:Filament settings: Disabled
echo: M200 D3.00
echo: M200 D0
echo:Steps per unit:
echo: M92 X200.00 Y200.00 Z3200.00 E200.00
echo:Maximum feedrates (units/s):
echo: M203 X120.00 Y120.00 Z12.00 E25.00
echo:Maximum Acceleration (units/s2):
echo: M201 X400.00 Y400.00 Z100.00 E2000.00
echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
echo: M204 P400.00 R3000.00 T400.00
echo:Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> J<junc_dev>
echo: M205 B20000.00 S0.00 T0.00 J0.05
echo:Home offset:
echo: M206 X0.00 Y0.00 Z0.00
echo:Endstop adjustment:
echo: M666 X0.00 Y0.00
echo:Material heatup parameters:
echo: M145 S0 H196 B92 F0
echo: M145 S1 H240 B110 F0
echo:PID settings:
echo: M301 P17.98 I0.98 D83.62

Ā 

8

If you want to reset to whatā€™s in Configuration.h, you can use M502.

http://marlinfw.org/docs/gcode/M502.html

Sometimes, it resets on itā€™s own, if the version written in the EEPROM doesnā€™t match whatā€™s in the firmware.

9

Has been a while since I tinkered with this build, worked a bit on cable management (ehhhh boring). And did some drawings with the pen today.
Out of curiosity, I tried one of them with the G02/G03 commands enabled. Well I gave it up pretty fast.
Out of curiosity. This ā€œdeviationā€ settings is that something new on Marlin?
How about older versions of Marlin firmware, do they face similar problems?
Is this ā€œjunction deviationā€ setting something whatā€™s meant to replace the ā€œjerk-settingsā€?
Iā€™m wondering if the 8-bit boards are just not able to handle it.
Iā€™ve already a 32-bit board here, all Iā€™m waiting for is the drivers to arrive.

10

Iā€™ve been meaning to dig into this more but I havenā€™t gotten to it.

I can say with confidence itā€™s not an issue due to 8-bit boards being underpowered. The command queue is not depleted so it has enough CPU to keep up.

1 Like
11

For now it is best to keep arcs off.

12

Yep, would agree.
I tried to adjust a bit, within reason, every time made the setting a bit larger, the time came a bit down, but no way near when the arcs are off.
The g-code becomes about 4 times larger when the arcs are off.

13

Luckily file size is almost of no concern, it gets ugly with trichoidal on but we cut slow enough to where no one has reported buffer issues yet.

1 Like