Cube3 File Editor

I think one of my problems was the fact that I changed the temperature values and updated them. This put out a script file that included the new values rather than the original 'from' values. Technically, at some point, you have to remove access to saving the script to keep all original 'from' values in tact. I'm not seeing the flow diagram you have in mind, but that seems to be at play in my brief observations.

My utmost usable utility is a series of batch files with standard conversion routines. Basically a set of command line batch files that says input this type and get out that type. You're already there! I'm lagging something fierce!

My 'development' scenario is to dial in specific routines for each element. Open the .cube3 file in the editor and output the script file. Edit the file and read it back in. Confirm the changes as edited in the script and save the .cube3 file. Before sending it to the printer, again confirm data by running c3sg.exe to make sure peaks are within limits and the header is correctly reported. Once a common script file is developed, it would get archived in a batch file for XYZ routine. That routine would be equivalent to opening the editor with a .cube3 file and reading in the 'common' script file; then save the .cube3.

- - - - - - - - - -

CUBE3PLA - EKOCYCLE - CUBE3ABS
EKOCYCLE - CUBE3ABS - CUBE3PLA
CUBE3ABS - CUBE3PLA - EKOCYCLE

This is the core conversion set. They have subset requirements. Minimizing those with commonalities is the challenge.

Even a quick look at temperature profiles I can tell you that they use a fairly complex routine for dual extrusion profiles.
But they do limit their increments to 5C which makes a table-approach possible.
Scenario; read in a standard temperature adjustment script that is pre-fitted to a user curve; let the chips fall where they may. Then read in retraction script separately...
The curves are easy to generate in Excel if you use a standard tables of say 2 dozen entries ranging from 190C to 265C (ignoring 155C).
Those and yours scenarios I need to start testing. Your scenario 3 is my development scenario.

- - - - - - - - - -

Already made the matrix bigger... CUBE3PETGonPLAchip < EKOCYCLE > CUBE3PETGonABSchip... I really don't like recipe development ;p

The save version of the tools with a valid digital signature. :)

https://drive.google.com/open?id=1gd...mhQ_f28-DhOI6e

I have attached a set of common Cube3 files for testing. These are the test cube models set up on end for the left extruder and added a sidewalk and supports on the right extruder.
I have included PLA (lp) ABS (la) and PETG (le) all else being the same.

These should make for simple test parts. The beginning of the supports are well into the print as they are only within the center hole.
If you study the thermal profiles of the two extruders for these 3 different builds, you will see how a simple temp change algo isn't going to do the Cube3 justice when printing with dual extruders. There is a specific heating pattern assigned to each one every time it switches nozzles.

Single extruder prints are much simpler. They just need a bias temperature adjustment and I think this will be common and straight forward.

I'll let you know how that signature signing goes in a minute.

- - - - - - - - - -

Cube3utils (13) had no Norton complaints. Windows defender still warns the first use of an .exe but is easily bypassed (the big purple page). This just seems to warn of 'newness' rather than known issues. This is a mere minor nuisance. Okay, Windows10 itself a nuisance to begin with.

Attachment 3314

Yeah, I am glad that Norton is now not giving you grief. Windows 10, well, you can turn that down, but it makes things less secure from most people's point of view.

This PC is made to 'restore to factory' anytime. Basically a 'Do I want to adopt Win10" ...PC.
Two years on and the answer is still a resounding NO! ...over my Win7Pro for CAD.
Makes for a good eval platform though.
Also keeps stuff out of my CAD PC's registry by testing usefulness on Win10 first.
And it keeps an eye out for current threats with basic protection.
Collaborative development on the other hand is always a challenge on Win10.

...
on another note...
Today was the first time I noticed that some header entries had spaces and some not. Interesting. Had to confirm this has always been the case. It has.

- - - - - - - - - -

And another interesting finding...

I remember seeing ascii text in the beginning of the print files in the past. I wasn't equating their existence properly though. They are in all native Cube print files. This section is a <build> section that really is a record of what settings were passed onto the slicer.

If you look at re-encoded files, this section is not maintained (also not included in the .bfb conversion). It is quite likely one reason the files cannot be loaded back into the app. The other would be a lack of image to display. Basically the data in the index has to be complete for the app to read it and send the file to the printer via WiFi.

The reason I found this interesting is that the decoded file shows material length values where the header in the native print files has a value of zero. That means the slicer did the calculation and provided the encrypted data back to the print file.

The other nifty feature is that the original file name is maintained in the file. That's proven useful more than once.

Where are you seeing spaces in the header entries? Is it in Cube3 Files or CubePro 1.87 files?

I had noticed that the CUBE3 files coming out of the Cube3 slicer were actually a conglomeration of files, that is the reason behind my cubeextract routine. For the Cube3 files, we could easily rebuild the original cube3 file with the modified model, but for the cubepro file, there is another file that seems to be a checksum or crc of the file contents. I didn't dig too deeply into that. I could make it so that when we encode a cube3 file, we encode all of the original parts back together and that would allow the file to be sent over wifi (or so I presume).

As to spaces, I was commenting on my use of Excel to parse the decoded output files. Using space delimiting, I use to see the "0.1925" pop up in its own column... specifically noting it as when you click the field to data length, it displays "0.193" although the entered value is still correct. In these series of files, it didn't separate and I wondered why. So I did some more checking and realized that the separated value came from one of the config files I was working with. That is how I got to looking closer at the headers of the print files. You found the same in a different way of getting there. Now I better understand your file set.

I wouldn't give the CubePro too much mind for now. Don't get me wrong, I am very interested in cracking the 2.02 code but the Cube3 has enough hoops to keep an eye on developments. Basically, CubePro should be simpler on its own. There is no reason not to manually hack a modified Cube3 core into a CubePro wrapper. Visa Versa will require intervention for the heater block bias that Cube3 utilizes. Dual extruder conversion between CubePro and Cube3 will be a very involved as a routine has to be injected on each layer replacing purging, wiping, and heating parameters.

I saw the checksum (crc32 call) but that seems a remnant of the <build> "xml" portion. I wonder if that subroutine was something that flagged the completed file transfer to the slicer.

I like that 'build' concept of reconstructing the whole of the print file. Removing sneaker-net from the equation would be useful. I doubt that the data even needs to match meaning it could be stripped from any .cube3 file. More and more are the Cubify BFB print files looking like what M$ took over with .3MF, just another ZIP format.

WiFi does work for CubePro, but only in that it can read in CubePro files. It can read in Cube3 files but can't send them... logical ambiguity... because only CubePro's are detected on Wifi... or we'd have an answer right there. Maybe you can dig into the CubePro app and figure out how to enable the Cube3 access! I have an idea of where he control is managed in the config files. But if you wander through the CubePro program files, you will see all kinds of Cube3 references including our build plate STL. That access would be so cool! Like a pro version of CubePrint.

- - - - - - - - - -

======================================
Findings in the thermal map for Cube3 profiles using dual extruders:

Fortunately all 3 basic material profiles act the same when printing using dual extruder output.
They go through a strange dance that accounts for overshoots, stable temperature, and hovering temperature updates.

Basically there is a common factor related to all the prints coming from the Cube3 or EKOCYCLE.
The nozzle must purge between every nozzle exchange. Nozzles are exchanged on an every-other layer basis.

While this exchange is made, several operations concerning nozzle temperature is acted upon.
The approximate handshake that goes on is as follows:
1) Prepare the temp of the nozzle to be used next - 190|235|230 (PLA/ABS/EKOCYCLE (petg)) Don't wait for temp.
2) Reduce temp of finished extruder - 145|200|205 Don't wait for temp.
3) Bring up unused extruder to bias temperature - 155|210|215 Don't wait for temp.
4) Bring up temp for nozzle to be used next - 200|245|240 Wait for temp!
5) Continue bringing up temp for nozzle to be used next - 210|260|250 Wait for temp!
6) Print resumes and a hold-up M104 is issued same as the last wait-for-temp - 210|260|250 Don't wait for temp.

There are a few exceptions to these values based on 'first occurrence' of different print types... support, sidewalk, or print.
First layer has a special temperature associated with it for any of the 3 basic layer types.

So it should be simple enough to see these alterations in the Editor. But basically, it shows how the bias temps are managed in Cube3.
There is a 10C offset to get to bias temps and 2 values that set the fixed temp that must be reached before continuing.
The M104/M204 that has a P1 modifier just means that there is no reason to wait for temp. Other platforms use M109/M209 for this.

I need to run a few more scenarios but this is a good start in understanding how to reliably convert one file to another with regard to temperature profiles and bias temps.
If these values remain constant and consistent regardless of which side supports and sidewalks are specified, some standard scripts can manage this easily.
I also need to see how Infinity Rinse is treated. That is a wildcard that may have a few other surprises.

- - - - - - - - - -

...on a whim I decided to check the Infinity Rinse implication on the slicer.
Interesting finding; CubePrint|Cube3 cooks the soluble filament to 245C!
This slicer function held a higher bias temp while PLA for the part was still 210C as expected.
Note: Inf-Rinse has limited valid combinations in the app.

Way cool that the editor manages the temps as it does.
It will certainly lend itself to customizing mixed materials.
Need a reference table to untangle the findings so far but it follows a formula.
The problem is more knowing the input and the exponential configurations each generation spawns.
Thermal configurations alone provides 4 valid and useful options in CubePrint alone.

Thanks Tom! I am going to spend some time looking over the temperature management, but have you seen any issues lately?

Nothing traceable. I'm using a gentle touch on the script though. I'll beat that up some more tomorrow.

Care to post a cheat sheet on the executable's and their command line syntax now that there's a rich set of options?

Any luck on reassembling a file back to an acceptable status to the CubePrint app?

Cube3Edit [<cube file> [<script file>]] -- edit cube files (as we've been doing). Or specify a cube file and a script file and modify the cube3 file based upon the script contents.
Cube3Encoder <BFB file> [<cube file>] -- this takes a BFB file and encodes it into a cube3 file.
Cube3Decoder [-xml] <cube file> [<BFB file>] -- this takes a cube file and decodes into an BFB file, or using the -XML switch, will decode an encoded XML file.
c3sg <cube file> [<script file>] -- this generates a script from a cube3 file.
cbld <folder containing extracted files> -- builds a cube3 file from a set of files.
CubeExtractor <cube file> -- exctracts the contents of a cube3 file.

cbld -- will combine a set of files back into a cube3 file. You probably want to extract the file set using the cube3extractor, modify the cube3 file, then use cbld to combine back to the combined cube3 file. This won't work for cubepro as there is the checksum file that I have yet to decipher.

- - - - - - - - - -

Scratch that. cbld is not working fully. Let me do some work.