Cube3 File Editor

Don't let me distract you from what you were doing.

Attachment 3317
This is what I have been doing -- printing a combine for my brother-in-law farmer. :)

SWEET! :o

New version with builder app that will reassemble cube3 file. I haven't tested the resulting CUBE3 on the printer, yet. But here is how I would test it:

1. use CubeExtract (cex.exe) to extract the files into a folder (all by themselves)
2. Edit cube3 file to hearts content.
3. Make sure that there aren't any backup files or script files or anything that wasn't put there by CubeExtract
4. use CubeBuild (cbld.exe) to combine the files in the folder back into a cube3 file.

I did verify that cube3editor can open the file. Now to check to see if it can print. :)

- - - - - - - - - -

So, I am going to have to modify the XML as well, there are a a few fields that need to be modified.

1. <type> -- > needs to be cube3
2. <extruder1> --> <code> -- needs to match E1
3. <extruder2> --> <code> -- needs to match E2
4. <extruder3> --> <code> -- needs to match E3

I assume that I will also need to do a crc32 of the cube3 file after compressing for the <build_crc32> portion...

- - - - - - - - - -

Yep -- getting an error 0x1020002 -- print file not valid.

- - - - - - - - - -

I have it working with some manual intervention.

1. <type> needs to be "cube" not "cube3"
2. <build_crc32> does indeed need to be updated properly for just the encoded cube3 file not the combined set of files version of the cube3.
3. <extruder1-3> needs to match the material in the cube3 file.
4. <recycled> needs to be 0 if the original came from an Ekocycle profile.

Now, to figure out how to incorporate this into the main program to extract, store, update both the cube3 and index.xml files. Easy, peasy, lemon-squeezy, right? :D

- - - - - - - - - -

I forgot to mention, I was able to transfer the file to the printer over WiFi....

You're having way to much fun with this!

Not valid file -and- WiFi printable? ...or an alternate submission process outside CubePrint?

I might like the option "trim" and "full" re-encryption. It might be a way to stuff the 50MB limit with a few more moves.

Sorry, I got excited.

After making the manual changes to the XML files, and using the builder app to reassemble the parts, I was able to use CubePrint to send the file to the printer over WiFi. :)

Way cool!

So here is a something to consider for the header. And I don't know the implications of not addressing it...
But the sidewalk and support material values should track whichever it was assigned to.
The tricky part is knowing which color the supports and/or sidewalks were assigned to.
Just another subroutine for the material value parsing when you get back to it ;p

Are you adjusting the .xml section to match the BFB section or just adjusting the checksum?

So, there seem to be 3 of these types of fields;

Sidewalks
Supports
Rafts

Sidewalks and Supports are visible in the CubePrint software, but not the rafts. I haven't determined if those are booleans, true/false, or if they are a set of flags that mark which extruder has which enabled. So, yes, this is tricky, and I will likely start producing some cube 3 files with the following matrix for the Ekocycle and Cube3 modes:

Left: Sidewalk off, Support off. Right: Sidewalk off, Support On.
Left: Sidewalk off, Support off. Right: Sidewalk On, Support off.
Left: Sidewalk off, Support Off. Right: Sidewalk On, Support On. ==> this one may not be necessary
Left: Sidewalk off, Support On. Right: Sidewalk off, Support off.
Left: Sidewalk on, Support off. Right: Sidewalk off, Support off.
Left: Sidewalk off, Support On. Right: Sidewalk off, Support On.
Left: Sidewalk On, Support Off, Right: Sidewalk On, Support Off.

We currently know that with them both off on both extruders, that they are -1, so, no need to check that one.

Right now, I am adjusting the fields I mentioned earlier:
<type> == to be "cube"
<build_crc32> == to be the CRC32 of the raw Cube data
<extruder1-3> -> <code> == to match the material code of Extruder 1-3
<extruder1-3> -> <recycled> == set to 0

Do you want to do those checks for us? and provide me with numbers for each combo? :) Maybe we can extrapolate the raft flags as well, then we can add that to the cube3 editor.

Rafts are only supported by 3D Builder. And we can't get to those files.

Here's my take on qualifying which extruder is assigned to supports and sidewalks:

E1 and E2 are populated; [confirm 2 extruders loaded]

tests
E1=/=sidewalk [not -1]
E2=/=sidewalk [not -1]
E1=/=support [not -1]
E2=/=support [not -1]


E1 or E2 is populated and so are sidewalks or supports. Then you track that material code.
[single extruder means only one solution; are either supports or sidewalks -not- -1]

When -if- is satisfied, you make sure these two values track going forward.
Basically, you are manually identifying which nozzle the sidewalk and the support are assigned to.

These -if- statements will solve matching the extruder to the support and sidewalk layers.
It is more or less records keeping data. But that is where apps tend to explode.

Oh, how I wish I could get 3DBuilder to work with my printer, but maybe it is because mine is a Ekocycle converted to a Cube3...

But yeah, I think I get where you are coming from with your suggestion above. Let me know what you come up with. I will look at it when I get the XML processing working...