-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nozzle moves to corner of bed mid print and then resumes #30
Comments
Can you send the before and after gcode? Also, are you using Octolapse? It can cause these movements. |
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 |
For further information this is happening with everything. Not just benchy. Here's another example. |
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. |
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 |
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:
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! |
I am on 2.0.6 on an Ender 3 Pro. I will try printing from the SD Card and report back. Thanks |
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. Edit: I've disabled all plugins except ArcWelder and I'm trying again. |
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. |
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. 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. |
Log is attached. I killed the print immediately after the issue occurred. Looks like it was probably this:
Or I know nothing, just a guess haha. |
Lol! You may be right. I will take a look tomorrow, thanks for the log! |
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. |
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. |
Weird. I made the firmware on both printers so entirely possible that I did something weird, but god knows what. |
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. |
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! |
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. |
Ok, thanks for trying. I will try to install the firmware you have to test. Might take a while :( |
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. 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.
Still at layer 253 there is a message saying it encountered an unknown command. It seems that the start got truncated. Instead of receiving
What if in the previous example it got truncated in such a way that all the 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.
For the sake of completeness, here is the gcode files: |
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: 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. |
I had to click it a few times to make it work. I could see I only had this issue once but can be reproduced if I delete Log file plugin_arc_welder.log 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. |
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 ;) |
Sure, I can test new versions as needed. |
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. |
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.
Again, this won't fix the issue, just mitigate it. The settings that had the most impact are 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. |
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): 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. |
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. |
@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 |
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.
|
@gxwilson69 Please try changing Issue #175 has more details about this. |
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. |
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
<#30 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE5J4UCLFOLSED36HOA4TL3TVJZ6JANCNFSM4PLAJ4MQ>
.
|
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. |
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
<#30 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE5J4UE6LYUASM7UJUKIHHDTVO4VFANCNFSM4PLAJ4MQ>
.
|
@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. |
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. |
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 |
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. |
Fyi all, I will probably add a setting to intelligently reduce precision to fit a given gcode length based on this thread. |
@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 |
@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:
BLOCK_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! |
Octoprint adds 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.
By using the example as a starting point we can say a worst case would be 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.
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 Marlin sets its own serial buffer size with |
@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. |
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.
The text was updated successfully, but these errors were encountered: