Layer Shifting Phenomenon

So I posted about this in troubleshooting a while ago and THOUGHT I had it figured out, but it turns out that I don't! My custom Rostock Max V2 has been giving me the strangest layer shift problem, and I haven't been able to isolate the cause.

The layers shift, but the print does not start printing at an angle as one would think (The layer shift and the following layers match up to how a Cartesian printer should respond, not a delta). I originally thought the bed was being pushed along the X/Y plane by the print head dragging across the top of the prints in certain areas (the bed is floating on FSRs, so only three spots to keep the bed from moving). I countered this by driving guide pins from the bed into the base to allow vertical motion of the bed for leveling but keep it from moving in the X/Y plane. Last night, I started a print with this setup and still had a layer shift. Since I'm still suspicious that it's the head dragging (although it still doesn't make sense since the prints are not coming out in a manner consistent with a delta after a belt skip or something), I've reduced extrusion rate on the slicer profile and have enabled z-hop/retraction for all travel motions. I plan to test this out tonight and record the print to see if the cause can be caught on video, if it does indeed happen again.

I'm curious if anyone else has ever experienced this and, if so, what your remedy was? G-CODE all checks out, bed is level, the first X layers print fine, but still I get a non-delta-standard layer shift out of the blue.

Thanks for any help you all can provide!

Rostock Max V2
DuetWifi Main Board - with PanelDue
E3D V6
Carbon fiber arms/machined aluminum ball joints
aluminum heat spreader/borosilicate glass/PEI sheet - heated bed sandwich
FSR bed leveling
Bondtech extruder

Update: Ran a test print with the updated G-CODE with z-hop active for all travel and slightly less extrusion rate. Same problem/effect: layer shifted (about 1/2" or more) and the print continued from the shift as normal. Unfortunately I did not catch it on video either...

Update #2: Ran another test print with the same G-CODE as in update one above, but at 85% speed. For whatever reason, it printed fine... at least for a while (will explain in a second). In all my recent G-CODE since I've been having this problem, I set up a process to slow the print down 66% of my normal print speed (3750 mm/min) at the problem areas. So the problem areas were actually printing at 1250 mm/min and still skipping but printing at 1050 mm/min and fine. For a delta printer capable of normally 7000 mm/min for normal print speed, I feel it's a shame that this is occurring. My belts are tight, motors are running at 1.2 amps max to increase torque and maintaining 12V, etc... So I don't know why I would have to slow down so much to prevent this shift from happening.

Which brings me to the "at least for a while" part. Since it printed past the problem areas without any issue, I decided to let it continue overnight. Probably two hours after I had walked away from it and went to bed, it just... stopped. No warnings in the console on the PanelDue (and if there were, they probably got pushed out by the constant stream of network warnings I received saying that no known network available to connect to), nothing out of the ordinary on the print screen (purple highlighting for heating faults, etc...), nothing. It's as if the printer had the emergency reset button hit mid print, but nobody was around/up to do that and there was no reason to do that as the print had been moving forward without any problems this time.

I'm getting to the point that I think there may be a fault somewhere with my DuetWifi. The constant wifi signal loss (NEVER had a problem with that up until recent. Then out of the blue it started having disconnect errors, saying no networks available, etc...), this random layer shifting (use to never happen. Never an issue until recently), and now a random system reset equivalent to an emergency stop... I feel like it all points to the board. I'm going to do a little more research on this new finding, but I believe I may be putting in a claim for a repair or replacement of my DuetWifi.

EDIT: I know if someone sees this, they may ask for me to run an M122 diagnostic check. I have not done that yet, but if this happens again then I will definitely run it to see what is going on. I've also seen suggestions to reinstall the firmware, which I may try next as well.

Edited 1 time(s). Last edit at 05/10/2019 07:18AM by MobiusOne.

The frequent wifi disconnections could be a sign that your router has hopped to a different channel, or that there is new interference on the channel it has been using. Telling your router to use a fixed wifi channel, different from the current one, may resolve that. I recently resolved a similar issue at 3D Meetup Sweden by changing the channel from 6 to 2.

Any automatic reset of RRF will save a trace of the reset reason and processor state. This information is included in the M122 report. However, as any deliberate software reset will overwrite some of it, you should get and save the M122 report as soon as possible.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

DC42,

Thanks for the feedback on the wifi disconnecting. I'll give that a shot when I get home from work. If for some reason the wifi continues to disconnect even after a channel switch, is there anything I should look at next?

As for the report, I'll do my best to grab it if this reset occurs randomly again. This is the first time I've ever had the system just stop/reset in the middle of a print like this. Other times it's been a heater fault so it was obvious what occurred.

For the random layer shifts, we discussed this briefly in my previous troubleshooting post but a root cause was never determined. The shifts started happening after firmware updates, so I'm thinking maybe something with firmware? The only thing I can think of immediately that would cause the shift is the head just dead stops for a split second and then resumes, but the G-CODE behind the motion never stops, making the head continue printing based off of a shifted coordinate system even though the software thinks it's right where it needs to be. I modified my print bed to prevent the bed from shifting so that isn't sliding out from underneath or anything, and when we last discussed, we were sure it wasn't a jumped tooth on the pulley because then it would start printing at an angle. This layer shift also only seems to happen with parts that have cylindrical holes through the part that are oriented along the X/Y plane. I've printed items with no cylindrical holes or the holes are aligned in the Z plane and they have had no issue.

Try to print without using wifi completely. Wifi can be extremely unreliable when your neighbours buy wifi routers as well, crank their power up and start e.g. streaming a movie. Get three or more such neighbours and not even channel switching helps you. Your wifi is a toast from that time on

If it would be skipped steps or a skipped belt then you would get both XY and Z error at the location where a skip happened. This does not have any influence on the part being tilted after an error. It will continue to be completely straight(*) after the error. It is just that everything will be shifted in all cartesian coordinates (X,Y,Z) and by a different amount depending on XY position.

(*) the walls which were perpendicular to bed will continue to be perpendicular

The only thing how you could get only XY error is:

• incorrect G-code (slicer error)
• firmware misbehaves and overwrites cartesian XY displacement which is normally modified by e.g. G10 command (this is firmware error)

hercek,

Thanks for the input! Using wifi right now is the only real, easy means I have of moving files around quickly and in the present case for running some of my prints. My Duet board is tucked away so pulling the microSD card out every time I have to update G-CODE would be a big hassle! I also can't access some of the files I upload to the Duet microSD using the PanelDue: some sub-directories don't show up on the interface, so I have to use the web control interface to select them. Not sure why or how, but it could be associated with firmware.

For the belt skip, you're assuming that all three belts would skip in order for this case to happen, correct? I'm still trying to catch the occurrence on camera so I can diagnose it, but It's definitely not shifting in the Z plane when this happens, only the X/Y plane. I've run the G-CODE through different simulators online and each one returned the same, expected result. I currently use Simplify3D for all my slicing as it has the widest array of tools available but I would not be against slicing in Cura or Slic3r to at least test if the slicer software is causing an issue. Otherwise, I'm leaning towards firmware misbehaving, especially since these incidents began to occur after a firmware update. If push comes to shove, I may roll back firmware to what I had before everything started happening and see if I can restart from there/see if it continues to happen.

BTW, bad network connectivity should not result in XY head position error either. Well, at least not directly. It should at most result in paused prints ... which may result to blobs of plastic extruded on one place which can cause head crash into those blobs when print is resumed later which can result in skipped steps which will have influence ob XY and also Z shift.

It is common in software, that one error causes a lot of subsequent errors which are not obviously related. Hypothetical example: data unavailable over wifi causes reading past buffer end, which causes writing random garbage into variables storing offsets from G10 command. I'm not saying this is what is happening to you. It is just one of many options.

Tiny Z shifts may not be easy to recognize. Tiny XY shifts are easy to recognize.

It is not needed that all the bets skip together. One is enough to get also Z-error. If one belt skips then the Z-error will be biggest near the tower on which the belt skipped.

Good information!

To clarify, my G-CODE is uploaded to a local MicroSD card on the machine and then run from the machine. I only monitor or start the print remotely. There shouldn't be any issue with the machine running the G-CODE at that point since it's not waiting for a buffer refill from the network.

I ended up doing a firmware wipe and reinstall to 1.19 and work my way up from there (if I need to honestly). So far, things are much better in terms of interface. I am still having some intermittent network connectivity issues, but the Duet isn't throwing the lost network errors and constantly disconnecting like it was. It's holding the connection steady. I'm in the process of swapping wifi channels to see if that helps at all. ALL of my G-CODE files are now showing up on the PanelDue interface, which they did not before. That is a huge plus for me. I updated the PanelDue firmware as well but the firmware changes didn't cover anything that I was having previous issues with, so I am ruling that out as the problem solver. I believe the rollback has taken care of all of the original problems, but I'll find out more tomorrow when I go to do a print again.

The only issue I have now is that when I open up my G-CODE file from the Duet Web Server, I get repeating directories... and A LOT of them. I only have six top-level directories for G-CODE on my SD card, but those six are repeated DOZENS of times. Sometimes it will clear up after a quick interface refresh but sometimes they stay there. I'll rule it a true new problem after I've done the WiFi channel swap over though.

Quote
MobiusOne
...
The only issue I have now is that when I open up my G-CODE file from the Duet Web Server, I get repeating directories... and A LOT of them. I only have six top-level directories for G-CODE on my SD card, but those six are repeated DOZENS of times. Sometimes it will clear up after a quick interface refresh but sometimes they stay there. I'll rule it a true new problem after I've done the WiFi channel swap over though.

I suspect that the versions of Duet Web Control and main firmware versions you are using are mismatched. You should use Duet Web Control 1.22.6 or 2.0.0-RC6, and main firmware 2.02 or 2.03RC1 (in any combination). Look on the Settings/General page of Duet Web Control to check what versions you are running.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Hey all, just wanted to give a quick update! Both good and bad.

The good: Layer shift went away when I printed the parts separately and not as a group. Don't know exactly why, but I can't really complain as I was able to move forward with my project. I do have to be weary of it returning though, so I will keep an eye on when it next occurs. Hopefully I can find a trend as to the occurrences. I also don't have the connectivity issues anymore. I did update the DWC and firmware a little more (haven't made the jump back to the current firmware just yet) and all my files continue to be there, so I may continue to move up. I'm thinking I may have gotten a corrupt install on my firmware. Not sure but it's not bothering me now. I also installed a WiFi repeater to help with connectivity. I wasn't having connectivity issues for a while, but when it started happening, I couldn't figure out why and it was impacting my G-CODE upload something fierce! The repeater has pretty much nullified the issue. My guess though is that my gateway is starting to go. I'll have to keep an eye on it!

The bad: I was having jamming issues, but I noticed my retraction was probably way too high for a ~550-600mm bowden tube.I was running 5.5mm retraction rate at 3000mm/min speed. I have since dropped retraction to 2.5mm and increased speed to 3600mm/min and I don't appear to be seeing jamming YET, but I am now getting some aggressive stringing. Not thick, thankfully, so I'm close to the proper retraction, but I'm nervous about jamming again by going up to say 3 or 3.5. Only time will tell. If it's any help too, I'm running my filament at 185C during main printing (the ZYLTech White PLA I'm using prints really well at that temp).I figured a lower temp might help a little against jamming since not as much heat is going to creep up during retractions. I'm hoping to get the stringing sorted out but for now, that is a smaller matter that shouldn't be too impacting!

So I've ordered a few things, one of which might help. I believe my problem lies within my heat brake. I've ordered a titanium smooth bore replacement along with a copper heater block. I've read a lot of success stories that say the titanium heat brake helped greatly with printing PLA since it helped to reduce thermal transfer up to the heat sink. I'm going to take a look at a couple other things tonight while I wait for my parts to arrive, but I believe I've narrowed it down to the problem area!

5 mm retract length for a long bowden printer is about right
Your retraction speed seems low at 50 mm/s.
I use 300 mm/s. My extruder acceleration is 7000 mm/s². But this all depends on what kind of extruder you have.

I actually just picked up a Bondtech BMG about two weeks ago or so. I might have to fine tune it a little but at 5mm retraction, there was no stringing, but the jamming was pretty consistent on multiple retractions. I was running 9000mm/min retraction speed but my extruder didn't sound too happy about that (super grindy) haha I am building a new mount for it though, hoping that helps with the grind sound. Most of my work will be done today so I'll post updates as they come!

Thank you both for your input though, I've been struggling to deal with these issues and I'm hopeful it's coming to a close soon.

So I'm about 4 hours into a print and a layer shift happened. Bed didn't shift, it's too small for it to have been a jumped tooth, and I can't imagine it being an idler pulley slipping down the adjustment slot based on frequency and repeatability. Ugh... I just want it to stop this!

Well... I feel a fool! I am pretty sure I've isolated the jamming issue. I forgot that when I built the hot end, I ended up having to move the hot end cooling fan higher than it should be (due to the mounts design, found online). Well, it leaves the three lowest fins out of the cooling so I'm getting EXCESSIVE heat creep! I'm redesigning the mount to accommodate the added length requirement for fitting the fan properly, so that should take care of the jamming.

Still need to figure out this layer shifting though! Argh!

If your parts are narrow like this:

Then you may have just a simple skipped step on one or more towers. The XY shift is so small that you may not notice that there is also Z shift.Try to break those parts. Are they breaking much more easily at the location of the the shift? If yes then you probably have also Z shift which you re not noticing i.e. it can be a skipped step.

Quote
hercek
If your parts are narrow like this:

Then you may have just a simple skipped step on one or more towers. The XY shift is so small that you may not notice that there is also Z shift.Try to break those parts. Are they breaking much more easily at the location of the the shift? If yes then you probably have also Z shift which you re not noticing i.e. it can be a skipped step.

That was actually the first thing I tried. Layer adhesion is definitely unchanged, couldn't break it. That's actually one of the nicer shifts I've seen as well. Some of mine have shifted as much as 1/2 inch in the X/Y plane without a shift in the Z!

So my test print with readjusted cooling on the hot-end still jammed on retractions... I'm wondering if maybe the new heat brake (titanium) is the new problem? Idk.. I'm starting to get incredibly frustrated by this and it's definitely a de-motivator.

Back to it today. Set up about a dozen tests to vary some aspects of printing. Also replaced titanium heatbrake with original due to a design difference in the brake. And added Canola oil to lube interior. So we'll see how it goes!

Edited 2 time(s). Last edit at 05/19/2019 01:15PM by MobiusOne.

So far, replacing the heat brake has helped. Also replaced the nozzle and Canola oiled that. Haven't had any jams yet, been incredibly smooth. Re-printing what I printed before (that had the layer shift) but slightly rotated, hoping that will counter the shift...

So I ran a 5 hour print last night and didn't have any issues. Not even the layer shift. I don't want to mark this thread as closed/fixed just yet because it may happen again, but for now I will share my tips that helped me finally succeed.

- Make sure the hot end fan is actually cooling the whole hot end (this was a design flaw in the effector assembly that I overlooked. Modified the design to properly house the fan).
- Added Canola Oil into the hot end. Helps with lubrication, especially with PLA. Can either add a drop directly into the hot end or soak a sponge and run the filament through that (I opted for the former as I didn't have a sponge for the filament).
- Rotated the model in slicer program by 5 degrees. Not sure why this helped with the layer shift issue, but it did. This may help in some cases, but I don't expect it to help in all. We'll have to see what the next prints have in store.
- Used the original heat brake that came with the hot end. The titanium replacement caused feed issues and I think part of that is due to the entrance to the brake having a tapered edge vs. the stock E3D heat brake which is flat (better mating with the PTFE tube). That tapered edge likely could have been allowing some swollen filament to fill up between the PTFE and the brake. Also think the titanium heat brake conducted heat much less than the original, meaning the brake was often cooler than it should have been.That's my guess at least!
- Set my retraction to 5.5mm (bowden tube of about 550-600mm), retraction speed to 6000mm/min, and print temps back up to 200/205C.

Happy thus far, and hoping the trend continues. I will post updates if anything happens though.