Post Processing Plugin

[MiguelAngelLV]

We need a "guide" to develop plugins to new systems. I have a plugin I would like port to new system but I don't know how start

[Dim3nsioneer]

+1
I'm in contact with @awhiemstra about future 'plugins' and having any easy API for postprocessing scripts again.

[adeebshihadeh]

Fortunately, it seems like EVERYTHING is a plugin - even the USB communications.

[MiguelAngelLV]

And the "concept" of old plugins? The plugins that only modify the gcode.
We would need I few examples to port the current plugins.

2015-05-28 7:01 GMT+02:00 quillford [email protected]:

Fortunately, it seems like EVERYTHING is a plugin - even the USB
communications.

—
Reply to this email directly or view it on GitHub
#13 (comment).

Miguel Ángel López

[awhiemstra]

The current idea is to develop a post-processing plugin that implements similar functionality as the old post-processing plugin structure. I have been discussing the details with @Dim3nsioneer in private, but we can also move that discussion here for more input.

[MiguelAngelLV]

Perfect

2015-05-28 9:09 GMT+02:00 awhiemstra [email protected]:

The current idea is to develop a post-processing plugin that implements
similar functionality as the old post-processing plugin structure. I have
been discussing the details with @Dim3nsioneer
https://github.com/Dim3nsioneer in private, but we can also move that
discussion here for more input.

—
Reply to this email directly or view it on GitHub
#13 (comment).

Miguel Ángel López

[Dim3nsioneer]

I would appreciate to have other opinions than just mine... ;-)

@quillford: The new plugins require quite some programming skills... the entry level is a bit too high IMHO for standard Cura users...

[adeebshihadeh]

@Dim3nsioneer you also have to keep in mind that many (if not most) users of repraps and Cura are programmers :P

[Dim3nsioneer]

@quillford User segments have significantly changed since autumn 2014...

[daid]

@quillford RepRaps is only tiny segment of the Cura users. Programmers are only a minuscule faction of the Cura users.

[nallath]

I've started with this. You can find the first bits here https://github.com/Ultimaker/Uranium/wiki/Plugin-Types

[nallath]

Some more info;
https://github.com/Ultimaker/Uranium/wiki/Creating-plugins
https://github.com/Ultimaker/Uranium/wiki/Backend-&-Plugin-structure

The documentation will also be updated soon. Please let me know if this is what you guys need to get started.

[MiguelAngelLV]

@nallath I don't know yet how I start to develop a post-processing gcode plugin...

[nallath]

The post-processing plugin type is not yet implemented, so there is no documentation to write in that regard, sorry.

The hackish solution would be to to use an extension plugin. I will discuss this with @awhiemstra. Will get back to you.

[awhiemstra]

So these are the preliminary requirements we came up with:

• Post processing files should be a single python file with a single entry point.
• Post processing files should work on a list of strings representing GCode, not on files as they used to do.
• Post processing files will not be sandboxed or otherwise restricted in their execution until there is clear proof that people are exploiting things this way.
• There should be a way to configure post processing files from the post processing plugin.
• It should be possible to run multiple post processing files after each other, including multiple instances of the same plugin.

[gearsawe]

I have had some success but it is all a hack really and the only way I have found to make this work for what I need, those who own a M3D Mirco and want to use 15.06
I modified the Original Gcode writer which access settings from those set thru the printer config. I know the printer config is not where these setting should be but in this case yes. Since the settings are for making changes to gcode which are specific to the printer.
I tried to make a separate GcodeWriterM3D along side of the GCodeWrite but all it seem to do is use the original and ignore mine.
@BagelOrb thanks for the example plugin. This give us something to dwell on. And still is not easy to figure this all out.

What Would really be nice if:
-Pose Process Plugs are run at save.
-You could make your own setting there.
-Setting could be saved to an ini file which could be loaded later at the time the plugin is run. (This of course to be done thru normal python script. And up to the programmer to make their own saving format.)
-Not only would being able to run multiple posting processing files but ability to chose the order.

[adeebshihadeh]

@gearsawe I heard that M3D's software uses CuraEngine. Why does it need a post processor?

[gearsawe]

@quillford Well their spooler does post processing of the gcode which is 100% not correct. They do some really weird stuff to the gcode before it is sent to the printer and I found a way to "fix" things. I process the file before they do so their program do not mess things up. M3D print does accept gcode. They have their own software which basically uses the old Cura to create the gcode based on a bunch of preset. It would seem they refuse to fix their post processing since they fail to see the problem. I hope in time to completely bypass their software and use Cura to communicate to the printer making it much better printer. I am just doing baby steps.

Secondly they do not have a system in place for the public to report bugs and track bugs. I would label this one as a show stopper.

[Dim3nsioneer]

@awhiemstra @nallath Can you comment on the status of a post processing script system? Do you request action from the community or will you come up with some code?

[awhiemstra]

Now that 15.06 is out we are once more doing work on feature development. I have started working on an overhaul of the output device API as that is also sorely needed. After that I plan to create a post processing plugin, which is hopefully going to be somewhere next week. Before that, I would like to know any additional requirements we did not yet think of.

[gearsawe]

@awhienstra I would also guess the post processing should also have a way for it save and recall settings. I hacked a plugin together for my own personal use and stored settings in the printer config. The problem is I wanted the same plugin settings to be used across multiple printer configs. This make it kind of difficult with my setup. Secondly if I disable my plugin then close Cura then Open re-enable the plugin again I have lost my setting and the are back to the defaults. I am sure with some time I could make something stores setting in a INI file then save and recall from there. My goal it to be able to have multiple profiles which can be chosen from within the same plugin. Hope this make sense. Still very new to Cura but love it so far.

[nallath]

You could use the preferences for this. Take a look at my printer cost calculation plugin.

[nallath]

I've started work on this. See https://github.com/nallath/PostProcessingPlugin

[nallath]

Just a quick update; A first sort of working version is up. Check it out.

[nickthetait]

Good to hear. Does it do something specific or is it a generic demo of how plugins can be implemented?

[nallath]

Its plugin that runs scripts (which sorta are plugins on its own). I've added the pause at height script that used to be in the old Cura, so it actually does something.