-
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.
