Cura 2.4 and Post Processing Scripts?

[mprowe 1]

I am trying to use the Pause at Height (I would really like a Pause@Layer) script.

However, although, it seems to work, the only changes made to my gcode file is to insert this:

Any thoughts?

Regards, Martin

[Kin 3]

I suggest uploading your gcode as well, your copy of pause at height, and also let know (and confirm) what you put the pause layer height at.

I suspect it's just that you are attempting to pause above a layer that the gcode gets to, as a typo or something.

[mprowe 1]

I suggest uploading your gcode as well,

Two test files (10mm high, 5mm dia cylinder. With & without gcode mods.

UM2_PauseAtHightTest.gcode1

UM2_PauseAtHightTest.gcode2

 

your copy of pause at height, and also let know (and confirm) what you put the pause layer height at.

The "pauseAtHight" script is whatever is distributed with Cura2.4! And this is the GUI:

All that happens is that a comment (;POSTPROCESSED) is inserted at line 5.

Regards, Martin

[Kin 3]

Hi Martin,

I checked over the pause@height and I couldn't find any major issues why it would fail for your parameters and gcode.  It should be starting to look at your lines after LAYER:0, and the it should find the first Z that is above the z target, so it finds Z5.07 around layer 49, and it should then insert the pause script (m83 + anything you modify the plugin with, but I think you indicate you haven't odified it.)

Have you tried any of the other default scripts? Maybe the tweak@Z or something?

One suggestion: can you try pausing it at a height other than 5.0mm? maybe it's an odd bug that doesn't register 5.0 since it's the default, and even though it's showing 5.0.. try maybe 5.02 if you want it to pause around 5mm (your first >5mm layer is 5.07mm)

Edited March 14, 2017 by Guest

[Kin 3]

edited this post because I think I'm shooting too far from hip, I will try to look into pause@height but also suggest trying a couple other gcodes/files, and also a different height (not 5.0 try 5.02 or something randomly different.)

just trying to troubleshoot.

Edited March 14, 2017 by Guest

[mprowe 1]

Hi Kin,

Thanks for looking at this. I have taken your advice and tried several other test strategies. Does this help:

1. Run the Cura 2.3.1 PauseAtHight script on an openSuSE 42.1. It works.

2. Ran the Cura 2.4 PauseAtHight on an openSuSE 42.2. It does not work.

So, whats different?

1. Cura 2.3.1 is shipped as a deb package. I have to use Alien to convert to an RPM for SuSE. But that seems to be fine.

2. Cura 2.4 ships as a AppImage package. According to AppImage.org, you just run it.

In case 1. the path to PauseAtHight.py is:

 

~>find / -name Pause*.py/opt/cura/lib/cura/plugins/PostProcessingPlugin/scripts/PauseAtHeight.py

 

and in case 2. the path is:

 

~>find / -name Pause*.py/home/mprowe/Cura-2.4.0/usr/bin/plugins/plugins/PostProcessingPlugin/scripts/PauseAtHeight.py

 

Is this significant?

Regards, Martin

[amedee 349]

As I was curious I just tried 2.4 on Debian Jessie...

 

1. Running AppImage: same issue as you have
   
2. Mounting the AppImage and starting AppRun: no change
   
3. Copying the image content to another location (So I can edit files for debugging): it all works, except PostProcessingPlugin which crashes at startup!!! (see below)
   

 

 

2017-03-14 16:42:00,604 - INFO - UM.PluginRegistry.loadPlugin [100]: Loaded plugin VersionUpgrade21to222017-03-14 16:42:00,618 - ERROR - UM.Logger.logException [65]: Exception: Error loading plugin PostProcessingPlugin:2017-03-14 16:42:00,620 - ERROR - UM.Logger.logException [69]: Traceback (most recent call last):2017-03-14 16:42:00,621 - ERROR - UM.Logger.logException [69]:   File "/build/2.4/build/inst/lib/python3/dist-packages/UM/PluginRegistry.py", line 87, in loadPlugin2017-03-14 16:42:00,623 - ERROR - UM.Logger.logException [69]:   File "/opt/cura24/usr/bin/plugins/plugins/PostProcessingPlugin/__init__.py", line 21, in register2017-03-14 16:42:00,624 - ERROR - UM.Logger.logException [69]:     return {"extension": PostProcessingPlugin.PostProcessingPlugin()}2017-03-14 16:42:00,625 - ERROR - UM.Logger.logException [69]:   File "/opt/cura24/usr/bin/plugins/plugins/PostProcessingPlugin/PostProcessingPlugin.py", line 37, in __init__2017-03-14 16:42:00,627 - ERROR - UM.Logger.logException [69]:     self.scriptListChanged.connect(Application.getInstance().getBackend().forceSlice)2017-03-14 16:42:00,629 - ERROR - UM.Logger.logException [69]: AttributeError: 'NoneType' object has no attribute 'forceSlice'2017-03-14 16:42:00,654 - INFO - UM.PluginRegistry.loadPlugin [100]: Loaded plugin TranslateTool

 

@nallath: is this expected behaviour? because if you can't run from a copy of the image, you can't install your own plugins anymore (or your own printer definitions)...

Edited March 14, 2017 by Guest

[Kin 3]

I am glad to have encouraged some movement on this post, but I admit I'm out of my comfort zone for debugging this. It does look like you found a genuine issue with 2.4 install on linux, but I don't know exactly what you've found. For the record i run in windows and expect the scripts in program files>cura>plugins>postprocessingplugins>scripts, which is totally different.

Hopefully someone with more knowledge (looks like already one other person has responded) will have a better sense of whether or not this should be pushed to a github issue.

Although what you've found so far suggests that there's a global issue with the post processing effects, but I still suggest also trying another script like the tweak@Z, if only because you can probably find a temporary work around if you can get some other script to work

[amedee 349]

I have investigated a bit why the PostProcessing plugin crashes, and it is a 'race condition'.

I have taken screenshots as the 'code formatting' of the forum is not always great...

First case: AppImage mounted on /opt/cura24 -- the PostProcessing pluging starts correctly:

Second case: AppImage copied on /opt/cura24 (respecting file attributes) -- the PostProcessing pluging crashes because the backend is not started yet, and Application.getInstance().getBackend() returns None:

I have really no clue on why this happens...

[amedee 349]

Mystery solved: PluginRegistery uses os.listdir() to get plugins. Order is not defined with this call, so depending on how the files are in the directory block, you get different results, and I am unlucky to have CuraEngineBackend at the end.

Small test to illustrate:

 

>>> import os>>> os.listdir("/opt/cura24/usr/bin/plugins/plugins")['XRayView', 'UltimakerMachineActions', 'GCodeProfileReader', 'CuraProfileWriter', 'ConsoleLogger', 'LocalFileOutputDevice', 'FileHandlers', 'Views', 'GCodeWriter', 'MachineSettingsAction', 'LayerView', 'X3DReader', 'SliceInfoPlugin', 'VersionUpgrade', 'PostProcessingPlugin', 'Tools', 'USBPrinting', 'PerObjectSettingsTool', 'LegacyProfileReader', 'CuraProfileReader', 'SolidView', 'UM3NetworkPrinting', 'XmlMaterialProfile', 'ChangeLogPlugin', '3MFReader', 'ImageReader', 'CuraEngineBackend', 'AutoSave', 'Doodle3D', 'RemovableDriveOutputDevice', 'UpdateChecker', '3MFWriter', 'FileLogger']>>> os.listdir("/mnt/usr/bin/plugins/plugins")['3MFReader', '3MFWriter', 'AutoSave', 'ChangeLogPlugin', 'ConsoleLogger', 'CuraEngineBackend', 'CuraProfileReader', 'CuraProfileWriter', 'Doodle3D', 'FileHandlers', 'FileLogger', 'GCodeProfileReader', 'GCodeWriter', 'ImageReader', 'LayerView', 'LegacyProfileReader', 'LocalFileOutputDevice', 'MachineSettingsAction', 'PerObjectSettingsTool', 'PostProcessingPlugin', 'RemovableDriveOutputDevice', 'SliceInfoPlugin', 'SolidView', 'Tools', 'UltimakerMachineActions', 'UM3NetworkPrinting', 'UpdateChecker', 'USBPrinting', 'VersionUpgrade', 'Views', 'X3DReader', 'XmlMaterialProfile', 'XRayView']

 

This would be perfectly OK if there were no dependency, but as PostProcessingPlugin depends on  CuraEngineBackend and it comes later in my copy...

I have filed this on Github (#1541), in the meantime I'll try to play with my directories to get things in the 'right' order so we can focus on the actual problem...

Edited March 14, 2017 by Guest

[amedee 349]

.... And we have white smoke!

 

;TYPE:CUSTOM;added code by post processing;script: PauseAtHeight.py;current z: 5.000000M83G1 Z6.000000 F300G1 X190.000000 Y190.000000 F9000G1 Z15 F300M84 E0M0 ;Do the actual pauseG1 Z6.000000 F300G1 X98.917000 Y93.260000 F9000G1 F9000M82G92 E110.758660;LAYER:47

 

I have filed a GitHub issue (#38)

Edited March 14, 2017 by Guest

[mprowe 1]

.... And we have white smoke!

Thank you Amedee,

What happens now (I'm new around here, you see...)?

Will there be a Cura 2.4.x released at some time with this fix included?

Regards, Martin

[amedee 349]

Will there be a Cura 2.4.x released at some time with this fix included?

 

I'm afraid not, you will have to wait for 2.5. It is fixed in 2.5 tree and 'master', they do not fix it in 2.4 source tree, which seems to tell us we won't have another 2.4.x before 2.5. But that's just how I see it.

The fix itself is very easy, you just need to correct the typo in PauseAtHeight.py Line 40 (amount instead of ammount).

Now on Linux it is a bit tricky as you have to explode the AppImage for this fix, and you might run into the other issue I had 2 posts above... This could be easily fixed as well in CuraApplication.py, but unfortunately it is frozen, so you have to download it first. Maybe you will be lucky to have it running (it is really random), if not I'll provide detailed instructions tonight.

[mprowe 1]

[...] Maybe you will be lucky to have it running (it is really random), if not I'll provide detailed instructions tonight.

 

Yes, please Amedee,

I did try on my own! I unzipped the AppImage, edited line 40 of the script and ran AppRun. However, now I do not get the Post Processing options under the Extension Drop-Down Menu.

Regards, Martin

[amedee 349]

 

TL; DR

You can download Cura-2.4.0-bUlles.AppImage which contains the fixes.

Checksum:

 

$ sha256sum Cura-2.4.0-bUlles.AppImage 35d85a9e6834e82ef180c52dba98e72a0a2e4d22210a3452a93eabb67a6130d5  Cura-2.4.0-bUlles.AppImage

 

 

Long Story - the hard way

When you unpack the image you run in the GitHub issue #1541.

This can be fixed in CuraApplication.py by un-indenting lines 398 & 399.

The problem is that you don't have this file as it is frozen, but you can get it from github. Here is an example of what you can do (I have unpacked the image in /opt/cura24):

 

root@wheezy64:~# wget https://raw.githubusercontent.com/Ultimaker/Cura/2.4/cura/CuraApplication.pyroot@wheezy64:~# cp CuraApplication.py /opt/cura24/usr/bin/lib/python3.5/cura/root@wheezy64:~# vi  /opt/cura24/usr/bin/lib/python3.5/cura/CuraApplication.pyroot@wheezy64:~# diff CuraApplication.py  /opt/cura24/usr/bin/lib/python3.5/cura/CuraApplication.py398,399c398,399<             self._plugin_registry.loadPlugin("ConsoleLogger")<             self._plugin_registry.loadPlugin("CuraEngineBackend")--->         self._plugin_registry.loadPlugin("ConsoleLogger")>         self._plugin_registry.loadPlugin("CuraEngineBackend")

 

That's it, now it should work as intended.

Edited March 15, 2017 by Guest

[mprowe 1]

You can download ....

Thank you very much Amedee,

Took the easy route, and it works like a dream.

Many, many thanks, Martin