So other people and I have been trying to help someone pretty much all day. The issue is extreme layer shifting on the x-axis and it’s ALWAYS to the left. We’ve had them do everything from tramming with 123 blocks (knowing that wasn’t the exact cause but just in case) to swapping rails to making sure the platform is correctly installed, even as far as doing a complete disassembly (this happened before I joined it) and reassembly. Nothing has changed the outcome at all. Seeing as they swapped rails I highly doubt it is a rail problem. At this point I think the firmware either got corrupted or the gcode is getting corrupted as it gets sent to the machine. Nobody so far has had them verify what firmware is installed until I said something. It’s a brand new machine that is only a week old so it’s likely 1.8. Luban version being used is 3.14. Calibration has been done multiple times to the point that a new user now knows it as a second language. Currently waiting to hear back about firmware version and how they connect to the machine and/or send gcode.
Looks like an intermittent X motor to me
That was the initial thought but as the x rail was swapped out with a z rail it still happens the exact same way.
Could you please post a photo which can show us the model on the heated bed?
Please update the firmware to V1.10.1 and try to print again.
You can upload the G-code file here so that we can try it at our end.
Cheers
Edwin
Ok so update on his issue. The firmware is refusing to update, it froze during update. It sat there for a few hours updating firmware, finally he shut it off and back on which we know is a bad idea but it was the only choice as it was stuck. So I’m more convinced that somehow his firmware got corrupted. For now it’s starting up normally as if nothing happened. Later today he will try a test print and see if the problem is still there.
Update: @Snapmaker-Edwin firmware has been updated, rails have been swapped out multiple times in multiple combinations and it’s happening the same way, I’ve forwarded the request of a photo of the failure still on the print bed as well as to capture a video of it while printing. It’s unknown as to what might be causing this. I’ll do everything I can to help troubleshoot but at this point we really only have one thing left to try before I’ll need to direct him straight to support. As far as gcode it’s happening on every file no matter what, and always to the left even though rails have been swapped around, which tells me firmware or gcode generation in Luban itself. Also having him do a complete uninstall and reinstall of Luban as I had strange stuff happen requiring that step before. I’ll also have him join here so you can talk to him directly as well.
You mentioned that the shift always in the same direction. That is quite strange. If the model always shifted in one direction, this issue has nothing to do with the linear module but the G code file or something else.
- Share a photo of the model when it is on the heated bed.
- Upload the G code file and the STL file here.
Thank you in advance.
Edwin
I can’t attach the gcode it’s too large but here are the pictures and stl
Radiant_Blossom.zip (2.1 MB)
The base always prints fine except for on the left “foot”. It goes wrong when it gets to anything above that. I agree there’s something wrong with the stl, it is manifold but there are intersections. I’m going to send him a file to print that I know works. When it does fail it fails in the exact same way, always shifting left. A situation of the print head nudging the print will not explain this as he has never had a print detach from the bed and it keeps printing left from the last shifted point instead of where its supposed to be. as it gets higher is when there are more problems, but again rails have all been swapped around but no change. If it were a bad rail we would be seeing the error somewhere else as the rails have been switched. Is it possible something is wrong with the controller? I’m honestly scratching my head on this one.
Edit: Also, it’s not a consistent failure except for the lamp, on short prints it is 80% success 20% fail, on taller prints 20% success 80% fail. Symptoms are mimicking missed steps, but on multiple rails? I think you’ll agree that while anything is possible, that would be extremely unlikely.
Update: I’m having him do a print of the calibration cube that we all know is a good stl. He recorded a video, I trimmed it to around the part where it happens so the file size isn’t too large, tell me what you think.
Update: Cube #1 printed just fine. Having him do more cubes. This is where we TRY to get it to fail and prove a pattern of inconsistency, the same gcode has been used on prints where some succeed and others fail. When failure occurs the head consistently continues where the last layer shift failed and just continues to go left.
@Edwin after all of this troubleshooting I think it may be the controller. it fails at random, but almost always on larger taller prints. With small items it rarely fails and with how many times the X-Axis rail has been swapped out, the likely hood of it being a rail problem is extremely low. I have generated G-Codes myself, inspecting models in multiple design software, the only one with errors being the lamp which is the one pictured here, but after repairing the model myself it still failed, and with the other larger models that DON’T have any errors still failing the same way it couldn’t be the cause. The benchy prints come out fine, but they are small. I found a simple pillar type model that is tall and no errors in the model and it failed. It seems anything that goes above a certain size will almost surely fail. I have directed him to contact support for final troubleshooting with Snapmaker. He also updated the firmware to 1.10.1 as you had requested and still problems. I am also suspecting the controller because it froze when trying to update the firmware the first time.
Thank you so much for your updates.
I just downloaded the STL file and generated the G-code with Snapmaker Luban in the Fast print mode.
I do not think the problem relates to the controller, it will not fail at random because we have not received any similar cases.
Because the model is hollowed, and the petals always failed. I think the issue may be related to the hollowed structure.
As you can print the cube without any shift, the X-axis is intact. Maybe the support structure, retraction and Z-hop need to be enabled in Snapmaker Luban before you generate the G-code.
The machine is working and I will update the progress here.
Edwin
Latest update: We got the cube to fail. Scaled it up in Luban to 150% and it failed. Retraction, retraction at layer change, and z-hop we’re all enabled. It seems when an object is over a certain size it has a tendency to fail. Now I am suspicious of the head itself. As retractions and z-hop were all enabled it failed but it wasn’t as extreme. I’m thinking maybe the shroud or other part of the housing might be snagging the prints somehow without causing the print to detach from the bed. Skin touch test on all components while printing to see if anything was hot, everything was normal.
Ok. Firmware is ruled out. We’ve gone through multiple firmwares as far back as 1.8. Swapped rails multiple times. Hardware is ruled out. Has anyone else that has this problem in the other thread used any slicer besides Luban?
Theory: @Edwin that other post is having the same issue. This is far fetched but is it possible that those of us with older firmware that have not updated yet including updating each head individually because of the rotary module release, is it possible it could be causing conflicts between the latest versions of Luban (starting with 3.14) and older firmwares?
I do not think your case is the same as the one of Mr. @ErwinDM . According to the threads, @ErwinDM has not tried to swap the linear modules, and the technical support is contacting him.
As for your case, it is quite strange that the calibration cube shifted. I am still printing the Radiant_Blossom and so far so good.
Could you please tell me in which direction did the cube shifted? Did it shifted alongside the X, Y or Z axes?
I will update the progress of the Radiant_Blossom later.
Edwin
It shifted on X, again to the left
Did you use enclosure with the enclosure?
He does not have an enclosure.
I did swap no solution
@ErwinDM my theory is those that are running older firmware that have not updated each module individually as required with the newest firmware versions (1.12 and up) because of the rotary module release, are having conflicts between Luban and the older firmware. It’s far fetched but the one I’m helping to troubleshoot has tried all firmware from 1.10.1 all the way down to 1.8. Now the reason for this theory is that the modules were required to be updated so they could recognize that the rotary module is now part of the firmware, I think it was so the heads wouldn’t run into the rotary module, for example the cnc when running boundary. I started to wonder if it inadvertently caused conflicts between the newest versions of Luban (3.14 and up) and firmwares with the non updated heads. Even I think it’s far fetched but I have seen really strange stuff happen in software.
What firmware are you running?