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.
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 support@snapmaker.com to step in.
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.
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.
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)
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.
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
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.
