Print starts on back right edge

[CoDanny]

Since I updated GPX to 2.3 version from this repo, all my print are now starting on the back right edge of the printer instead of the center like before. This is a FlashForge Creator Pro

Has anything changed regarding print start position? When we slice with cura or slic3r we set print_center to 0,0 although I have also tried calculating the center coordinate and setting that (e.g. 50,50 on a 100x100 bed)

We're not passing the bed size on the gpx ini file (it hasn't been needed with previous versions). Could this be the cause?

[markwal]

It's probably the start gcode is behaving differently in the new version. I changed the way it handles unknown coordinates, though I haven't seen your behavior before. Do you have a gcode file (say of a calibration cube) that worked in the previous version, but doesn't now?

GPX itself doesn't decide where the coordinates are, it just generates the step equivalent coordinates and sends those along. The firmware decides where to go based on the coordinate system defined by the homing in the start gcode. So the x3g sequence may be confusing the firmware due to some bug I introduced, but I'll need a repro to track it down.

[CoDanny]

This one. It's generated with slic3r. 25mm_cube-Creator-Pro-PLA-normal.gcode.zip

Note though that our code prepends the following start.gcode to all x3g files: start.gcode.zip

We execute them like this: gpx -c -gi -N t (provide start.gcode via stdin and pipe stdout to a file) gpx -c -rpi -N h (provide slic3r/cura gcode file via stdin and append stdout to previous file)

[markwal]

Does your code also do a substitution on {half_size_x} and {half_size_y} in start.gcode before sending it through?

Without that, I'd expect it to print off the table to the back right because the gcode is defining the home position as (0, 0, 0). So a correct translation to x3g would be that. I'm not sure why an older GPX wouldn't also.

You know, for machines that have properly set home offsets in EEPROM you could move that G92 to before the M132 and change it to: G92 X0 Y0 Z0 A0 B0. As you have it now, it recalls the offsets and then stomps on them with the following G92. Which is the way MakerBot Desktop does it, inexplicably. But I think the following makes better use of the EEPROM to let people make adjustments to their machine and still print the same x3g files:

G92 X0 Y0 Z0 A0 B0 M132 X Y Z

Note, I left the A B off of the M132 because just defining them as 0 lets GPX and the firmware be on the same page about their position and an EEPROM offset for the extruder position seems less useful. X, Y, Z don't have this problem because the next absolute move will sync GPX and the firmware. That'd be true of the extruders also except that from this point on, often the gcode just uses E, so you run the risk of the other extruder getting confused since some x3g commands take all 5 coords (ie G92) even if they aren't specified. And some GPX always generates even though it technically doesn't have to, just the way WHPThomas wrote it.

[CoDanny]

Yes, {half_size_x} is replaced by the proper values on x3g creation time.

[markwal]

Could you capture one of those that is reproducing the problem and post that?

[CoDanny]

do you want the generated x3g?

[markwal]

No, the exact gcode file that is sent to gpx.

change the command to something like 'tee start.gcode | gpx -c -gi -N t' or as you're writing to stdout, just write the commands also to a side file. Either way, I need to see what gpx is seeing.

[CoDanny]

I think the two files that I uploaded before are exactly what you need. We use them as source to gpx and append the s3g output of the second to the s3g output of first to generate the x3g file. As far as GCODE goes those two files are it.

I did forget to replace {half_size_x} and {half_size_y} in start.gcode but those values would be 145.5 and 72.5 in the example that I tried (Creator Pro)

[markwal]

OK, the problem is since the files are separated and GPX sees that G92 E0 in the second file without knowing any of the other coordinates, it defines the current position as (0, 0, 0, 0, 0) and you're still at home. I don't know why the old version didn't do that also yet.

[markwal]

I get the exact same output from gpx 2.2.1. I don't think it can work like this because x3g's 140 requires all 5 coordinates and the second gpx invocation doesn't know anything about the first. The output from GPX 2.2.1 looks like this which should also result in the print being off the bed to the back right.

cat 25mmyadayada.gcode | gpx -rpi -N h > foo221.x3g
s3g-decompiler.py foo221.x3g > bar221.txt
head -11 bar221.txt

Command count: (Command ID) Command description
1: (136) Tool 0: (13) Toggle blower fan 0
2: (136) Tool 0: (3) Set target temperature to 225 C
3: (136) Tool 0: (3) Set target temperature to 225 C
4: (135) Wait until Tool 0 is ready, 100 ms between polls, 65535 s timeout
5: (140) Define position as (0, 0, 0, 0, 0)
6: (139) Absolute move to (0, 0, 120, 0, 0) with DDA 37
7: (155) Move to (0, 0, 120, 193, 0), DDA rate 658701,  relative, distance 0.000000 mm, feedrate*64 -21952 steps/s
8: Command not recognized 6
9: (140) Define position as (0, 0, 120, 0, 0)
10: (155) Move to (8489, 5003, 120, 0, 0), DDA rate 9954, A, B relative, distance 110.856850 mm, feedrate*64 8320 steps/s

That's going to try and move into the end stops 110mm.

[markwal]

You probably need to send that G92 from start.gcode in through the second gpx instance or just combine them into one.

There's nothing in start.gcode that is affected by the r vs. g flag. That only effects:

implicit toolchanges M106/M107 M109

[CoDanny]

Thanks. I'll try and combine it in one call to gpx to see if that fixes the problem.

Currently when using Cura instead of Slic3r, it works. I think it's because Cura doesn't add the G92 E0

[markwal]

Since I don't think I can fix GPX for this (since it is an implicit problem with the x3g 140 command), I think closing this issue is correct. If there is something GPX should be doing differently, feel free to re-open.