Cura Engine for Binder Jet 3D printing (BJP): plugin, extension, ... ?

[piter123 0]

Hi all, I'm posting here as I would like to hear your comments/advises regarding my current endevour.

 

I am developing the control software for a custom 3D printer which binds together "sand" by dispensing "glue" in the required areas.

The similarities to fdm:

- one or more nozzles move in the XY plane and dispense the binder (instead of extruding plastic)

- it requires walls and infills to be computed

- most of the fdm-printing settings are relevant also for bjp

 

However, there are also several differences:

- it needs a set of routines extraneous to fdm (sand refill, sand recoat, ...)

- the nozzles are not operated by stepper motors (solenoid valves)

- whereas many fdm-settings can be used, several are not needed and a few need to be added

- several fdm-related features are not needed (support, brims, rafts, skirts, ...)

 

My first thoughts. To integrate the extra routines, most of the changes would need to be done to the engine itself, particularly to the following files:

- GCodeExporter

- all the files starting with FFF (FffProcessor, FffPolygonGenerator, FffGcodeWriter)

- finally one more command would be needed in the main Application (say "sliceBjp") and some changes to handle it in the "Communication" (i.e. cura::Commandline)

 

My current approach:

- I am modifying the engine with the aim to call it from the cura GUI instead of the "original" one

- I will need some custom settings definitions (btw, I really like your inherit-override approach)

- I will probably end up needing some extra widgets (GUI)

 

Now, the questions:

- the first one is easy: is there any way to apply the changes I need by writing a cura-plugin? Looking at the available examples, I would say there isn't

- From the naming of some files (the ones starting with FFF), it looks like the engine was set up with the idea of being extended to other methods: is that so? and, if so, what was the concept?

- beside plugins, is there any other way to apply the described changes without rewriting part of the engine?

 

As the project continues, I will most likely come up with new questions (I already see the communication with hardware-specific components at the horizon).

 

I would like this post to be useful to others who might want to implement other 3d printing strategies (i.e. SLA, WAAM, Concrete extrusion, ...) and, as such, was planning to continue writing here. That is all to say that, if some apparently-only-remotely-related question might come up, I hope the moderators will forgive me..

 

Pietro

 

 

 

 

 

[GregValiant 1,240]

In the year or so that I've been hanging around here I've developed some feel for the people involved in the work on Cura.  I'm sure that some would be able to give you guidance into what the thoughts were behind the software design.  Whether or not they have the time (or inclination) is another thing.  The Cura Team is heavily involved in the new Arachne version along with maintenance and support of the current and past versions.  Additionally I believe most are Ultimaker employees which will no doubt have some political implications regarding how they spend their time and what they give away for free.

 

Firmware design, mainboard design, and the physical design of your machine, are other things you have no doubt considered.  It would appear to be a fusion between FFF/FDM gcode generation and translation and CNC gcode generation and translation.  I would call it an ambitious endeavor.

 

I know some of these are directly involved in the Cura Team at Ultimaker.  In no particular order - @ghostkeeper, @nallath, @fvrmr, @rburema, @SandervG and @ahoeben at FieldOfView.  In addition @burtoogle (@smartavionics on GitHub) has his own thing going with Cura itself.  I hope none take offense that I've included their handles here (and that none I've left out take offense).

 

As for me...I know just enough about this stuff to hurt myself.

 

[ahoeben 1,948]

38 minutes ago, GregValiant said:

Additionally I believe most are Ultimaker employees which will no doubt have some political implications regarding how they spend their time and what they give away for free.

The biggest implication being that Ultimaker pays them to develop software for Ultimaker printers. The fact that it can also be used for other printers is a bonus. But any feature that does not directly benefit Ultimaker printers either has to come from community members like @burtoogle or me, or from printer manufacturers. The Ultimaker employees still take time to check and include these contributions, but at times they also have to reject features because it would take the project too far from what Ultimaker needs or it would take too much time in the future to maintain the feature in the codebase.

 

My contributions have been mainly in the frontend, not in CuraEngine. Some of the changes you need could be implemented by postprocessing the gcode that CuraEngine creates, which can be done with a plugin in Cura. CuraEngine does not have a plugin-system, only the frontend does. For example, I have written Blackbelt Cura (which is still for FFF printers, but slices at an angle) completely as a set of plugins.

 

2 hours ago, piter123 said:

it looks like the engine was set up with the idea of being extended to other methods: is that so? and, if so, what was the concept?

No, not really. As far as I know.

 

[ghostkeeper 105]

On 2/9/2021 at 12:48 PM, piter123 said:

the first one is easy: is there any way to apply the changes I need by writing a cura-plugin? Looking at the available examples, I would say there isn't

Indeed, as ahoeben already said, the changes to CuraEngine can't be implemented from a plug-in. You might be able to make changes in a post-processing step that works on the g-code string, but anything involving the polygonal shapes of support, slice layers, etc. will probably be impossible because it's very hard to retrieve the original shapes that were intended to be printed from just g-code. So you can't just perform a polygon offset or anything. Since you need to modify things in FffPolygonGenerator and FffGcodeWriter, I'm pretty sure that you can't do those things from just post-processing and will need to modify CuraEngine itself.

 

 

On 2/9/2021 at 12:48 PM, piter123 said:

From the naming of some files (the ones starting with FFF), it looks like the engine was set up with the idea of being extended to other methods: is that so? and, if so, what was the concept?

Cura has always just had the scope of FFF printing by design. There is however one SLA printer in Cura's printer list (Peopoly Moai) which is in a similar situation as you. They interpret Cura's g-code to generate the structures that will be solidified, if I understand correctly.

The names of these files have been this way since CuraEngine was started by daid (they were renamed at some point from "fdm" to "fff" only) and even then I think his only intention was to make it work for FFF. For instance, a polygon generator for SLA or something would be very similar in many ways, so that would need a more generic architecture anyway. In any case, don't wait on us to implement things outside the scope of FFF ;)

 

On 2/9/2021 at 2:18 PM, GregValiant said:

I know some of these are directly involved in the Cura Team at Ultimaker.

Of those, Nallath, Fvrmr, Rburema and I are in the Cura team (along with Jellespijker, Konskarm, Vandrasc and Evtrados who aren't active on this forum as far as I know). SandervG works for Ultimaker but not directly in the Cura team. We generally have fairly little to do with each other but we communicate about blog posts for Cura's releases. Ahoeben and Burtoogle are active outside contributors and know a lot about Cura in general.

[piter123 0]

5 hours ago, ghostkeeper said:

For instance, a polygon generator for SLA or something would be very similar in many ways, so that would need a more generic architecture anyway. In any case, don't wait on us to implement things outside the scope of FFF ;)

Never thought so :) 

Was just wondering if there was the intention to "direct" the way other people would do it (doesn't seem like)

 

On 2/9/2021 at 2:18 PM, GregValiant said:

Additionally I believe most are Ultimaker employees which will no doubt have some political implications regarding how they spend their time and what they give away for free.

Yep, totally understand it..

 

On 2/9/2021 at 3:05 PM, ahoeben said:

CuraEngine does not have a plugin-system, only the frontend does

 Ok, got it. I just started looking at the "engine", looks pretty straightforward to work with, and I already did something similar using "mattercontrol" (which, i believe, is some kind of C# version of cura).

 

One basic question: what should I use to build the c++ source code (on windows)? I'm asking as today I tried to call my "version" of the engine (built with MSVC) from the main app and it's spitting out some strange errors that seem somehow related (see the snip).

It could be a "spurious correlation", as I'm relatively new to c++..

One last detail: if i run my version from command line it behaves as expected.

 

 

[piter123 0]

Brief update: built it with mingw and the error is gone! only the executable size jumped from 6MB to about 80MB.. might be that I configured it as debug, check tomorrow

[GregValiant 1,240]

From 6 to 80 eh?  That's a better bloat ratio than Microsoft!