Cartesian Printer: X and Y length (and location?) reversed

[howsTricks]

I tried queuing up a print and adjusted the printer settings to X length: 105 and Y length: 200. Moved the print to the front edge of the tray but when I tried to print the head moved all the way to the far right (X positive) and slammed against the side. My printer does not have an X maximum end stop (just at 0 for homing). Thinking that the X/Y axis are not orientated correctly as it shouldn't be moving towards that edge?

As a side note, is this the appropriate spot for issues as this seems to be more of a web interface issue than an OctoPrint-PolarCloud plugin issue.

[howsTricks]

Actually, now that I'm watching a bit more closely and at the gcode viewer in OctoPrint, looks like the location of the model is not where it shows in PolarCloud. See attached.

[dnewman-polar3d]

This is a fine spot for now....

Is your printer Cartesian or Cartesian 200 x 200? (Hopefully the former.) And did you adjust your starting gcode?

If you look at one of your queued jobs, you can right click on those three vertical dots along the right edge. And from that you can download the slicing config which should have been sent to your printer. It should have posx=52500 and posy=100000. And that's telling Cura to translate the print away from the corner (0,0).

[dnewman-polar3d]

I pulled your STL and it looks to be centered at (X,Y) = (0, -55m) or so?

[howsTricks]

My printer is X105 Y200 (Printrbot Play with extended bed). Just thinking something isn't right when comparing the screenshots, looks like the translation doesn't line up with what is shown in the PolarCloud interface.

[dnewman-polar3d]

Ahh, centered at (0, -54.46) to be more exact.

Now, I believe Cura then translates it by +52.5mm on C and +100.00mm on Y so it should then be centered at (52.5, 45.54) on your build platform.

Also, I believe that the cloud feeds the .ini file to the plugin. The plugin may do some additional handling of it? I'm assuming it leaves posx and posy in good shape? Not easy for me to test that directly as my printers all have (0,0) at the center of the build plate and not at a corner.

[dnewman-polar3d]

From my experience with the Printbot Metal Plus and Simple, the advertised bed dimensions don't exactly agree with reality. (BTW, seen the Printbelt yet? That's a collaboration between Printbot and Polar3D.)

[dnewman-polar3d]

Sorry, not so much the bed dimensions but what results as the resulting position after doing a G28. I.e., values then asserted from either M206 or M212 settings or both. I seem to recall on the Metal Plus finding, after homing with G28, that the current position wasn't quite what I expected it to be causing not quite correct centering when using the bed dimensions for posx and posy.

If that is indeed your case, you can look at your 206 and 212 values via M503 and adjust. Or adjust the dimensions you tell the cloud. It's generating posx=(x-length)/2 and posy=(y-length)/2. Or, after G28 asserting G92 X0 Y0 in your starting gcode.

Or, I could be completely off in left base....

[dnewman-polar3d]

Note further that asserting G92 X0 Y0 assumes homing X,Y min....

[howsTricks]

Looking at the gcode viewer again, this is what was generated

This is pretty weird as it doesn't line up with what is shown in polar cloud, I would expect the model at either one end of the rectangle or the other, but not in the middle (and half way off the bed)

[howsTricks]

Ok, so this may be partially my fault, looks like my Printer Profile was set to "default" instead of my printer, which I assume the built in slicer uses for reference. See below for an updated gcode viewer showing the model centered. However, still doesn't line up with the location shown in the PolarCloud interface.

[dnewman-polar3d]

Two items,

1. When I look at your STL, it still looks like it should be centered by Cura at (52.5, 45.54).
2. There is an issue with the generic "Cartesian" printer type that may be confounding this. I have someone else looking at it now. (Go over to the PLACEMENT tab to the left of PRINT SETTINGS and then look at the values for the Move option....)

[dnewman-polar3d]

Marcus has made a fix to issue 2 -- print settings move values being NaN non-values (not-a-number). That'll percolate out this evening when the production servers are refreshed.

[dnewman-polar3d]

I believe this issue is now resolved.