ArcWelderPlugin
ArcWelderPlugin copied to clipboard
FormerLurker
Indirectly causes a layer shift
About 8 hours into a 16 hour print today, I had an issue where I heard the X or Y axis belt slip, the print head was all the way in the front left corner of the build area. Then the print head made two complete pases around the entire perimeter of the print bed (all four courners, in a big square).... then resumed printing. Of course, since it slammed into that corner causing the belts to slip, we now had a layer shift. The same print NOT using Arc Welder did not exhibit this behavior.
Hello there, what is your firmware version amd printer model?
On Sun, Apr 11, 2021, 12:29 PM mytechguyri @.***> wrote:
About 8 hours into a 16 hour print today, I had an issue where I heard the X or Y axis belt slip, the print head was all the way in the front left corner of the build area. Then the print head made two complete pases around the entire perimeter of the print bed (all four courners, in a big square).... then resumed printing. Of course, since it slammed into that corner causing the belts to slip, we now had a layer shift. The same print NOT using Arc Welder did not exhibit this behavior.
— 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/189, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE5J4UCI4237HRF5ESXLNGDTIHE55ANCNFSM42X2RTYA .
Ender 5 pro, using Marlin TH3D unified firmware v2 on 4.2.7 Creality main board
oh, this was using the Cura Arc Welder plugin, not the one within Octoprint
I have the exact same setup. Need to recompile from the marlin bugfix branch. I would send you mine, but I have a 4.2.2 board, so it wouldn't help, and its a good skill to practice anyway.
Have to enable RX_BUFFER_SIZE and set it to something >256
On Sun, Apr 11, 2021 at 2:48 PM mytechguyri @.***> wrote:
oh, this was using the Cura Arc Welder plugin, not the one within Octoprint
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/FormerLurker/ArcWelderPlugin/issues/189#issuecomment-817354279, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE5J4UFFPP6B4IALFMYDIC3TIHVF7ANCNFSM42X2RTYA .
i just had this same issue happen to me almost 2 hour into a print(layer 23 at 0.2~mm layers), i heard the nozzle crash into the corner limits, then recover but layer shifted. Using the arc welder cura plugin and printing from octoprint. my RX_BUFFER_SIZE is commented out, using 250kbaud speed
Marlin 2.0.x rhapsody bugfix, cura 4.8 with plugin updated
@Eliminateur,
my RX_BUFFER_SIZE is commented out, using 250kbaud speed
Maybe un-comment RX_BUFFER_SIZE and increase as @seantapscott has done?
I have modified it but yet to try, sadly it borked a 9+hr print 6hrs into the print(and i could not recover it the 2nd time as it pushed the object outside the bed) and i'm not super keen on going through that again
Well, I can tell you that I have an Ender 5 Pro with a v4.2.2 board, and this change worked wonders for me, as I was also experiencing the same things with connection timeouts and sudden moves to the front of the printer. It was actually due to buffer overrun and truncation with the longer commands that involve arcs. The RX_BUFFER_SIZE was originally suggested by someone following (or actually developing/maintaining) the Marlin Firmware changes closely.
On Sun, Apr 18, 2021 at 10:08 PM Eliminateur @.***> wrote:
I have modified it but yet to try, sadly it borked a 9+hr print 6hrs into the print(and i could not recover it the 2nd time as it pushed the object outside the bed) and i'm not super keen on going through that again
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FormerLurker/ArcWelderPlugin/issues/189#issuecomment-822119366, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE5J4UG43DCT4VYG2XUDJE3TJOGA7ANCNFSM42X2RTYA .
ok i've done more tests, this time a very simple rectangle(a 100x100 empty rectangle, with 3mm thickness and 3mm wall test with arc welder with RX_BUFFER_SIZE set to 1024(in fact the model has no XY curves whatsoever, the gcode shows a scant number of G2/G3commands), sent from octoprint, a the start of layer 13 i heard a thunk and the head bonked to max X and i had to abort. Model has 14 layers.
Sliced with arc welder plugin on cura 4.9, G90 checkbox set.
TX_BUFFER_SIZE 32 RX_BUFFER_SIZE 1024 MAX_CMD_SIZE 96 BUFFSIZE 4
Just tested from SD card finished succesfuly, and i daresay even faster than on octoprint
What hypothesis was your experiment trying to test?
On Sat, Apr 24, 2021, 5:17 PM Eliminateur @.***> wrote:
ok i've done more tests, this time a very simple rectangle(a 100x100 empty rectangle, with 3mm thickness and 3mm wall test with arc welder with RX_BUFFER_SIZE set to 1024(in fact the model has no XY curves whatsoever, the gcode shows a scant number of G2/G3commands), sent from octoprint, a the start of layer 13 i heard a thunk and the head bonked to max X and i had to abort. Model has 14 layers.
Sliced with arc welder plugin on cura 4.9, G90 checkbox set.
TX_BUFFER_SIZE 32 RX_BUFFER_SIZE 1024 MAX_CMD_SIZE 96 BUFFSIZE 4
Just tested from SD card finished succesfuly, and i daresay even faster than on octoprint
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FormerLurker/ArcWelderPlugin/issues/189#issuecomment-826154712, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE5J4UHDCS3IKLIDBBHF6VDTKMYNPANCNFSM42X2RTYA .
Octoprint adds a line number, which makes the commands longer than when printing from SD. There is another setting for max gcode length, might want to see what that is set to.
What hypothesis was your experiment trying to test? … On Sat, Apr 24, 2021, 5:17 PM Eliminateur @.***> wrote: ok i've done more tests, this time a very simple rectangle(a 100x100 empty rectangle, with 3mm thickness and 3mm wall test with arc welder with RX_BUFFER_SIZE set to 1024(in fact the model has no XY curves whatsoever, the gcode shows a scant number of G2/G3commands), sent from octoprint, a the start of layer 13 i heard a thunk and the head bonked to max X and i had to abort. Model has 14 layers. Sliced with arc welder plugin on cura 4.9, G90 checkbox set. TX_BUFFER_SIZE 32 RX_BUFFER_SIZE 1024 MAX_CMD_SIZE 96 BUFFSIZE 4 Just tested from SD card finished succesfuly, and i daresay even faster than on octoprint — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#189 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE5J4UHDCS3IKLIDBBHF6VDTKMYNPANCNFSM42X2RTYA .
i was trying to test if changing the RX buffer as the other people said would fix the crashing behavior, it did not.
Octoprint adds a line number, which makes the commands longer than when printing from SD. There is another setting for max gcode length, might want to see what that is set to.
they're set as default: #define MAX_CMD_SIZE 96 #define BUFSIZE 4
the longest command on the gcode generated is 61 bytes
My BUFSIZE is 16, though i am not knowledgeable enough to determine if that has an effect on this.
Running Marlin Bugfix? I also have SERIAL_OVERRUN_PROTECTION enabled.
On Sat, Apr 24, 2021, 6:45 PM Eliminateur @.***> wrote:
Octoprint adds a line number, which makes the commands longer than when printing from SD. There is another setting for max gcode length, might want to see what that is set to.
they're set as default: #define MAX_CMD_SIZE 96 #define BUFSIZE 4
the longest command on the gcode generated is 61 bytes
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FormerLurker/ArcWelderPlugin/issues/189#issuecomment-826162936, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE5J4UFMPHXMKKIO46436KDTKNCXLANCNFSM42X2RTYA .
Whoops. I see now you already sent the buffsize, sry. Not been all there today. Fyi, there will be 10-12 more bytes added by octoprint (line number + checksum), but it sounds like 96 bytes should do it.
It is so strange that this issue didn't happen during the SD print. Indicates a firmware issue, or maybe an octoprint issue.
My thoughts also that this is related to firmware and Octoprint, and outside the direct scope of ArcWelder, perhaps, although the firmware misconfiguration does strongly affects ArcWelder's efficacy as a tool.
On Sat, Apr 24, 2021 at 7:27 PM FormerLurker @.***> wrote:
Whoops. I see now you already sent the buffsize, sry. Not been all there today. Fyi, there will be 10-12 more bytes added by octoprint (line number
- checksum), but it sounds like 96 bytes should do it.
It is so strange that this issue didn't happen during the SD print. Indicates a firmware issue, or maybe an octoprint issue.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FormerLurker/ArcWelderPlugin/issues/189#issuecomment-826166488, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE5J4UHW5Q2LCWMLH7EYDSTTKNHVBANCNFSM42X2RTYA .
@Eliminateur Please enable the serial logging at Settings -> Serial Connection -> Serial logging -> Log communication to serial.log, restart OctoPrint then print and wait for the issue. Attach the log here so I can try to figure out what may be happening.
Also, do you know the exact commit you are using to compile your firmware? If it is earlier than February 27th it won't have the required patch and RX_BUFFER_SIZE won't have effect at all.
@Eliminateur Please enable the serial logging at Settings -> Serial Connection -> Serial logging -> Log communication to serial.log, restart OctoPrint then print and wait for the issue. Attach the log here so I can try to figure out what may be happening.
Also, do you know the exact commit you are using to compile your firmware? If it is earlier than February 27th it won't have the required patch and
RX_BUFFER_SIZEwon't have effect at all.
i'm using rhapsody's fork, dated STRING_DISTRIBUTION_DATE "2021-03-25"
i'll enable the debug next time i try and will upload the result
Ok an update, as i've been fiddling with lots of stuff inbetween: Raised the BUFSIZE to 16 from 8, and also started using meatpack compression. So far after 11 prints of the same calibration part that was failing, i got NO issues. but since i didn't do any of those things separately, i couldn't pinpoint on if either of those fixed it. What i could tell you is that add in the readme a suggestion to raise the BUFSIZE to 16 to use arc welder, to be on the safe side
@Eliminateur, thank you for trying that. If you ever have time to run some tests with and without meatpack enabled, that would be extremely helpful. I'm unsure how RX_BUFFER_SIZE could be affecting things, but I think Meatpacker may. I'd love to figure out exactly what's going on here, but I don't have enough breadcrumbs to follow ATM.
Will keep this open for a while longer in case you run into other issues. If I close it out, and you have problems, feel free to reopen it!
Well, keep in mind that we also don't know if Eliminateur is actually using RX_BUFFER_SIZE correctly. He said he wasn't actually using the bugfix branch, but some Marlin branch from a developer named Rhapsody.
On Mon, May 3, 2021 at 2:48 PM FormerLurker @.***> wrote:
@Eliminateur https://github.com/Eliminateur, thank you for trying that. If you ever have time to run some tests with and without meatpack enabled, that would be extremely helpful. I'm unsure how RX_BUFFER_SIZE could be affecting things, but I think Meatpacker may. I'd love to figure out exactly what's going on here, but I don't have enough breadcrumbs to follow ATM.
Will keep this open for a while longer in case you run into other issues. If I close it out, and you have problems, feel free to reopen it!
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FormerLurker/ArcWelderPlugin/issues/189#issuecomment-831458673, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE5J4UBF2VJHNZGZ4VMNIXTTL3VY5ANCNFSM42X2RTYA .
Well, keep in mind that we also don't know if Eliminateur is actually using RX_BUFFER_SIZE correctly. He said he wasn't actually using the bugfix branch, but some Marlin branch from a developer named Rhapsody. … On Mon, May 3, 2021 at 2:48 PM FormerLurker @.***> wrote: @Eliminateur https://github.com/Eliminateur, thank you for trying that. If you ever have time to run some tests with and without meatpack enabled, that would be extremely helpful. I'm unsure how RX_BUFFER_SIZE could be affecting things, but I think Meatpacker may. I'd love to figure out exactly what's going on here, but I don't have enough breadcrumbs to follow ATM. Will keep this open for a while longer in case you run into other issues. If I close it out, and you have problems, feel free to reopen it! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#189 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE5J4UBF2VJHNZGZ4VMNIXTTL3VY5ANCNFSM42X2RTYA .
Rhapsody fork tracks the latest bugfix every few weeks, the build i'm using is the 26/4 bugfix. The only thing that fork has is special configs for Tronxy printers, other than it's the bone stock bugfix with some delays, so it is taking the RX_BUFFER_SIZE correctly.
what i changed is not only RX_BUFFER_SIZE but also BUFSIZE.
I'll try to backtrack all the changes but not gonan be able to do it ATM (specially since it's a reflash everytime those values change)
No worries, I just wasn't familiar with Rhapsody. Feel free to ignore the ignorant one that is me.
On Mon, May 3, 2021 at 3:57 PM Eliminateur @.***> wrote:
Well, keep in mind that we also don't know if Eliminateur is actually using RX_BUFFER_SIZE correctly. He said he wasn't actually using the bugfix branch, but some Marlin branch from a developer named Rhapsody. … <#m_-9165740106355903326_> On Mon, May 3, 2021 at 2:48 PM FormerLurker @.***> wrote: @Eliminateur https://github.com/Eliminateur https://github.com/Eliminateur, thank you for trying that. If you ever have time to run some tests with and without meatpack enabled, that would be extremely helpful. I'm unsure how RX_BUFFER_SIZE could be affecting things, but I think Meatpacker may. I'd love to figure out exactly what's going on here, but I don't have enough breadcrumbs to follow ATM. Will keep this open for a while longer in case you run into other issues. If I close it out, and you have problems, feel free to reopen it! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#189 (comment) https://github.com/FormerLurker/ArcWelderPlugin/issues/189#issuecomment-831458673>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE5J4UBF2VJHNZGZ4VMNIXTTL3VY5ANCNFSM42X2RTYA .
Rhapsody fork tracks the latest bugfix every few weeks, the build i'm using is the 26/4 bugfix. The only thing that fork has is special configs for Tronxy printers, other than it's the bone stock bugfix with some delays, so it is taking the RX_BUFFER_SIZE correctly.
what i changed is not only RX_BUFFER_SIZE but also BUFSIZE.
I'll try to backtrack all the changes but not gonan be able to do it ATM (specially since it's a reflash everytime those values change)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FormerLurker/ArcWelderPlugin/issues/189#issuecomment-831496598, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE5J4UGQRS2TL6J55CVLN4TTL353TANCNFSM42X2RTYA .
Just an update on this problem ... I changed rx buffer in my firmware to 512. I'm running the latest THD3D unified Marlin firmware 2 on Creality 4.2.7 main board. I'm still seeing this behavior where it hits hard against the endstop, causing the belt to skip, then moving around to all 4 corners before resuming the print, but now with shifted layers... So I really don't think rx buffer is the cause of this problem.... Although I suppose I could increase it to 1024 and enable xon/xoff if you still think buffer overruns are the cause.
I'm also going to try arcwelding with the Cura slicer and printing from the SD card directly, which should rule out a communication/buffer issue from the pi entirely. I'll update as my testing progresses.
On Sun, Apr 18, 2021, 10:05 PM FormerLurker @.***> wrote:
@Eliminateur https://github.com/Eliminateur,
my RX_BUFFER_SIZE is commented out, using 250kbaud speed
Maybe un-comment RX_BUFFER_SIZE and increase as @seantapscott https://github.com/seantapscott has done?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/FormerLurker/ArcWelderPlugin/issues/189#issuecomment-822118603, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALD3AQXBSIBRUWPG7ZL2PPTTJOFXHANCNFSM42X2RTYA .
So, I implemented a work around that may solve this problem. If you check out the latest devel branch and install it, there is ~~not~~ now a setting to limit the maximum gcode length. I'm not sure exactly what it should be set to, but something like 50 should work. You should be able to see how many gcodes were rejected for being too long, and adjust it so that it is as low as possible without rejecting too many arcs. Be sure to read the help (question mark icon next to this setting) and note the other things that contribute to long arc commands: xyz and e precision (number of decimal points) and the 'allow 3d arcs' setting.
FYI, if you head over to my ArcWelderLib repo and look through the issues, there are huge threads discussing this issue. It CAN be solved by changing firmware settings, but everything has to be configured just so, and I don't really understand all the settings. When printing through OctoPrint the gcodes get longer than they look since a line number and checksum is added to every command, so this can be difficult to track down. If the gcode file has, say, 1,000,000 lines, the line number will take up a lot of characters.
Let me know if you are willing to try this, if you need help with the install, and how testing goes. There are other features in that release (encode travel moves, cura Arachne engine support, and a few other things), so be sure to look through the settings and read as much help as you can. I'd appreciate any feedback!
I was wrong about similar issues being in ArcWelderLib. Here is an issue that includes several fixes and workarounds, and also a link to a recent build of marlin that fixes this bug.
@mytechguyri The suggestions are for the official Marlin firmware. The TH3D fork may not have the latest bug fixes and changing the buffer size won't work at all. If possible please try with the official firmware.
Thanks I'll give these a try... Fwiw, my latest test I removed Octoprint and the communication with the Pi from the equation... Sliced in Cura with the Cura arc welder plugin... Saved and printed directly from SD card.... And still got the layer shift. So definitely not a rx buffer issue I would say. Must be some other firmware issue.
On Tue, Jul 20, 2021, 1:20 PM FormerLurker @.***> wrote:
So, I implemented a work around that may solve this problem. If you check out the latest devel branch and install it, there is not a setting to limit the maximum gcode length. I'm not sure exactly what it should be set to, but something like 50 should work. You should be able to see how many gcodes were rejected for being too long, and adjust it so that it is as low as possible without rejecting too many arcs. Be sure to read the help (question mark icon next to this setting) and note the other things that contribute to long arc commands: xyz and e precision (number of decimal points) and the 'allow 3d arcs' setting.
FYI, if you head over to my ArcWelderLib repo and look through the issues, there are huge threads discussing this issue. It CAN be solved by changing firmware settings, but everything has to be configured just so, and I don't really understand all the settings. When printing through OctoPrint the gcodes get longer than they look since a line number and checksum is added to every command, so this can be difficult to track down. If the gcode file has, say, 1,000,000 lines, the line number will take up a lot of characters.
Let me know if you are willing to try this, if you need help with the install, and how testing goes. There are other features in that release (encode travel moves, cura Arachne engine support, and a few other things), so be sure to look through the settings and read as much help as you can. I'd appreciate any feedback!
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/FormerLurker/ArcWelderPlugin/issues/189#issuecomment-883561837, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALD3AQUHZQLD4S7HISZO4J3TYWV5FANCNFSM42X2RTYA .
Sorry, and the original gcode too. I would like to take a closer look.
It is the RX_RECEIVE_BUFFER if you're still using TH3D firmware.
On Wed, Jul 21, 2021 at 9:04 PM FormerLurker @.***> wrote:
Sorry, and the original gcode too. I would like to take a closer look.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FormerLurker/ArcWelderPlugin/issues/189#issuecomment-884593338, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE5J4UGRK5DEO37SQ5QS3CDTY5VA3ANCNFSM42X2RTYA .
I'm really out of my element on this issue, 😂. Can't keep all these different firmwares straight.
Well, I wouldn't think anyone would expect you to, but I would hope the users might take some responsibility and read over the guides and follow the instructions explicitly given.
On Wed, Jul 21, 2021 at 11:56 PM FormerLurker @.***> wrote:
I'm really out of my element on this issue, 😂. Can't keep all these different firmwares straight.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FormerLurker/ArcWelderPlugin/issues/189#issuecomment-884640421, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE5J4UDFY7WYIXIX7VN4HTDTY6JF3ANCNFSM42X2RTYA .