Nozzle moves to corner of bed mid print and then resumes

[acharmedmatrix]

Hi I just started using this plugin and I have done a few test prints. Overall the prints have had massive improvement on curves, However, I have a very odd problem. Randomly during the print the nozzle will move to the corner of the bed and then immediately move back and resume the print. On a standard Benchy this happened twice. I circled the spot where you can see the error caused by this random movement.

[FormerLurker]

Can you send the before and after gcode? Also, are you using Octolapse? It can cause these movements.

[acharmedmatrix]

Yes I used OctoPrint. The print on the left is the original gcode. As you can see the zits were significantly improved, but the weird departure was not in the original.

Both gcodes are in this zip.

Thanks

Benchy.zip

[acharmedmatrix]

For further information this is happening with everything. Not just benchy. Here's another example. V3Test.zip

[FormerLurker]

Is there any way for you to tell me exactly what layer is having this problem? It's very difficult to pinpoint where the problem is otherwise, though I'll do what I can.

[acharmedmatrix]

I am printing the V3 test now and it just had the issue. It is on layer 8.

This was the first command sent when it started printing again N24002 G2 X155.075 Y91.998 I-699.132 J311.043 E890.05150*122

[FormerLurker]

What printer and firmware are you using? Here is a preview of that layer in simplify 3d (I verified the line of gcode you sent exists in that layer):

As you can see, there are no travel moves off of the component on that layer. Also, there is only one movement from the corner, and that is the initial move after priming:

There is also one movement at the end of the print, but I see that in the gcode file.

As I see it there are two possibilities:

1. There is some firmware issue. Please report the exact version of marlin you are using. The latest release, 2.0.6, just dropped a day or two ago, and can be found here. You'll notice this in the 'Bugs Patched' section: Fix G2/G3 Arcs segment bugs

2. This could be some undiscovered issue with OctoPrint or an installed plugin.

To narrow these two things down, I recommend trying to print one of those .aw gcode files directly from your SD card. If it works there, then we know it has something to do with OctoPrint or a plugin. If it does the same thing it is either a gcode issue (which I find no evidence of ATM) or a firmware issue.

Hopefully we can get this figured out!

[acharmedmatrix]

I am on 2.0.6 on an Ender 3 Pro. I will try printing from the SD Card and report back. Thanks

[acharmedmatrix]

Update: Downloading the gcode from OctoPrint and putting it on the SD Card it printed without issue.

I reuploaded the file to OctoPrint and tried again and had the same issue.

Enabled 3rd party plugins are: Spaghetti Detective, ArcWelder (duh), Bed Visualizer, DisplayLayerProgress, Enclosure Plugin, Exclude Region, FileManager, FullScreen Plugin, GcodeEditor, Octoprint-Display-ETA, and PrintTimeGenius.

Worth noting my description was slightly off. It will actually go to 0,0 on x,y and then it goes around the perimeter of the bed before returning to the print. I managed to catch a video of the tail end of this behavior. IMG_4590.zip

Edit: I've disabled all plugins except ArcWelder and I'm trying again.

[FormerLurker]

Yeah, lots of plugins there, so something def could be interfering. Pretty much noone is using G2/G3 ATM, so many plugins have never encountered them before. Also, no Octolapse (lol, j/k...)??

That video is absolutely bonkers. One of the craziest things I've ever seen a 3d printer do! Ok, I think I'm going to need a full serial log to figure it out. If we can see exactly what was sent to the printer and find the differences between the gcode file and the serial log that will point us to the exact issue. Do you know how to generate one of those with OctoPrint? If you can pin down exactly which plugin is causing the problem, or if it's a stock octoprint problem that will also help immensely.

Thanks for sticking through this arduous process to try to get the issue solved. It helps everyone in the community.

[acharmedmatrix]

Hah I don't have Octolapse because I don't like how it pauses for the photo.

I've also never seen anything like this so it's pretty interesting. Unfortunately even with every plugin disabled I had the same results. IMG_4596.zip

So unfortunately it seems like it's something in stock OctoPrint or some weird setting I have somewhere. I do not know how to obtain that log, but I'd be happy to do it.

Your plugin significantly improved the hull on these Benchys so I'm very hopeful that we can get it dialed in.

Edit: Found the option for serial log. Trying again.

[acharmedmatrix]

Log is attached. I killed the print immediately after the issue occurred. Looks like it was probably this:

Recv: Error:Line Number is not Last Line Number+1, Last Line: 42112

Or I know nothing, just a guess haha.

serial.log

[FormerLurker]

Lol! You may be right. I will take a look tomorrow, thanks for the log!

[acharmedmatrix]

Update: I have a second printer which is an Ender 3 (nonPro) also with Marlin 2.0.6 and running OctoPrint. It is having the same issue.

Side note: I forgot to mention both of these have SKR Mini E3 v1.2 mainboards.

[FormerLurker]

I couldn't find anything in the logs. I compared the last 20 or so lines of gcode and everything looked correct. I will continue to research.

[acharmedmatrix]

Weird. I made the firmware on both printers so entirely possible that I did something weird, but god knows what.

[FormerLurker]

It's unlikely since it's working via SD. Perhaps you can look at your OctoPrint printer profile and Serial Connection settings (all 4 tabs)? Screencaps may be useful to see if there are any non-standard settings in there.

[acharmedmatrix]

[FormerLurker]

Sorry it's been so long since I've had a chance to look at this. I have a theory about what might be wrong. It's possible that Marlin is having trouble with the precision of the I and J parameters for G2/G3. The line that appeared to fail has a really large offset:

G2 X110.378 Y112.331 I-44305.381 J-9.420 E2335.56923 F1500

Notice how small I is (-44305.381). That should be a valid value for I, but I have seen issues with much larger numbers, so maybe there is a connection. Fortunately I built in a setting to deal with this, or at least test to see if this is the problem. Change your ArcWelder settings to match this screen shot:

Then, try reprinting that benchy, and be sure to turn on serial logging again. Let me know how it goes, and post the serial log if you continue to have problems. If that settings change fixes the issue I think we will need to post this on the marlin github issues.

Thanks!

[acharmedmatrix]

Thanks for following up. Unfortunately this did not seem to solve the issue. I cancelled the print just as the nozzle returned to Benchy from one of its little walkabouts.

serial.log

[FormerLurker]

Ok, thanks for trying. I will try to install the firmware you have to test. Might take a while :(

[ldursw]

I had this exact issue 7 times in a single benchy print. I don't have the serial log for the first time but I have for the other 6.

• Layer 68
• Layer 222
• Layer 253
• Layer 259
• Layer 302
• Layer 312 twice

It seems to have a pattern. It starts with a response from Marlin with the line number missing, then on the next command it says the line number is wrong and asks to resend the command that has just been sent. When the command is sent again it seems the buffer is bypassed and the command is executed immediately.

Here is an excerpt of layer 253 with comments and line breaks added for clarity.

; Commands being processed normally
Send: N91900 G1 F2100 E3258.28037*53
Recv: ok N91900 P2 B31
Send: N91901 G1 F300 Z30.68*36
Recv: ok N91901 P2 B31
Send: N91902 G0 F10500 X106.641 Y117.522 Z30.68*38
Recv: ok N91902 P0 B31
Send: N91903 G1 F300 Z30.48*36
Recv: ok N91903 P1 B31
Send: N91904 G1 F2100 E3264.78037*59
Recv: ok N91904 P0 B31
...
Send: N91931 G1 X107.021 Y117.272 E3265.57825*91
Recv: ok N91931 P1 B31
Send: N91932 G0 F10500 X106.089 Y116.789*124
Recv: ok N91932 P2 B31

; Sent command 91933, received 'ok' without line number
Send: N91933 G3 X102.608 Y116.593 I256.266 J-4581.024 E3265.66006 F1213*37
Recv: ok P3 B31

; Sent command 91934, received error
Send: N91934 G1 X102.601 Y114.338 E3265.713*91
Recv: Error:Line Number is not Last Line Number+1, Last Line: 91932
Recv: Resend: 91933

; Also received ok from 91902, 30 commands before the last one.
; Maybe it's a buffering issue?
Recv: ok N91902 P3 B32

; Resend 91933, immediately executes, blocks the stream
Send: N91933 G3 X102.608 Y116.593 I256.266 J-4581.024 E3265.66006 F1213*37
Recv:  T:210.00 /210.0000 B:59.78 /60.0000 @:69 B@:0
Recv: echo:busy: processing
Recv:  T:210.00 /210.0000 B:59.70 /60.0000 @:69 B@:127
Recv: echo:busy: processing
Recv:  T:210.00 /210.0000 B:59.92 /60.0000 @:69 B@:127
Recv: echo:busy: processing
Recv:  T:210.00 /210.0000 B:60.12 /60.0000 @:69 B@:127
Recv: echo:busy: processing
Recv:  T:209.96 /210.0000 B:60.35 /60.0000 @:70 B@:127
Recv: echo:busy: processing
Recv:  T:210.00 /210.0000 B:60.68 /60.0000 @:69 B@:127
Recv: echo:busy: processing
Recv:  T:209.96 /210.0000 B:61.11 /60.0000 @:70 B@:0
Recv: echo:busy: processing
Recv:  T:210.00 /210.0000 B:61.26 /60.0000 @:69 B@:0
Recv: echo:busy: processing
Recv:  T:210.00 /210.0000 B:61.41 /60.0000 @:69 B@:0
Recv: echo:busy: processing
Recv:  T:210.04 /210.0000 B:61.50 /60.0000 @:68 B@:0
Recv: echo:busy: processing
Recv:  T:210.00 /210.0000 B:61.45 /60.0000 @:69 B@:0
Recv: echo:busy: processing
Recv:  T:210.00 /210.0000 B:61.47 /60.0000 @:69 B@:0
Recv: echo:busy: processing
Recv:  T:210.00 /210.0000 B:61.42 /60.0000 @:69 B@:0
Recv: echo:busy: processing
Recv:  T:210.00 /210.0000 B:61.31 /60.0000 @:69 B@:0
Recv: echo:busy: processing
Recv:  T:210.00 /210.0000 B:61.15 /60.0000 @:69 B@:0
Recv: echo:busy: processing
Recv:  T:210.00 /210.0000 B:61.03 /60.0000 @:69 B@:0
Recv: echo:busy: processing
Recv:  T:210.00 /210.0000 B:60.89 /60.0000 @:69 B@:0
Recv: echo:busy: processing
Recv:  T:210.00 /210.0000 B:60.72 /60.0000 @:69 B@:0

; Receive 'ok' for 91933
Recv: ok N91933 P0 B31

; The stream continues as usual
Send: N91934 G1 X102.601 Y114.338 E3265.713*91
Recv: ok N91934 P0 B31
Send: N91935 G1 X102.501 Y114.155 E3265.71789*85
Recv: ok N91935 P0 B31
Send: N91936 G1 X102.097 Y113.993 E3265.72811*84
Recv: ok N91936 P0 B31
Send: N91937 G1 F2100 E3259.22811*54
Recv: ok N91937 P0 B31
Send: N91938 G1 F300 Z30.68*46
Recv: ok N91938 P0 B31
Send: N91939 G0 F10500 X101.9 Y105.509 Z30.68*41
Recv: ok N91939 P0 B31

Still at layer 253 there is a message saying it encountered an unknown command. It seems that the start got truncated. Instead of receiving N92022 G2 it got 22 G2.

Send: N92021 G0 F10500 X120.769 Y102.393*115
Recv: ok N92021 P1 B31
Send: N92022 G2 X115.977 Y102.659 I54.510 J1021.463 E3267.56107 F1213*56
Recv: echo:Unknown command: "22 G2 X115.977 Y102.659 I54.510 J1021.463 E3267.56107 F1213"
Recv: ok P4 B31
Send: N92023 G1 X115.568 Y102.502 E3267.57129*90
Recv: Error:Line Number is not Last Line Number+1, Last Line: 92021
Recv: Resend: 92022
Recv: ok N91991 P4 B32
Send: N92022 G2 X115.977 Y102.659 I54.510 J1021.463 E3267.56107 F1213*56
Recv:  T:210.00 /210.0000 B:60.00 /60.0000 @:69 B@:0
Recv: ok N92022 P0 B31
Send: N92023 G1 X115.568 Y102.502 E3267.57129*90
Recv: ok N92023 P0 B31

What if in the previous example it got truncated in such a way that all the N part got removed and it started with just G3 making it run immediately?

At this point it looks more like an issue with serial rather than the firmware itself. I have an Ender 3 Pro with MKS Robin E3 board running Marlin 2.0.7.2. It uses a CH340 chip as Serial-to-USB converter. According to this Stack Exchange post the default 250000 baud used by OctoPrint is not supported.

I've recompiled the firmware to use 230400 baud but I haven't printed anything yet. I'll report back if this solved the issue or not.

We have some possibilities here.

1. This is a plugin bug that causes wrong movements
   • Unlikely because printing from SD card works
2. This is a firmware issue that doesn't interpret G2/G3 commands correctly
   • The commands should be correct because SD card printing works
3. This is a firmware issue w.r.t. serial communication
   • I'm not sure about that one. I have ADVANCED_OK enabled and BUFSIZE set to 32
4. This is a serial communication issue
   • It is more likely something is corrupting the data sent to Marlin and it is doing what the (corrupted) data told it to do.

For the sake of completeness, here is the gcode files: CE3PRO_3DBenchy.zip

[FormerLurker]

Very interesting. I will def look into this!

I have implemented a new firmware tester that you may want to try if you are willing to try an alpha version. The check isn't perfect, and there are still some things I need to fix, if you want to try it out you can install from the plugin manager by clicking 'Get More' then adding this line to the 'From Url...' box and clicking install: https://github.com/FormerLurker/ArcWelderPlugin/archive/d92528cdebf158f67b906caf99c50a35c7fcbc4e.zip

Once the install is finished, restart octoprint and make sure your printer is connected (this is one of the things that's broken). Then go to the arc-welder tab and click on the new 'Check Firmware' button. It is possible that a check has already completed.

Here is what it looks like:

If you have any problems running the checker, go to the arc welder settings and turn on verbose logging for the firmware checker like so:

Clear the current logs:

Save your settings changes:

Click on the firmware check in the Arc Welder Tab:

Then download and post your log file at gist.github.com. You can download it via the Octoprint logging menu, or go to the arc welder settings and click download log:

I've still got to add help files for various firmware versions with known issues, but for now you can just send me a snapshot of the checker and I'll let you know what your options are.

[ldursw]

I had to click it a few times to make it work. I could see M115 and the response in the terminal but it didn't update in the page. When trying to reproduce the issue I noticed that if I go to the Arc-Welder page right after Octoprint restarted the plugin would ask to check the firmware and clicking the button would start a firmware check but fails. After a few minutes it automatically updates the page with the right information.

I only had this issue once but can be reproduced if I delete current.json. I know this file is not supposed to be deleted but I just wanted to report this bug that may confuse the users when they first install the plugin.

Log file plugin_arc_welder.log Plugin configuration current.txt And a gif

Here are my configurations and the firmware compatibility check.

Following up on the previous message, I've printed a few items using 230400 baud and I haven't had any issues so far.

[FormerLurker]

Excellent 👍 i think I might know what the problem is. If you are willing to retest, I will send another link later.

Also, looks like your firmware is all good ;)

[ldursw]

Sure, I can test new versions as needed.

[cjamison08]

Ok, so I just noticed this same issue, would not have caught it, had it not sent my bed clips across the room, so I kept an eye on the print, untill it cleared the clips, and noticed it a few more times. Is there a workaround for this? Other than just running it from the sd card? I may just run the arc welder plugin from cura, instead of octoprint, and see if the issue reproduces itself that way.

[ldursw]

I've been trying to fix this issue since I posted here. Here's what I found out so far.

It only happens when there are arcs in the gcode. I did a 15-hour long print without arcs and got zero resends. A simple 20-minute print with arcs can have anywhere between 0 to 5 resends or sometimes even more. This bug is not deterministic, the exact same gcode file can have different resend ratios when printed multiple times and the part that had a resend can be different between prints.

It is definitely a bug in the firmware. I managed to reduce the resend count by changing some settings but there is always a few that refuse to go away. With this change the resends I got from benchy reduced from 90+ to around 6 and the nozzle stopped moving erratically.

Enable
#define SQUARE_WAVE_STEPPING
#define ADVANCED_OK

Change
#define BAUDRATE 921600
#define BLOCK_BUFFER_SIZE 64
#define MAX_CMD_SIZE 128
#define BUFSIZE 64
#define TX_BUFFER_SIZE 64
#define RX_BUFFER_SIZE 2048

Disable
#define SLOWDOWN
#define SERIAL_OVERRUN_PROTECTION

Again, this won't fix the issue, just mitigate it. The settings that had the most impact are BAUDRATE, SLOWDOWN, and SERIAL_OVERRUN_PROTECTION. All of them wait for data so the less time the firmware spends waiting, the less resends you get.

I'm using these settings with a MKS Robin E3. You may have to tweak the settings a bit to work with your board, especially the buffer sizes. The firmware will use a lot more RAM to compensate for the time it takes to resend a command.

OctoPrint 1.5 has a handy resend counter. I'd suggest upgrading it if you can to track whether the settings improved or not the issue.

[FormerLurker]

Can you guys try this latest devel version? There was one possible issue that could maybe be causing this (overflow issues caused by I+J values growing too large): https://github.com/FormerLurker/ArcWelderPlugin/archive/cb5e62706269bce0333017d095ace93ba815535e.zip

I'm planning to promote this to an RC, perhaps with a few other minor alterations. The firmware checker should now work as expected to, provided I have the info for the version in question.

[cjamison08]

If your using cura, the plugin for it, has completely mitigated the issue for me, it seems to be something within octoprint, that after missing a step, only sends a partial move code back to the printer. However with the cura plugin, it does not do this.

[ldursw]

@acharmedmatrix There was a firmware bug in STM32-based boards what would corrupt the command if it was longer than 64 characters. It's been fixed in the latest Marlin bugfix. I did a 12-hour print with Arc Welder and had no issues at all.

As your board is a SKR Mini E3 v1.2 and uses a STM32 microcontroller could you test the latest firmware, please?

In Configuration_adv.h set RX_BUFFER_SIZE to 128, compile, and flash.

[gxwilson69]

I'm seeing a very similar behavior. This is causing a similar head moving to the side and back to printing again. I'm using a Ender 3 Pro with a new 4.2.7 board with Marlin bugfix 2.0.X build. Its not every STL file but just those that have thin wall (I print planes).

Each time I've caught it doing the strange trip around the build plate I'm seen the same lines in the terminal log.

I've done this direct from the SD card, from Cura printing to OctoPrint (using Cura Plugin), sliced from Cura to Octoprint with the Arc Welder Plugin. For those certain models, its very consistent that Arc Welder will cause this problem.

Send: N6337 G0 X120.998 Y136.823*31
Recv: ok
Send: N6338 G3 X114.309 Y130.698 I3871.269 J-4234.457 E486.44228 F1500*28
Recv: ok
Send: N6339 M117 20% L=56/729*93
Recv: Error:Line Number is not Last Line Number+1, Last Line: 6337
Recv: Resend: 6338
Recv: ok
Send: N6338 G3 X114.309 Y130.698 I3871.269 J-4234.457 E486.44228 F1500*28
Recv: echo:busy: processing

[ldursw]

@gxwilson69 Please try changing RX_BUFFER_SIZE in Configurations_adv.h to 128. This change will only work on Marlin 2.0.8-2.0.9 or a recent bugfix.

Issue #175 has more details about this.

[LookItsRain]

Im still having issues with this, no matter what i set for RX_BUFFER_SIZE, or any other buffer/serial related settings, every arc welded gcode will produce a few resends no matter what. There is zero resends with a normal gcode file, have yet to find an actual solution in my specific case.

Tronxy X5SA with Chitu V6 board, STM32F103ZET6, most recent stable marlin and marlin bug fix tried.

[seantapscott]

This could be related to a lot of things. Which version of Marlin are you using? Is that the original board for the TronXY X5SA? I heard the original motherboard on those couldn't be flashed.

Other questions might be related to your connection settings such as baud rate? Are you using OctoPi or RepetierServer?

On Tue, Jun 29, 2021 at 9:50 PM LookItsRain @.***> wrote:

Im still having issues with this, no matter what i set for RX_BUFFER_SIZE, or any other buffer/serial related settings, every arc welded gcode will produce a few resends no matter what. There is zero resends with a normal gcode file, have yet to find an actual solution in my specific case.

Tronxy X5SA with Chitu V6 board, STM32F103ZET6, most recent stable marlin and marlin bug fix tried.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/FormerLurker/ArcWelderPlugin/issues/30#issuecomment-871036227, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE5J4UCLFOLSED36HOA4TL3TVJZ6JANCNFSM4PLAJ4MQ .

[LookItsRain]

Ive tried marlin versions from 2.0.8 to current stable 2.0.9.1, to current bugfix. Its the original tronxy x5sa board and yes it can be flashed with marlin. Using Octopi on a PI 4B 2GB, everything updated to most recent stable versions, baud rates of 115200 and 25000 tried. Again, no issues with non arc welded gcode.

[seantapscott]

I'm not the developer or maintainer, I just help answer questions or gather information occasionally here, but if I were to guess, I would have to suggest that you send over a sample of a small-model gcode file with arcs that are giving your printer/octopi combination trouble.

What settings have you used for RX_BUFFER_SIZE so far? I'm actually using 1024 byte RX_BUFFER_SIZE on a Creality board based on the same chipset as yours, and haven't had any issues, but it only works while using Marlin bugfix branch.

TLDR

• Sample gcode file with arcs?
• What settings have you used with RX_BUFFER_SIZE so far with the Marlin Bugfix branch?

On Wed, Jun 30, 2021 at 8:58 PM LookItsRain @.***> wrote:

Ive tried marlin versions from 2.0.8 to current stable 2.0.9.1, to current bugfix. Its the original tronxy x5sa board and yes it can be flashed with marlin. Using Octopi on a PI 4B 2GB, everything updated to most recent stable versions, baud rates of 115200 and 25000 tried. Again, no issues with non arc welded gcode.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/FormerLurker/ArcWelderPlugin/issues/30#issuecomment-871827363, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE5J4UE6LYUASM7UJUKIHHDTVO4VFANCNFSM4PLAJ4MQ .

[ldursw]

@LookItsRain Please post your Marlin configuration files, an example gcode file with and without Arc Welder, and a serial log of a failed print.

Serial logging can be enabled at Settings -> Serial Connection -> Serial logging -> Log communication to serial.log and restart OctoPrint. You can let it print all the way through or stop it after a few resends if you prefer. Then download the log and post it here.

[LookItsRain]

LookItsRain_AW_Testing.zip

Here are all the files, full print with 11 resends included in the log, non-arcwelded version of the same stl has 0 resends. Configuration.h and Configuration_adv.h included.

[ldursw]

It looks like a bug. I've made some changes at https://github.com/ldursw/Marlin/tree/tronxy. Please test this version with the following configuration.

#define BLOCK_BUFFER_SIZE 16
#define TX_BUFFER_SIZE 0
#define RX_BUFFER_SIZE 128

I'm assuming the environment for this board is chitu_f103 in platformio.ini.

[LookItsRain]

Can confirm this fork of marlin solved the issue, same arc welded gcode as sent earlier produced no resends along with some other arc welded gcode tried.

chitu_f103 is the correct environment, also chitu_v5_gpio_init is valid.

[FormerLurker]

Fyi all, I will probably add a setting to intelligently reduce precision to fit a given gcode length based on this thread.

[ldursw]

@LookItsRain Thanks for testing. You can now switch back to the official Marlin bugfix.

MarlinFirmware/Marlin#22292 has been merged. The PR should fix this issue once and for all. It is included in the latest bugfix and releases > 2.0.9.1.

@FormerLurker This is a good idea for a workaround. I have another idea in mind as well. The firmware check could send a command larger than 64 characters and check if the firmware replies with "Unknown Command". Maybe something like G21 0000000000000... would work and won't cause any side-effects.

[FormerLurker]

@ldursw, Is 64 characters the max before octoprint adds additional characters (line number + checksum)? Ideally I would know the following so I can add instructions/firmware warnings:

1. What is the max number of characters that OctoPrint can add to a gcode?
2. What are all of the firmware settings that affect the max length of the command, and how can I determine what the max length is given those settings. I assume some or all of these:

BLOCK_BUFFER_SIZE MAX_CMD_SIZE BUFSIZE TX_BUFFER_SIZE RX_BUFFER_SIZE

I am thinking about adding a little calculator to help people determine what the max gcode length should be.

Also, I've finished adding this feature (max_gcode_length) pending some testing. It will reject any arcs that produce gcodes larger than the max length. Once I finish verifying things are working as expected I'd appreciate some help testing :)

Thanks for all your help!

[ldursw]

What is the max number of characters that OctoPrint can add to a gcode?

Octoprint adds Nxxxx and checksum values when a command is sent internally. Let's suppose it was a busy day for an user and 10.5 million commands has been already sent to the printer. The command would look like: N10500200 G2 X10 Y42 I-0.313 J1.425 E0.28572*255.

The counter length will depend on how many commands was sent since the connection was opened. The checksum only goes from 0 to 255. In that example the command size would be 34 (gcode) + 10 (counter) + 4 (checksum) + 1 (new line) = 49.

When I was investigating this issue I couldn't reproduce it when sending the commands through the terminal. The command itself was shorter than 64 characters but when adding the counter and checksum it would be larger than that and thus would only occur when printing because the terminal sends the command exactly how you type it.

I am thinking about adding a little calculator to help people determine what the max gcode length should be.

By using the example as a starting point we can say a worst case would be gcode + 15 characters. A 12-hour print would have an average of 500k commands based on my experience (but it depends heavily on how complex the object is).

IMHO it would be better to alert the user that the firmware version may have some issues and use this feature as last resort if the firmware can't be updated. Preventing arcs to be created defeats the plugin's purpose. I understand why that would be necessary, though.

It's also not guaranteed that reducing each gcode size will eliminate the issue. Octoprint may decide to send some commands at once and that will also corrupt the buffer.

What are all of the firmware settings that affect the max length of the command, and how can I determine what the max length is given those settings.

Marlin has a buffer for the serial data so that it always has something to work on while more data is being received. The underlying framework Marlin is built on STM32 microcontrollers also has its own buffer with a default value of 64 bytes. Other microcontrollers such as AVR, LPC, and DUE are not affected.

If the host sends more than that at once it would silently corrupt the oldest data as it's a circular buffer and Marlin is not aware of that because the framework would deliver the data already corrupted. If the command is corrupted just enough so that Nxxxx is replaced with G2/G3 ... then the firmware will interpret as an immediate command and will do the arc at the wrong location, most likely clipping to the max/min of the build area.

Marlin sets its own serial buffer size with RX_BUFFER_SIZE and the framework uses USART_RX_BUF_SIZE (libmaple) or SERIAL_RX_BUFFER_SIZE (ststm32) depending on the build environment. Until very recently the framework size would always be the default 64 bytes regardless of the value RX_BUFFER_SIZE had. Now with that PR both values will always be the same for compatibility and the minimum was raised to 128 to reduce the chance of corruption.

[FormerLurker]

The firmware check could send a command larger than 64 characters and check if the firmware replies with "Unknown Command". Maybe something like G21 0000000000000... would work and won't cause any side-effects.

@ldursw, I missed this earlier! What a good idea!! I will try to implement this.

Also, I did add that feature. It's in the devel branch. Let me know if anyone here wants to try it out, as I could use some feedback. I adjusted a few other things, added travel move encoding, arachne engine support, and travel conversion statistics.