search

FormerLurker / ArcWelderPlugin

A plugin for OctoPrint used to convert G0/G1 commands to G2/G3 commands. Reduce the size of your gcode files, and reduce number of gcodes per second sent to your printer.
Other
443 stars 26 forks source link

Arc Welder causing Layer Shift #113

Closed rizwansarwar closed 3 years ago

rizwansarwar commented 3 years ago

Hi @FormerLurker,

Apologies if you have already fixed this as I know you have done fair bit of work since the first release. I wanted to report it in case you have not.

I noticed layer shifts on a print today, I suspected it was the Arc Welder so I printed the non-converted version which resulted in no layer shifts. The layer shift occurs between Layer 20 to 24, there might be more later in the print but I did not bother completing as I could repeat layer shifts between 20-24 multiple times. I have attached both GCodes for comparison. I think something is going wrong during conversion. Would really appreciate if you have a look at your leisure.

screwmeasuringtool_raised_letters_0.2mm_PLA_ENDER3_4h7m.gcode.zip screwmeasuringtool_raised_letters_0.2mm_PLA_ENDER3_4h7m.aw.gcode.zip

FormerLurker commented 3 years ago

Of course, I will take a look. I may ask you to install the devel version since there are more features in there to help diagnose issues, as well as several fixes and enhancements. If you are willing, I will send instructions. I should be able to take a look at your gcode before and after over the weekend, which starts tomorrow for me. If something is wrong with the gcode itself, I will probably find it.

Thanks for your post!

FormerLurker commented 3 years ago

Ok, so I've not found any issues with the GCode, so at this point I'm suspecting either some serial communication issue or a firmware issue. The serial issue might actually be firmware too because I'm working on a few other similar problems that only seem to happen in creality firmware. What printer are you using?

Finally, if you are willing to try the devel version, you can install it with the plugin manager (OctoPrint Settings->Plugin Manager->Get More->From Url...) with this link: https://github.com/FormerLurker/ArcWelderPlugin/archive/a0f41e1ae75443805278b643ed9162bfcae17394.zip

Though this is not quite ready for a production release, in many ways this is the safest version of ArcWelder to use. It has many extra safeguards to prevent issues. In fact, I think that after a year of development I finally feel like the core algorithm is finally complete. It's really the plugin part that needs additional work.

I'm interested in what the new firmware checker says about your firmware mostly. If you install it send me a snapshot of the firmware checker (it's on the tab), and I would also appreciate any feedback you have regarding the new version.

Thanks!

Hextler commented 3 years ago

Same Bug occured with my Ender 5 Pro. I will try the devel version of Arc-Welder as soon as my current print finishes.

Ive seen once why this layer shift happened on my maschine: The Tool runned all the way in X_max direction. It even hit the hardware boundaries and tried to go past them, resulting in loud noises. After this the same with y_max, followed by x_minand y_min. Then it continued its printing with a shifted y_axis.

(Without Arc-welder no layer shift)

My printer runs the lastest bugfix-2.0.x firmware (Time of writing)

FormerLurker commented 3 years ago

My suspicion at this point is that this is a firmware problem, but I'll keep looking for issues within the gcode. If accurate gcode causes a layer shift, I'm not sure what I can do about it. If the gcode is somehow wrong, then it can be fixed on my end, else this is a downstream (firmware) problem.

@Hextler, one of the issues with these 'bugfix' branches that they do not have a specific version number. I'm not sure what patches have been applied (is it a bugfix of 2.0.0, 2.0.1, 2.0.2... etc). Marlin 2.0.6 and 2.0.7 both have substantial changes to the arc interpolation algorithm. Did you compile this yourself, or does Creality just not add a semantic version to their releases?

Also, I'm not sure why exactly I keep seeing this problem on creality printers, and not on others (yet...). Perhaps it's just a matter of numbers?

Hextler commented 3 years ago

I compiled it myself, so in fact it's newer than 2.0.7

There are three exceptations:

If its a firmware issue within the interpolation algorithm, it should happen at least at other 32bit boards.

If its a creality issue i would suggest it happens on other machines with tmc 2208/9 stepper drivers too.

If its hardware specific thean theres nothing anyone could do about it, except switch the board.

*Also to note, its not happening with every gcode file. But when it occours its likely to occour again. (But in different layers). Another Hardware suggestion: Is there a chance that running g2_g3 commands could produce more load on the speppers and result in overheating, or an inconsistent state?

FormerLurker commented 3 years ago

@Hextler,

If its hardware specific thean theres nothing anyone could do about it, except switch the board.

Since all of the arc moves get translated into very short linear moves by the firmware, I would expect if this were a hardware issue , we would be seeing similar issues with standard gcode. If it is a firmware problem, then it could be related to the various marlin definitions in the configuration files, or it could be an issue with one of the algorithms.

There is a second possibility that actually combines many of these things. Arc moves have less overhead than standard linear gcodes, in that the parsing overhead is greatly reduced (it takes a LOT of time to perform string manipulation), so it's possible that the timing differences when running G0/G1 vs G2/G3 (less time between commands) is actually the culprit. In my testing, even when running gcode directly from SD, I've noticed that G2/G3 code tends to be executed faster than G0/G1 code. On some models it is quite substantial. The only way to account for this is that the printer must not be hitting it's peak acceleration or speed when running G0/G1, but it gets closer when using G2/G3. Thoughts?

Hextler commented 3 years ago

You might be right, in fact linear moves are normally slowed down in your slicing software using F parameters. G2 and G3 doesnt have one, so they are excecuted as fast as possible.

Currently my max feedrate as well as accelaration are at 500 mm/s (defaults). I could test lowering acceletarion to lets say 300

FormerLurker commented 3 years ago

@Hextler, F paramaters DO work for G2/G3. My hunch is that your acceleration is right on the cusp of causing the steppers to skip Maybe try lowering it to 450 first, and see if that takes care of this? If it does, this will provide some deep insight into how G2/G3 affects 3d printing in general.

Hextler commented 3 years ago

Ok i will try this, and report success or failure in the following days :)

rizwansarwar commented 3 years ago

Ok, so I've not found any issues with the GCode, so at this point I'm suspecting either some serial communication issue or a firmware issue. The serial issue might actually be firmware too because I'm working on a few other similar problems that only seem to happen in creality firmware. What printer are you using?

Finally, if you are willing to try the devel version, you can install it with the plugin manager (OctoPrint Settings->Plugin Manager->Get More->From Url...) with this link: https://github.com/FormerLurker/ArcWelderPlugin/archive/a0f41e1ae75443805278b643ed9162bfcae17394.zip

Though this is not quite ready for a production release, in many ways this is the safest version of ArcWelder to use. It has many extra safeguards to prevent issues. In fact, I think that after a year of development I finally feel like the core algorithm is finally complete. It's really the plugin part that needs additional work.

I'm interested in what the new firmware checker says about your firmware mostly. If you install it send me a snapshot of the firmware checker (it's on the tab), and I would also appreciate any feedback you have regarding the new version.

Thanks!

Thank for looking into it, I will try the devel version too, I just need to setup another instance of Octoprint (oh yes I forgot to mention my prints were via octoprint). I checked Klipper logs after your comment and it seems there were few buffer overflows during the print, it is possible that the problem is caused by Octoprint (even though Arc welder is designed to help with Octoprint). So I have 2 things to try,

FormerLurker commented 3 years ago

@rizwansarwar, Also check your max acceleration and feedrate. It's these 'skips' are incredibly difficult to debug. I've had these issues myself several times (I push the boundaries of speed on my printer). Sometimes it was mechanical (bad bearing, bed rubbing against frame, tangled filament on printer bed that I caught due in a timelapse). Once it was firmware (solved 100% via an update). Another time it was EEPROM data I had forgotten about. The last time it was due to a typo in my slicer.

The most irritating fact is this definitely could be caused by Octolapse if there is an error setting the feedrate. Most good gcode viewers will shade based on print speed, so that is not too difficult to diagnose.

Hextler commented 3 years ago

Just to be clear: In my observed case wasn't any skipped steps. Instead the tool hammered against the mechanical bounding box of my printer, until it catched itself. But after the layer shifted.

@rizwansarwar Did you watched your printer, while there was the layer shift, or just noticed it later?

FormerLurker commented 3 years ago

OHHHHH... wow. Ok. @Hextler, this is 100% caused by lack of G2/G3 support. Not sure how I missed that... I reread your OP and that is now quite obvious to me. it's It's been a long day :)

Hextler commented 3 years ago

But why did it only happen once in one print, had Cura's Gyroid infill , which has very very much arcs and it happened on different layers after retry the same file.. (Also once but not seen directly)

Other Arc Welder processed files works just great

FormerLurker commented 3 years ago

@Hextler, lol, I'm getting you confused with OP now, lol. Ok, so forget what I said. I'll wait for your results turning your speed down. If I keep getting confused I may separate these issues :)

rizwansarwar commented 3 years ago

@FormerLurker So I have done extensive testing since last time, tried your beta too. I have not seen a single layer shift since then. Printed at faster speeds too which did not cause any issues. It is really weird because I was able to reproduce this multiple times when the layer shifts were happening. I can only put it down to Octoprint and Raspberry Pi being the culprit. From my perspective this can be closed and Arcwelder is not at fault.

FormerLurker commented 3 years ago

thanks for following back up @rizwansarwar It can be very difficult to figure out what is causing any problem since there are so many systems interacting. I'm very glad things seem to be working as expected now!