Not working for me

[b-morgan]

Not working for me

[Willmac16]

@b-morgan could you share the file you tried it on? The plugin currently detects the first layer start marker and only then begins shifting the gcode around.

[b-morgan]

3DBenchy.zip

[Willmac16]

I'll work on getting the RegEx to match and get back to you once it is working.

[b-morgan]

I have quite a few slicers installed including S3D if you want gcode from each to test with.

[Willmac16]

That would be amazing, I'll also try to make the RegEx a user editable setting in the future.

[b-morgan]

The file I previously uploaded has been renamed to 3DBenchy_CuraLE. I have included a couple of slicers you've probably already tested, Ultimaker Cura 4.8.0 and PrusaSlicer 2.3.0. In addition, KISSlicer 1.6.2, ICESL 2.3.5, and Simplify3D. S3D is the only one you have to pay for, KISSlicer and ICESL are more obscure.

I have a few more, CraftWare, ideaMaker, and MatterControl all of which are free downloads. I didn't include files for them unless you want them.

3DBenchy.zip

[Willmac16]

Awesome! I think those should work quite well for now.

[Willmac16]

Looks like the regex was failing because I didn't account for a CTLF line ending. I'll get that fixed up and test on the other sliced files.

[Willmac16]

@b-morgan Try installing with this url https://github.com/Willmac16/OctoPrint-TranslateModel/archive/main.zip, it should fix the issue with your original file. I was able to get it to work properly with 4 of the 6 files you sent, and I will work to get all 6 of them working.

[b-morgan]

I tested with the CuraLE version and it did translate as requested. The line endings changed which isn't a big deal (except it made comparing the files a challenge).

What might be a big deal is that it changed the E values. The original had E values to 5 decimal places and the translated file has E values to 4 decimal places. I'd have to print both files and see if the difference is visible to be sure.

The following experiment failed. Translate the translated file reversing the translation. I translated the original CuraLE file by X=20, Y=20. I then attempted to translate the result by X=-20, Y=-20 and it failed. I believe it is because the output layer line doesn't match your regex. I used a different file (5x5x5mm cube) because my Notepad++ compare plugin was taking forever on the 3DBenchy.
Test_Cube.zip

[Willmac16]

• I have changed the code so it will now preserve line endings in the output file
• I do see some lines with 4 decimal places, but there are the same number between all three versions and most lines come out with 5 decimal places.

* The double translation appears to have failed because my regex didn't like the `;TRANSLATE-MODEL_LAYER-START` comment that I added to the same line.

The link to download the newest code is https://github.com/Willmac16/OctoPrint-TranslateModel/archive/main.zip. Thank you for all of you testing and feedback!

[b-morgan]

The latest version (you really should change the version number for each build) is still converting 5 decimal E values to 4
decimal values in the attached files.

Also, the line endings did not remain the same.

3DBenchy3.zip

What command did you use to get the test results?

[Willmac16]

I screwed up the download url. https://github.com/Willmac16/OctoPrint-TranslateModel/archive/devel.zip is what you want.

I was running a RegEx search in my text editor for the whole folder I was in. It is possible that the LF line endings are causing the last character to not display for you.

You could replicate with. grep -E "E[0-9]{1}\.[0-9]{4} <path-to-file> | wc -l

[b-morgan]

I believe the command should be: grep -c -P -e 'E\d+\.\d+\r*$' Test*.gcode or grep -c -P -e 'E\d+\.\d{5}\r*$' Test*.gcode

This catches all the lines with an E parameter, not just those with a single digit left of the decimal point. The \r* before the $ at the end handles both Windows (DOS) and Unix line endings.

Using those commands gives the following output and as you can see, some 5 decimal E parameters are getting converted to 4 decimal and some 4 decimals are getting converted to 3 decimals. My contention is that you shouldn't be messing with them at all. It appears that you are converting them to float and then back to strings.

+ grep --color=never -c -P -e 'E\d+\.\d+\r*$' Test_Cube.gcode Test_Cube.translate_20_20.gcode Test_Cube.translate_20_20.translate_-20_-20.gcode
Test_Cube.gcode:634
Test_Cube.translate_20_20.gcode:634
Test_Cube.translate_20_20.translate_-20_-20.gcode:634

+ grep --color=never -c -P -e 'E\d+\.\d{5}\r*$' Test_Cube.gcode Test_Cube.translate_20_20.gcode Test_Cube.translate_20_20.translate_-20_-20.gcode
Test_Cube.gcode:569
Test_Cube.translate_20_20.gcode:373
Test_Cube.translate_20_20.translate_-20_-20.gcode:373

+ grep --color=never -c -P -e 'E\d+\.\d{4}\r*$' Test_Cube.gcode Test_Cube.translate_20_20.gcode Test_Cube.translate_20_20.translate_-20_-20.gcode
Test_Cube.gcode:59
Test_Cube.translate_20_20.gcode:237
Test_Cube.translate_20_20.translate_-20_-20.gcode:237

+ grep --color=never -c -P -e 'E\d+\.\d{3}\r*$' Test_Cube.gcode Test_Cube.translate_20_20.gcode Test_Cube.translate_20_20.translate_-20_-20.gcode
Test_Cube.gcode:6
Test_Cube.translate_20_20.gcode:24
Test_Cube.translate_20_20.translate_-20_-20.gcode:24
+ exit

The above was captured before I installed the latest URL. I'll do that now and report back.