x3g exporter assumes machine is always a replicator 2 (print shrunk on rep1/clones)

[studiofuga]

When exporting to x3g format, MC always assumes the target machine has the replicator 2 machine parameters, in particular the mm/steps ratio. This is not true for most makerbot clones, for example, on my CTC dual which has the Replicator 1 parameters. This results in printers that are shrunk along all the axes by about 6%. my 40mm test print was 38mm long.

In ExportPrintItemWindow.cs, line 558:

private void generateX3GfromGcode(string gcodeInputPath, string x3gOutputPath, string machineType = "r2")

and it's called from line 431:

generateX3GfromGcode(sliceItem.GetGCodePathAndFileName(), x3gPathAndFilenameToSave);

On my CTC it should be called with r1.

[unlimitedbacon]

The steps/mm (among other machine specific settings) are defined in your On Connect G-Code using the M92 command. These default to the Replicator 2 values, since that is what is used by all the printers we have profiles for. However, you can override them with whatever you need to.

The code you are looking at is leftover from MatterControl's old method of exporting X3G files (using GPX). It is no longer used.

If you get a working profile, let us know. We offer $15 MatterHackers store credit for printer profiles. There is an existing profile for the CTC Bizer that we know is good. However I am not sure whether it is for the Bizer I, II or III. Which printer do you have?

[studiofuga]

Hi, thank you for your response. Unfortunately the M92 code doesn't work for this purpose. I tested it with the following strings: M92 X95.7089 Y95.7089 but the resulting print is still 38mm. I guess it is due to the fact that the s3g protocol works with steps measures, not mm, so it would impossible to change the arguments on the fly. Unfortunately there's no easy solution, except by altering the proportions of the geometry, including the layer height, and the extrusion volume, but it's impractical. Yes I noticed the ubuntu installation package provides a GPXDriver.dll that isn't created when building from 1.6.1 and 1.6.2b releases. Unfortunately I have too little experience with mono development to provide a patch.

By the way, my machine is a CTC dual, i.e. a Replicator 1 Dual clone (r1d on gpx), with sailfish 7.7 firmware, it has a different steps/mm ratio (95.708958 on x and y, 400 on z). the extruders are geeetech mk8, I suspect they have a different step/mm ratio than the original extruders, but it's yet another step.

Also, I am testing with slic3r and the original gpx, except for the origin position (I had to tweak the profile), the axis / mm are ok with those values and the print is correct.

[unlimitedbacon]

I just did some test prints and M92 is working as it should. Changing the steps/mm for the X axis from 88.8 to 44.4 resultedd in an object half as long. We have also tested on printers that use both the rep 1 and rep 2 values. We have a Makerbot Replicator 2 that uses 88.8 steps/mm and a Flashforge Creator X which uses 94.5 steps/mm. Both machines print correctly.

Did you try disconnecting and reconnecting the printer after you changed the values? Does it only do this when printing an exported X3G file from SD or does it do it when printing directly from MatterControl over USB as well?

[studiofuga]

I tried only with sdcard. I tried both adding the M92 on the OnConnect box and on OnStart. I'll try directly with the connected printer when possible. Thanks