Printing very skewed

Hi, maybe someone can share some insight.

My printer is printing up, but also back, and to the right. As seen in the picture. I’ve tried gcode from others that print normal. It’s not the gcode. The axis are set up correctly. Prints the same from the controller, off the usb stick, off wifi, and also with luban just connected to the machine.

This machine is just a mess. This problem, along with the skipping/bump in practically all the axis. The controller disconnecting all the time. The print head diving into the print surface and possibly bending the table. I figure if I can get it printing correctly, then I can start working on the other issues. But this product is NOT ready for prime time.

Dont take me wrong, but please check your assembly, that behavior is not normal.

Send some pictures of your machine from front, left or right.

The people here will help.

1 Like

I’m genuinely amazed that actually printed, stayed adhered to the bed, and didn’t spaghetti.

Post gcode in addition.

All the axis seem to work properly using jog mode on the controller… This gcode printing fine on someone else’s snapmaker… sooo

One would assume that if they react correctly that way, it would react correctly if it were printing?Calicat_check.gcode (506.5 KB)

What the heck is going on with this one LOL

Very fascinating

gcode preview looks ok

Can you photograph the build plate mounting to the linear modules?

Its like the Z and Y are mixing up in the Gcode somehow or something

Have you by chance done any firmware updates?

If the modules are dragging as you say it seems likely steps are being skipped and its shifting that way… but it seemed to move OK from the button interface

Maybe some more video with the print head closer to the table?

If assembly checks out there must be something inherently wrong with the controller or something… probably will require to step in.

That’s a new one. Maybe it’s been taken over by the spirit of Picasso?

Usually when it does something like that it’s an assembly error and x y or z are plugged wrong but obviously moving properly manually.

Try loading the 1.9 firmware. (that’s the most stable) Some people have had luck fixing various problems by reinstalling.

Otherwise I tend to think there’s a problem with the brain.



Is the controller aware of the shift? I’d be interested in the output of M114 when the print ends, or at least confirmation the machine is commanding the drift, via the Luban machine coordinates console as it prints.

Can replace all extrusion commands in the gcode file with 0 extrusion, and run the file just so it goes through the motion, like so. Also no temp either:
Calicat_check_no_E.gcode (427.6 KB)

If you run that, does it still go up and back? You could override the speed from the console. M220 S200 to run twice as fast.

1 Like

It still moves back and to the side. It’s not done yet. But it may run off the sheet. Who knows.

Well, that at least rules out skipped steps due to the nozzle colliding with something in the print.

I can’t recall if there’s a positional readout on the touchscreen that shows you the current X/Y/Z - does the machine think it’s moving? Do you have a laptop or something you could hook up and connect via USB and issue an M114 and get the position readout? It won’t stop the print or anything, you can issue commands over USB at any time.

It thinks that its moving…

I don’t know if any of these commands tell you anything. I will try again later and do the M114 and get the coordinates. I’m almost willing to bet that it’s a computer issue. But, that along with all the other little things. gr. I really want to send this thing back. luban.doc (57.5 KB)

Are you sending the file from Luban, or are you running the file from the touchscreen? Does it behave differently if you do?

If you want to send it back, good luck - I don’t think I’ve heard of anyone doing that successfully.

This doesn’t seem like a major issue to me - I mean obviously it needs to be fixed, but I feel like it’ll be a simple fix.

And yea, that’s just temperature reports, there’s nothing in that log.

I think you live near very hevy magnetic fields :rofl:


It’s not just the 3d printing. The table bump it has. Etc. The screen malfunctions like a mofo. It doesn’t keep calibration, even though I calibrated the print head. I get the same results from the touch screen, USB, Luban through USB, and wifi.

I bought mine through imakr. So if I don’t get a refund, I’ll simply do a charge back.

Hmmm. Well, I didn’t know these were being sold anything other than direct from China, so if that’s an option I’d say exercise it.

Otherwise we’re gonna exorcise your machine.

Sounds proper broken.

Anyway, this seems like 2 step skipping linear modules…
May you try printing slower @Ev0lv3 and see if it happenes again?

Can you triple check the cables for the axis motors are plugged into the correct corresponding holes? Check both the mounting box and splitter boxes to ensure they match up and then tripple check the splitter box itself it going to the correct axis motor

Your “X” is the verticle bar that goes across, “Y” are the two flat on the frame “Z” are the two towers standing up

Did you watch the video posted? I don’t see how the cables could be wrong.

I agree the machine is appropriately wired, this is a controller issue or an issue with multiple modules being broken and skipping/dragging (or both)

It was my first inclination until you see him manually jogging the unit properly.

Its incredibly interesting the form this problem has taken and I am so curious about the end result.

Unless - maybe he has one z and one y swapped in the splitter modules? i dont think i saw him jog both directions…

or maybe there is some random spam going through different ports that the linear module is picking up and he is on the wrong port altogether?

Trying to wrap my head around the logistics of the longboi kitty.

You’d hear massive grinding during the jogging if one motor was dragging the other along forcefully.

Yea, I haven’t ever seen anything that would provide a mechanism for this to happen. Completely bizzare.

Actually on second thought, I have had a smaller version of this happen with backlash compensation. Maybe a large backlash compensation would explain this? Although nothing in the gcode or information presented above gives any suggestion that backlash compensation M425 commands were being issued before running the job, and it resets on power cycle.

hmm even with an m500?