Printing registration bug

skutch

I downloaded and used the latest version of Repetier-Host v 1.0.6, with Slic3r, and today went to print 2 copies of a pad in one go, with no skirt and 3mm brim; the first brim printed out fine, but when it went to print the 2nd, it went to the X home position of the bed, printed a line from the 2nd part, then went to finish printing the brim of the 2nd part, only it was shifted about +3mm X further from where it was supposed to be. I tried separating the parts more and moving them around the bed, but it does the same thing. When I let it run with the shift, it went back to the 1st part for the infill and it was then shifted the same amount. What's up? Using an Airwolf 3D 5.5. All previous versions have never had this problem. I just tried starting 2 smaller pads, about a 2" x 3" total area on the print bed, and they are processing fine, but the larger pads, about a 4" x 6" area messed up, even when I separated the pads into 2 distinct areas, not connected in any way. I did a fresh slice with Slic3r in RH and in Slic3r I downloaded from their website, no difference

Repetier

The host only sends the commands, so I guess the problem lies in the gcode you send. So first you should check how the gcode preview looks. From your description it could be, that you hit endstop when it "home x" which then shifts coordinates when your object is outside printable area.

skutch

The weird part is that it is an L shaped pad; when I print them both in the same orientation, the problem occurs, when I print 1 normal and the other rotated 180 degrees, it works fine. I even tried downloading Slic3r directly from their website; it displays everything fine, it just tweaks when it goes to print. I'm haven't messed with gcode before, but I'm thinking the problem lies in these negative coordinates Slic3r generated:
G1 X18.810 Y56.385 F9000.000
G1 X-0.308 Y55.498 F9000.000
G1 X-2.360 Y91.996 F9000.000
G1 X-0.859 Y110.495 F9000.000
G1 X57.716 Y138.226 F9000.000
G1 E1.20000 F1800.000
G1 X149.172 Y138.226 E1.84470 F3600.000

So why does Repetier Host show the printout as normal, it should throw out an error warning or something when coordinates outside the print area are used, shouldn't it? I'll post this to the Slic3r forum, as it appears to be an error there.

skutch

So after some more checks, I found that when I place 2 individual pads with the same orientation, the problem occurs, but when I save the pads to a new STL and just load the single STL and slice, it doesn't create the issue. I also tried loading the 2 individual pads into the actual Slic3r program I downloaded from the manufacturer's website, and it sliced it correctly with the same settings, so it looks like an implementation bug in the Repetier Host version of Slic3r.
:-<

Repetier

Look here

G1 X-2.360 Y91.996 F9000.000

negative x coordinates! Can your printer handle that or is x=0 your endstop? If not, you will get a misalign here.

Currently host only tests if objects or inside print area. So evenif this is the case, a skirt or raft may stick outside print area, It's not really an error, just a model that is too big or misplaced.

skutch

The thing is, there should not be any negative coordinates generated from the slice, the parts are in the center of the print bed with about 3 squares all around them, so the built in version of Slic3r is generating illegal negatives, but only for the start line on the 2nd pad, weird. A definite bug in the program, but no way to report it to the powers that be.
:-<

Repetier

These are informations I did not have. I assumed 2 objects were so big it hot near the border.

Could it be in the slic3r start gcode or repetier start gcode? I mean some component must have generated these lines and that is the error. The host it self does not generate any gcode like this, it only includes the slic3r results. And the bundled slic3r is the original from their website.

skutch

From my understanding, RH launches slic3r when you click the Slice button, I don't know if the version that ships with RH is the unmodified program or if it was tweaked for RH, but something in the process of RH using it, generated the problem. The startup code in the gcode seems okay, it prints the outer brim then part 1 brim (when both parts are close to each other; otherwise just the full part 1 brim) then it errors when going to print the part 2 brim; yet if I save the two parts into 1 stl file and just load that file, it works fine...so again, not sure the root cause, but it is either going to be a bug in how RH sends the data to slic3r, or something in the version of slic3r installed with RH.

Repetier

I just tried to create the same error with no success. I get a brim around both seperate or over all if close together, but nothing outside the printable area. So I'm not sure what you do different to me.

Host exports all objects as amf for slic3r, so each importe dobject stays it's own object so it is in deed a different to a stl composed of both.

Can you make a screenshot of the error slice so I can imagine it better.

skutch

Best I can do without wasting more material to start printing the error. If I could upload a file, I'd send you the STL of the pad, then you could load it in, do a 1 part copy with auto placement and slice it to see the error.

Repetier

I assume previe also shows this?

You can send files to my mail repetierdev gmail com

skutch

The preview shows everything perfectly normal, you only see the problem when it goes to print the brim on the second pad. Thanks, just sent the files over, check them out and let me know.