First (non-demo) print put a hole in the bed

#1
I'm having a pretty negative out of the box experience with this machine, but I'm willing to give it another try if someone can tell me what went wrong here.

So far, I unboxed it, followed all of the setup instructions, run the test file, and run the test print from the SD card. The Z offset was way too low out of the box and it wasn't even able to extrude filament (the extruder motor just skipped steps). Isn't this thing calibrated at the factory? Anyway, I "babystepped" it up a bit and it produced a print that was so badly stuck to the acrylic bed that there a still bits on there after re-sanding it. Anyway, no major loss there because I bought the heated bed and didn't plan to use the acrylic beyond the first test print.

I then installed the heated bed (really, no software control of the temperature, unplug it to turn it off?) and decided it was important to dial in the perfect Z offset before doing anything else. So I spent some quality time with a business card under the nozzle, stepping it by 0.1 (as best I could given that one detent of the knob moves several steps) until it was just tight, setting a new Z offset, saving settings, eventually realizing you have to power cycle and auto home to get the new setting to take effect. But now it was good, I printed the test file from the card and it worked.

Now on to using it for real. I'm partial to Cura, so I went to the gcreate.com downloads site, got the current version of the SD card software, downloaded and install the obsolete Cura 2.5 as instructed, put the printer and printhead settings in place, imported the three profiles provided, loaded a tiny sample STL from Thingiverse, plugged in the USB cable, and clicked the button. It heated to 200C, probed the bed, and then drove the extruder right down into my brand new BuildTak surface, melting a hole in it as I quickly hit the power switch.

What happened? I used the correct profiles and recommended settings. I had my Z-offset configured spot on. This machine is for a maker space. With our other printers, I have some confidence that as long as people use the installed profiles and default settings, they won't destroy themselves.

I'm not sure if this forum will let me include a file. If so, I'll attach the G-code that Cura generated.
 
#2
Here's how it starts, anyway:

Code:
;FLAVOR:RepRap
;TIME:241
;Filament used: 0.147501m
;Layer height: 0.2
;Generated with Cura_SteamEngine 2.5.0
M104 S200
M109 S200
G21 ;metric values
G90 ;absolute positioning
M82 ;set extruder to absolute mode
M107 ;start with the fan off
G28 X0 Y0 ;move X/Y to min endstops
G28 ;Home X/Y/Z
G29 ; Bed level
G91 ;relative positioning
G90 ;absolute positioning
G1 Z25.0 F9000 ;raise nozzle 25mm
G92 E0 ;zero the extruded length again
G1 F9000
;Put printing message on LCD screen
M117 Printing...
;LAYER_COUNT:20
;LAYER:0
M107
M204 S5000
G0 F3600 X172.901 Y195.15 Z0.3
M204 S600
;TYPE:SKIRT
G1 F1800 X173.576 Y194.596 E0.05446
G1 X180.341 Y190.018 E0.56386
G1 X180.872 Y189.707 E0.60224
 
#4
I've gone through this thing line by line and the behavior makes no sense. For some reason I'm able to print the demo file "gMax First Print_170911.gcode" on the SD card, but if I send the same G-code commands one at a time over the USB port, it crashes into the bed on one of the first moves after probing or it hangs and doesn't move at all.

Unfortunately, it looks like this won't be suited for our space. I've got 3 days left in the 10-day return policy and no more time to experiment, so I'm going to have to pack it up tomorrow. :-(
 
#5
I have a theory. I sent the G-code one line at a time, and this is where it rammed into the bed:

G1 Z25.0 F9000 ;raise nozzle 25mm

Before doing this, I noticed that right after the probe sequence completes, the display is reading nonsense for the Z value:



Also, an M114 at that point produces this response:

Code:
X:384.00 Y:398.00 Z:0.00 E:0.00 Count X:30720 Y:31840 Z:-2147483648
Z is not at 0, it's 13mm or so above the bed when it finishes probing. So I think something is corrupting internal state. The big question is why am I able to run a test print off the SD card? My hypothesis is that the problem only occurs over the USB connection. And I suspect a low number of people use this printer, making it possible that few or none actually use the USB connection (or it's even more specific to the model of computer plugged into it).

Is anyone successfully using a gMax 1.5 XT+ with Marlin 1.1.1 and a USB connection plugged into a MacBook Pro?

I have limited free time today and used it all to write this post, so I can't go do the obvious experiment to test my hypothesis.
 

GORDON.LAPLANTE

Administrator
Staff member
#6
We finally found a solution. If you want to print from USB please remove the SD card.

It turns out if you have the SD card inserted while printing from USB, the Z offset is cleared out. We tried this on several machines and from Cura 2.7, Cura 3.03, Cura 3.04 and Simplify3D 4.0

Even simpler if you connect to the printer from a host, we used Pronterface, and run the code below, the x/y/z coordinates are output after the bed probe. Make sure to run M114 after the bed probe has complete:

Code:
G28
G29
M114
Our results without an SD card inserted but from USB:
Code:
SENDING:M114
X:384.00 Y:398.00 Z:14.99 E:0.00 Count X:30720 Y:31840 Z:5528
The exact same setup only this time we inserted the SD card:

Code:
SENDING:M114
X:384.00 Y:398.00 Z:0.00 E:0.00 Count X:30720 Y:31840 Z:-2147483648
Notice the Z position is cleared out in the second one with the SD card inserted. This causes the head to dive into the bed after bed probing. The weird thing is you can print from SD with the USB plugged in with no issue you just can't do it the other way around. We apologize for any inconvenience and will notify the Marlin dev team of this bug.
 
#7
Thank you! That would also explain why this isn't more widely known. It was just a coincidence that I left the SD card after doing my initial setup and trying my first print with Cura. Long-term, that card slot is going to be empty and have tape over it, so it's unlikely I would have seen this problem later on.

It's a weird bug, but removing the SD card is a simple workaround I can easily live with.