Willmac16 / OctoPrint-TranslateModel

An OctoPrint plugin to move models around without re-slicing
https://plugins.octoprint.org/plugins/translatemodel/
GNU Affero General Public License v3.0
7 stars 1 forks source link

Not working for me #5

Closed b-morgan closed 3 years ago

b-morgan commented 3 years ago

I installed the plugin and attempted to use it. My first comment is that it isn't immediately obvious how to run it. Clicking on the icon in the file list doesn't appear to do anything. I was expecting the translate model dialog to pop up but it did not.

I moved to the Translate Model Plugin tab and found the file name, x and y at 0 and with "do nothing" selected. I changed X and Y to 10 and clicked the translate button. This did start the process and generated a new .gcode file. I downloaded the original file and the translated file and compared them. They were identical (i.e. no translation took place).

I thought maybe "do nothing" was exactly that so I went back to the tab and selected "load". Clicking on the translate button does nothing. The process won't run a second time.

My printer is a LulzBot TAZ 6. Since the start gcode includes wiping the nozzle on a pad in a fixed location, I was curious if those commands would get translated which would render the resulting gcode useless.

Below is my system info. Let me know if you want anything else.

browser.user_agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:86.0) Gecko/20100101 Firefox/86.0 connectivity.connection_check: 8.8.8.8:53 connectivity.connection_ok: true connectivity.enabled: true connectivity.online: true connectivity.resolution_check: octoprint.org connectivity.resolution_ok: true env.hardware.cores: 4 env.hardware.freq: 1200 env.hardware.ram: 915058688 env.os.bits: 32 env.os.id: linux env.os.platform: linux env.plugins.pi_support.model: Raspberry Pi 3 Model B Rev 1.2 env.plugins.pi_support.octopi_version: 0.18.0 env.plugins.pi_support.throttle_state: 0x0 env.python.pip: 20.2.4 env.python.version: 3.7.3 env.python.virtualenv: true octoprint.safe_mode: false octoprint.version: 1.5.3 printer.firmware: Virtual Marlin 1.0

Willmac16 commented 3 years ago

@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 commented 3 years ago

3DBenchy.zip

Willmac16 commented 3 years ago

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

b-morgan commented 3 years ago

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

Willmac16 commented 3 years ago

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

b-morgan commented 3 years ago

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 commented 3 years ago

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

Willmac16 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.