Unexpected lines printed on UM3 that are not visible in cura

[kevinastock 0]

I've been having a problem with lines being printed where I do not expect them. I'm printing on a UM3 with Cura 5.2.1. In the attached pictures, the highlighed black lines should not appear inside the outlines. When I look at the path in Cura's preview mode, I do not see the extruder move along these paths at all, either printing or traveling.

 

I've experimented with some settings in cura but without success, although changing settings does move around where errors like this happen in the build. I tested rerunning the same gcode file once and the errors appeared in the same places, so it seems to be deterministic for a specific gcode file. Unfortunately I don't have access to another UM3 to determine if it's deterministic across printers.

 

Any ideas what could be causing this problem? The closest similar report I've seen online is this one: 

 

[gr5 2,234]

Please post your project file that corresponds to one of these photos - hopefully the simplest one where it's obvious in the photo what the problem is.  In cura do menu "file" "save project as" and post that file here.  It will contain your models and your machine settings, profile, and settings.

[kevinastock 0]

Unfortunately I don't have a minimal reproduction at this time; all of these pictures are from one large object which I've attached.

 

The last image is the first layer of the print at the 'Q' on the second row (when viewed from the bottom) as printed by extruder one. The outline is drawn very early in layer one when I slice it, and the unexpected line happens during the print of that outline.

UM3_clock.3mf

[gr5 2,234]

 Okay, first of all, this is strange.

 

But let's calrify things please.  This must be the second layer, right?  Because on the first layer, in the project file you sent me, it prints the black first, then the clear.  But on the second layer it prints the clear first and then the black so it's possible on the second layer for black to be above the clear.

 

Can you confirm that it is the second layer for the Q and the V?

 

Also this is a very very cool clock.  I love it.

 

Okay well this is very bizarre.  The movements are quit exacting and aren't related to non-printing moves.  They appear to be on normal printing moves.  So no retraction is occuring.  The travel moves don't explain the pattern seen.  On any layer.

 

So I think it is truly moving to the wrong position.  Which implies a bit is getting flipped.

 

There are two computers in your UM3.  The linux computer which is a powerful computer - similar to the ones in an old iphone.  Running an advanced operating system with the ability to hook up an hdmi monitor and keyboard and mouse and has full blown operating system.

 

The second computer is a wimpy arduino style computer.  It doesn't have an operating system but has just a single app on it called Marlin.  Marlin is open source (as is the linux stuff).  It controls the servos.  It has the motion controller software.  These two computers communicate through I believe a USB cable under your printer.  Basically in serial mode.  The linux computer sends the gcode as ascii code (which is a strange way to do it but whatever).  So the gcodes might look like this:

 

G1 X100.731 Y70.555 E1.333

 

I've seen this issue on UM2 printers but not UM3.  The ascii in say a 5 ends with bits "0101".  Literally a binary 5.  If you flip the first bit it is "1101" which is an illegal character and will interpret the remaining digits as zeros.  If you flip the second you get 1, third bit you get 7, and last bit you get 4.

 

So what happens is you tend to get errors of exactly 1,2 or 4 mm or 10,20,40mm or 0.1 0.2 0.4mm.  Or 100,20,40,10mm.

 

Those look like errors of around 2 or 4mm on the Q and V and about about 20 or 40mm on the N.  You can probably measure them.  The errors are only in one axis for the Q and N but the V is extra bizarre and I can only explain it if 2 of the numbers had a bad bit.

 

There may be checksums which just means the errors are much more frequent then we thought and we are seeing the 1 in 100 to pass the checkum test however I don't think checksum testing is enabled.

 

So what is the fix?  I'd disconnect and reconnect any cables that conned the 2 computers together.  I'm pretty sure it's a usb cable.  You could take some pictures.  I forget if the UM3 has the olimex board (the linux computer) mounted to the main board or if they are literally separate boards connected by a single cable.  The cable should be cleaned if possible (the connector/connectors).  Maybe replaced.  Maybe rerouted away from other cables that might contribute noise although it's a shielded cable so that shouldn't be an issue.

 

I have to tell you I've never seen this on a UM3.  You are probably having other errors you don't notice.  LIke the extruder.  I bet the extruder occasionally retracts 10, 20,40, or 100mm and then reinserts the filament.  It would be an obvious pause in printing for maybe 5 seconds while it does this if you are nearby and have a musical ear it will be obvious.  I've heard it on my UM2 before I fixed it.

 

On occasion the error is great enough for the print head to be asked to go out of bounds.  Instead of moving X to say 100.243 it might get flipped to 400.243 which is out of bounds and is an error.  Also many errors go unnoticed as they are in the tenths or hundredths of a mm.

 

Or the extruder might extrude an extra 10mm and then retract 10mm and it will skip on the extrude and will then underextrude for a minute until things balance out.

 

The Z axis is unlikely to ever have an issue as only about 1 in 5000 gcodes move the Z axis.

 

 

[gr5 2,234]

So I just looked at pictures of the bottom of a UM3 and I think it's that ribbon cable.  That's unfortunate.  It's not shielded.  So keep it away from other cables if possible.  Maybe re-route it on the other side of the Z stepper?  And slide it in and out a few times on both ends to get a good connection.  With all the vibration in a printer, those connections can slip a little and/or degrade (oxidize?).  Route away from other cables as you can get something called "cross talk".  Look it up.  Happens when you have a long run of wire very close and parallel to another.  You get both inductive and capacitive coupling.  "long run" might be 2 inches.  Maybe take pictures of where the red line goes on each end before disconnecting.

[kevinastock 0]

Quote

This must be the second layer, right?  Because on the first layer, in the project file you sent me, it prints the black first, then the clear.  But on the second layer it prints the clear first and then the black so it's possible on the second layer for black to be above the clear.

This is the first layer, taken when it has only printed black. It's being printed on an adhesion sheet which was used for another build previously, hence looking like there's something under the layer.

 

Quote

Also this is a very very cool clock.  I love it.

Thank you! I've been working on it on and off for an embarrassingly long time, it's great to see it finally coming together.

 

10 hours ago, gr5 said:

Which implies a bit is getting flipped.

I suspected that as well, so I printed the same gcode file a second time and the errors showed up in the same spots on the first layer. I guess it's possible something about the printer is causing the interference which could make it deterministic. But I will make sure there are no other electronics are near it and take the other steps you suggested with the cables.

 

I've included the gcode for just the black part of the first layer that I printed. Looking at it in NC Viewer it looks like it's not a gcode issue. However I see that I had arcwelder enabled; I should have turned that off before submitting a bug. I'll try slicing with that disabled and see if it makes a difference, but given those lines already don't show up in the gcode it seems unlikely to make a difference.

 

It may be a few days until I can make the suggested changes and run some tests, but I'll let you know what comes of it. Thank you very much for all the help!

 

layer1.gcode

[gr5 2,234]

Oh!  It's very likely arcwelder.  I don't know that the UM3 (nor the S3 - don't get them confused) supports arcs.

 

Yeah - I see lots of G2 and G3 commands in your gcode.  I doubt I had those in mine.

[kevinastock 0]

Sorry for the slow response, I finally had a chance to do another print and found that disabling arcwelder solved the problem. Thank you! It's good to know the um3 doesn't support arcs; I hadn't realized arcwelder could produce instructions some machines wouldn't understand.