-
Well CubePro v2.02 still does not decode properly. I get some real output and some odd output...
Code:
^JLP0TUWgSoNrP84mJ2.8qeY
^PrinterModel:CUBEPRO
^Firmware:V2.00
^Minfirmware:V2.0
^ForceMinfirmware:V1.14B
^DRM:000000000000
^ConfigAndConfiguration:No-
^MaterialCodeE1:202
^MaterialCodeE2:-1
^MaterialCodeE3:-1
^MaterialLengthE1:10561.2
^MaterialLengthE2:0.0
^MaterialLengthE3:0.0
^ExtruderTypeE1:0
^ExtruderTypeE2:0
^ExtruderTypeE3:0
^ModelHeight:64.00
^LayerCount:320
^LayerHeight:0.2000
^Supports:-1
^Sidewalks:202
^Density:Strong
^Pattern:Cross
^Time: 97
G50
?;?j????????E????i??????????#u??Q?l??t?bu#??R?&?e?Rm??
?LLh??t?]U?%?|?V??g?????
g?q-?!u?zT??#??.????cH?T?? ?nM[*"???? U8?????%?U??u?G
The rest of the file looks like the end, so they did something else or encrypted the remainder of the file.... with something else.
-
Yes they did the bums! But not their .xml config files. No one has dug into that from what I've found. I've tested all the previous versions of CubePro only to find v1.87 to be the latest that is supported by previous decoders.
-
It almost looks like a simple cipher, since there are some patterns in decoded data.
- - - - - - - - - -
CCubeArchive3DB
- Get3DBArchive
- SetInputXML
- Request3DBInfoBuffer
- Request3DBInfoBufferSize
- ReadCube3DBFile
- Create3DBArchive
- Destroy3DBArchive
Not seeing anything obvious in the decoder yet...
-
'Simple he says...' :rolleyes:
- - - - - - - - - -
Let me see if I am understanding the process the editor is using when using the command line;
The editor is dependent on the .cubescr file to match the .cube3 file in entries.
Somehow the .cubescr file is an index file tied to the .cube3 file where every entry has indexes tied to them.
If index entries are missing or extra in the .cubescr file, the command line will fail.
Is this a proper way of thinking the file-set related to the cube3editor.exe?
-
The CUBESCR doesn/t necessarily need to match the CUBE3 file.
If you specify that you want to replace a temperature of 250 with 235 and your current CUBE3 file does not contain an entry for 250, then nothing happens. If this is causing the command line usage to fail, then that is a bug.
I think what we need is maybe a better way to describe the changes we want to see in the CUBE file based upon the script. I am thinking possibly adding a range possibility?
Code:
modify temperature left range 250:265 by percentage 25
This would take any temperature between 250 and 265, inclusively, and decrease them by 25%
The same mechanism could be used for retractions and pressure as well.
The other thing we could do would be to add an if statement capability:
Code:
if left material is PLA then
modify temperature left range 250:265 by percentage 25
modify retraction range 375:400 by percentage 50
modify pressure 800 by replace 400
end if
The if statement may be a little more difficult to implement, but I could try.
-
Understood. I am seeing errors but wasn't sure why. I will continue testing with this premise.
- - - - - - - - - -
I had considered some alternative means to present the data.
What I see as helpful at the moment, and may require the least effort, is to read in the .cubescr file into an active cube3editor session.
-
Can you talk more about this? I am working on an update to generate, view/edit the script. I have the automatic generation, but I haven't started the editor portion.
-
I like the cube3editor.exe interface as a "catch-all" confirmation prior to pulling the trigger on file creation.
It allows opening a .cube3 file and extracts the unique data we are interested in.
What I am proposing is that you can then read in a .cubescr file to match the "from" data of the read file and replacing the "to" data from the file in the appropriate fields.
-
I think I understand. What you want me to do is to read in the script, and populate the various temperature, extrusion and pressure fields with the data that matches the existing fields. Interesting idea. Let me see if I can accomplish that. I am still working on my code signing certificate.
-
-
2 Attachment(s)
Alrighty then... TommyDee's 1st use-case for BuddyBo's toolkit
Aim:
Generate a CubePro file to compare slicers.
Slicers:
CubePro v1.87
CubePrint 4.03
Printers:
CubeProDuo v2.02
CUBE3 v1.14B
I've been printing a lot of PLA shipping caps for ReCube Light. I wanted to see how I could print the same quality on CubePro using ABS.
I needed a baseline for all three prints. Turns out the Cube3 slicers is very boring using PLA. 2 heat settings and 2 retract settings.
I decided to slice the shipping cap using the EKOCYCLE settings (offline printer); no sidewalks or supports.
It was wild to see all the precision retracts and velocity iterations I am use to seeing only in CubePro files.
This explains a lot about why EKOCYCLE makes such nice prints.
My next baseline was this shipping cap sliced with CubePro v1.87. I tried to align the start points but failed. But the results are valid.
I went and printed this baseline print. I am using ABS. And it warped horribly.
And of course the other shortcomings of the CubePro slicer mostly due to a wall-offset setting and incremental infills.
But as usual, precise! Always "within bounds". That seemed to be the mantra for the CubePro developers.
I should back up here and say some things about the toolkit usage.
First of all, the c3sg.exe... or Cube3 Script Generator is outstanding! A quick overview of what a file contains. No fuss, just data!
That is how I could see how busy the retracts were. Cube3 PLA.. light duty; CubePro ABS middle of the road; and EKOCYCLE was vast!
One concern I had was the starting gap in EKOCYCLE being 0.32... which is over and above the dialed in gap.
So I made some files and started looking at how to get the EKCYCLE file to print on CubePro.
Now the Cube3Decoder.exe came in handy. I needed a matching set of headers and footers to try and make as much sense of the file as possible.
So I decoded the cubepro version and noted some overall data patterns.
I stripped everything between init complete and the M103 at the end of the print.
...finding that the filament retract settings were 250 and 100, I stayed with these in the EKOCYCLE conversion...
Which was now being changed in the .cubescr file generated with c3sg.exe.
Retracts of 375 went to 250 and 300(?) went to 100. Temps that were ranged above 220 were fixed at 260 for 3DS ABS.
I didn't need to change the other elements as the header and footer would be stripped.
I did try to change extruder 2 to 0. That failed! But not by warning... only by checking the file with another c3sg operation.
As another most excellent feature with the toolkit is the command line capabilities of the Cube3Editor.exe.
This program will do a mass cleanup of your file based on an input file we just edited.
A simple batch file made it easy to run the command line without trying to type long filenames.
Once run, your original input file is updated to the values of contained in the input file (.cubescr).
Now I should add "should change" as this Beta adopter is still is still learning the ropes.
BUG REPORT; can't change M204 to 0 :p
Normally you would not do this. This is a unique area in Cube3/EKOCYCLE; They use a shared heater block that maintains a bias temperature.
Not so for CubePro. In fact, CubePro just makes sure all are off in the footer. Therefore, I needed to strip all the M204 lines from the file.
So now I have a file with a CubePro header and footer that matches the required settings from the EKOCYCLE print.
And I have the modified .cube3 file that was modified using the command line option (batch file) and the script file (cubescr).
I open the cubepro text file; decode the .cube3 file; open the new .BFB file and strip out the header/footer/ and M204 lines.
Select everything and paste it in the cubepro file between the header and footer.
Save the file and drag-n-drop it on the toolbox's Cube3Encoder.exe. And out pops another cube3 file. Rename that and open it in CubePro v1.87.
...Use CubePro to send the file to the printer.
And the results were absolutely AMAZING! NO WARP; PERFECT STICK; GOOD DETAIL; AND A PERFECT SEAM!
- - - - - - - - - -
Top is CubeProv1.87
Bottom is EKOCYCLE on CubePro
Attachment 3309
Top is EKOCYCLE on CubePro
Bottom is CubePro v1.87
Note the ghosting on the inside of the CubePro print.
Attachment 3310
Although this is a super-simple sample, it does show how closely aligned EKOCYCLE and CubePro are in slicer performance.
-
Wow, very nice. I am in progress of letting you load up a model, then generate or load up a script to have the script applied to the currently loaded model. This seems to be working.
My next goal, is to allow edits to the script to be applied to the in memory model. I haven't started on that feature yet. I may modify the command line to Cube3Editor to allow you generate a new script after applying the provided script to the provided model:
Code:
cube3editor input.cube3 input.cubescr new_script.cubescr
or
Code:
cube3editor input.cube3 input.scr -os=newscript.cubesr
But holy buckets, you are doing things with these utilities I did not expect and wowzer, that difference.
I can remove the check for 0 and to allow it, but not less :) Maybe if you try a replace with -1 on the temperature -- if the calculated value is less than 0, I set it to zero.
- - - - - - - - - -
New version added. https://drive.google.com/open?id=1gd...mhQ_f28-DhOI6e
- CTRL-O will open the file dialog to load a model
- CTRL-G will generate a script from the loaded model
- CTRL-L will open the file dialog to load a script
- View Script button to show the currently loaded script in an editor.
- Save button will save the script in the editor
- Font button will display a font dialog to set the font you like
- Checkbox to apply any changes to the script to the in memory model (applied when dialog is closed)
- Generate Script button will use the current model and generate the script from it (same as C3SG).
- Script can then be viewed/edited in the Script Viewer dialog.
Let me know what you find. I have added some error checking to not allow certain things if you haven't loaded a model, for example.
- - - - - - - - - -
Oh, yeah, I still don't have an official code signing certificate -- trying to get my private key...
-
I'll see if this new set works later today.
Quick comment on the command line proposals...
I am not sure why the two .cubescr files in the command line. The editor is already parsing the 'default' .cubescr so it shouldn't need a unique reference.
That could just be the way I am seeing it but somehow it is not clicking in my brain.
You realize you have the makings of a product if you simply wrap the content in a UI.
There are refinements that can go far beyond this if you include specialized recognition routines related to the various "layer types" (#vector calls).
Bottom line; your efforts here are phenomenal for Cubify series print file manipulation. I am both in awe and deeply appreciative of your efforts.
I don't have an issue with manually removing the extra M204 lines... in other instances it will be the M104 lines when the right side is used. But yes, setting them to 0 should work without issue.
I also think that 'previewing' a custom .cubescr in the editor dialog is just a good 'preview' of the expected print file. It also lends itself to developing a recipe library system for command line processing based on an individual user's preferences.
Looking forward to checking out this latest release.
-
With the current version, you supply a cube model and script and out pops a new version of the cube model, right? I was thinking that maybe you could output an updated version of the script based upon the changes applied to the model by the input script. Maybe that's silly.
I just had another thought of a new command to allow you to delete lines, maybe something like
Code:
delete temperature right 250
This would remove M204 lines that have a temperature of 250. or it could be specified to be remove them all
Code:
delete temperature right
This same logic could be applied to retractions and pressures (if you so desired).
But yeah, adding support to display the various later types -- hunting for #vector calls, and allowing some modification of those.
-
I'd leave it alone for now as this is only applicable for conversion between cube3 and cubepro. Complete replacement of specific header and footer data will get involved anyway so that wiping in the bins and multi-color swaps are handled properly. That will only get more complicated as this moves forward.
I think the command line option for cube3editor.exe can easily use two options; one is a turnkey batch file operation that spits out a usable .cube3 file based on the specified .cubescr file; the second is to open the editor with the specified .cube3 file and the settings according to a specified .cubescr file. This could be as simple as using a command line switch to determine which operation your desire such as /v for verbose (open the editor interface) or /s for silent mode.
For now, concentrating the apps to tweak Cube3 will go a long way towards understanding cross-platform integration considering its unique and highly refined processes. I suspect that integrating things like Cura would be of greater interest where dual color options would require injecting specific cells into the BFB to deal with wiping and purging. I still have a lot of work to do to understand these unique operations in both Cube3 and CubePro. Dual color printing is way cool but only involves less than 1% of my printing related tasks. Right now I am only trying to get an idea of how to get my perfect single color Cube3 prints to translate to CubePro effectively. Your tools makes this much simpler than previous attempts.
The one "recipe" I would like to hone in on is the conversion from EKOCYCLE to Cube3 PLA. This should be simple as I only need to figure out how the bias temperatures change. Some of the settings are simply housekeeping operations and mean little to the print. My peeve with regard to Cube3 is how temperatures can overheat PLA within nozzles. This risks carbon contamination. And considering our extruder tips basically are the cost of a cartridge, keeping them healthy is important. Obviously I don't run abrasive filaments either ;p
I should ask you as well... what is your most coveted use-case for the toolbox? Do you deploy infinity rinse materials? Do you do a lot of dual color printing?
I want to make sure my testing efforts supports your end goal as well.
-
I don't really have a strong purpose. I am primarily printing PLA, but would like to try PETG at some point. I may try some ABS as I have some samples floating around that I would like to use up. And I want to find an easier way to swap colors without pulling the connector out of the print head -- something like a midline connection that I can expose the filament and cut it there. I don't know if you have anything like that already. I am just looking at printing miniatures for gaming, or replacement parts for games, stuff around the house, etc. I may get into doing larger things and projects, but I am nowhere experienced enough at this point. I am happy supporting your goal at this point.
-
1 Attachment(s)
I can certainly help with a system where you can open up the line without removing the nozzle. That is the entire purpose of the universal hub... or Back to Basics concept (B2B). The only reason it is not found on Thingiverse is the making of the groove in a bowden tube appears to be too much effort. That I can send you in an envelope!
Basically, the B2B system allows the nozzle to remain in place for all filament management operations including changing filament mid-print. There are only two caveats; one) you don't trigger the "nozzle present switch" in the hotend and two) resuming requires the same chip as when you paused. Think of it, no more gapping either! This upgrade alone made the Cube3 highly reliable alongside Lokbuild w/ glue slurry techniques.
3rd party ABS in Cube3 benefits from using the EKOCYCLE slicer. Short of changing a few retraction settings, the PETG profile for EKOCYCLE is a perfect substitute for the 3DS ABS slicer. on Cube3. Of course, PETG works equivalently well using this technique.
For actual 3DS ABS, their default recipe works well. Again, adjust the retraction settings a little is optional but does help. Basically 3DS settings runs about 10C hotter than most ABS is comfortable with. Truly a unique blend. 3rd party ABS tends to 'spit' for no reason. Similar to moisture contamination but not. It actually comes from the default retraction operation adding air to the nozzle and a melt that is already too hot. This 'spitting' is heard as 'plosives' or 'pops' during printing and leaves little holes all over your print. I once thought this was moisture but learned eventually that was not the case having recovered several 3rd party ABS materials to make excellent prints.
You might also like my 'multi-color' option... Pre-loading short lengths of filament in a long bowden tube and let them print in the order they are stacked. Makes for interesting prints.
I can honestly say that these past 2 years have been a very productive and useful in bringing out the best of these machines. Efforts like yours only enhance the experience further. I cannot thank you enough with regard to the effort you are providing for print file manipulation. You have already succeeded in providing the most comprehensive tool set to date.
Is your location 'Earth' somewhere in the vicinity of USA?
- - - - - - - - - -
And Norton isn't happy with the last batch either :p
This is what it -didn't- delete by default: (EDIT: resolved)
Attachment 3312
...not sure what causes this. This time I could simply restore as I did in an early version. This time was not marked for permanent deletion.
I did try the 'duplicate but different' analogy but that made no apparent difference when I deleted the last stable version (11). I will now proceed with (12)...
- - - - - - - - - -
Dude! You've nailed it! This editor interface is simply fabulous!
I get it now... 'raw BFB' is actually 'in memory'. That is how my CAD operates... on a whole other level until you commit by saving.
And as I overlooked completely but find excellent as well... the save script can easily save quick tweaks to the recipe.
Okay, next step on testing will be 'development of common recipes'... or 'how to quickly change EKOCYCLE prints to Cube3 ABS and PLA prints'.
- - - - - - - - - -
...one thought; what's the best way to report system errors or 'strange occurrences'?
A couple of things keep showing up, and I am certain it is operator error, is a 'point of commitment' to any current data space.
Now that I can go wild with ways to 'input' data that it appears the data gets confused and the output data is not what one thought it would be.
Of course, that is the whole idea of testing... and coming up with repeatable events likely and bizarre can be tricky to document.
One distinct area I am seeing anomalies is the header section which can easily be due to the delay between two field entries converted to one data entry.
The second is an anomaly in the right side extruder temps.
Specifically I saw two things with repeated 'data swapping' to try to tune a recipe (.cubescr). Somehow, after saving/overwrite the .cubescr file lost a few left side temperature entries. Similarly, the header data was not changing when it was expected to be in output file but showed correctly on the UI. The former is likely a timing event where data was committed and later changed again but now had missing indexes; the ladder is likely due to how and when the material code is parsed.
I will throw some more mud onto the canvas and see what develops with some shortcut script files. If anything above sounds familiar, you now have a target.
-
Ugh. So, it doesn't like the DLLs. Weird. They are signed along with the exes with my test digital certificate. I am still working on getting my purchased one -- it seems I screwed up when I first signed up, you have to do it all from Firefox or IE, you can't use Chrome. I used Chrome. But it was nowhere on their site to use Firefox or IE, now I am in the weekend and have to "reissue" the certificate.... Ugh.
- - - - - - - - - -
Yeah, I only tested the additional changes briefly. I think I need to do a "refactor" on the code. I have been pasting features with only a high level architecture in mind. With the changes that I have been making, the architecture is getting more concrete, but the code is not able to keep up. Let me see if I can see what you are seeing. I do know that if you make changes to the BFB, they are not reflected in the in memory model -- I hadn't plumbed that feature in. If you have a few steps I could follow, with maybe a sample model and script, that might help me track down the issues.
For the B2B, I would like to try and build the tool that you had designed for creating the grooves. i am about to print it and see what I can do with it.
-
Understood. Yes, there are a few logical issues that can be forced. I don't know how many idiot-proofing routines you care to write.
I figured you were still patching bits of code. I'll be nice to the interface for now.
I'm making headway into seeing how temperatures are managed with multi-materials. It should come out to a pretty simple matrix.
I just need to run lots of samples to see if anything changes out of the blue.
If you have trouble with the groove tool, let me know and I'll mail you a couple of tubes. The least I could do.
-
So let start a list of scenarios and the description of each.
Scenario 1: Model manipulation with Cube3Edit UI
In this scenario, a model is loaded, and the user modifies the various fields by hand, adjusts the temperatures, retractions and pressures. Once these have been changed as desired, the model is saved.
Expected behavior: if User reloads the model, the changes made are persistent and match the values before it was saved.
Scenario 2: Script generation with Cube3Edit UI
In this scenario, the model is loaded and the user generates a script from the model. The script editor is used to change some of the fields, the script is saved and the changes applied when the script editor is closed. The model is saved once the script editor is closed.
Expected behavior: The script, after saving, should contain the changes that the user made. The model, if reloaded, should have the changes made from the application of the script.
Scenario 3: Load Model, Load Generic Script using Cube3Edit UI
In this scenario, the user loads a model, then loads a script to make specific changes to the model, such as extrusion temperature, etc. The changes should be applied to the model upon loading the script. The model is then saved.
Expected behavior: When the script is loaded, the changes prescribed by the script are made to the in memory model and are reflected in the UI. After the model is saved, a reload of the model should show that the changes persist.
There are tons more with just the Editor. What else can you think of?
Some other features could and should be, when loading a new model, the current in memory, BFB, Script, pressures, temps, retractions, materials, etc should all be reset.
-
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
-
2 Attachment(s)
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.
-
Don't let me distract you from what you were doing.
-
1 Attachment(s)
Attachment 3317
This is what I have been doing -- printing a combine for my brother-in-law farmer. :)
-
-
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...
