Cube3 File Editor

No worries, Buddy. I know you are doing great works with regard to our little cubes. BTW; the testing was on Win7Pro.

To continue on the Cubepro conversion. I got a surprise when I tried stopping a print and the plate just kept going up into the limit switch.
I figured that changed some things and it did. Needed more gap-dots! Lesson learned; don't cancel a job when the "glue applied" button is pushed.

So now I am at 2 dots for casual contact to the build plate for native Cubepro files and 3 dots for converted Cube3 files. Dots are blue tape dots that I am using the alter the initial gap for Cubepro prints. Zero dots is now pretty much flush gap.

So with 3 dots I got back to the casual contact I expect for my prints. the initial gap between the Cube3 and the Cubepro v2.02 are apparently different. 3 dots worked for the Cubepro print but it came apart once removed form the plate.

Attachment 3324
Left; Cube3 conversion - Right; Cubepro native 3-dots.

However, I did learn something about the two slicers that I find intriguing. I have been trying to force Cubepro to print more walls. But it doesn't like to do that. I am sure it is the settings I am using but the one thing that is becoming very clear is that Cubepro would rather fill a layer than add more walls. This is what creates the rougher surfaces and odd patterns on Cubepro prints. Since this is a thin part, these infills are easily seen in the print as there is only 1 wall thickness in that region. Lesson learned; use a minimum of 3 walls when making organic parts. Better yet, use the Cube3 slicer and Buddy's most excellent tools :)

Attachment 3325
Bottom; Cube3 converted - Top; Cubepro native

These are the kind of things I am learning about the difference between Cube3 and Cubepro.
And I still find the Cube3/EKOCYCLE to be much further refined than the Cubepro. However, the Cubepro just runs prints parts without too much fuss.

I did loose a wrench in there somewhere though. I was tightening that Z-limit switch and lost a 2mm hex wrench. It got sucked up under the bottom plate never to be seen again. You might consider a drop cloth on the bottom of the Cubepro when using tools.

Since i don't have a CubePro, although I could have access to one, I am not too worried. Will you have to take apart your cubepro to get it out? I am close on the fixes for the pressure changes -- this same issue would have affected the temps and retractions, so I am reworking the entire set.

- - - - - - - - - -

BTW, is that an original iPOD in the lower portion of the last picture? :D

Oh, I am aware of the tangent that the Cubepro throws into this conversion battle. I am doing the Cubepro for some simple understanding of the two slicers. Please pay it little attention as this is something I am doing to increase the usability of the Cubepro. All I would like to get out of this effort is to get Cubepro to print what I get out of Cube3 with ABS. I like the Cube3 slicer a lot more with the exception of not accessing the larger variety of options the Cubepro slicer makes available. Getting the reverse out of it, say make a v1.87 file work similarly on Cube3 is kinda moot as the slicer is way to conservative. However, highly selective modifications can be made to remove the offending infill sections. This is what I like about the 3DS BFB format, they are wholly stand alone sections where other slicers are highly dependent on system settings being specified once until changed.

I also haven't given up on modifying the config files for both printers.

Yea, that's an ol' 80gb iPod. Lost the hard drive with iTunes and could never restore the thing with all my old data so it is just a music player with a huge playlist. Funny thing is, I uploaded it to Android and Android pretty much saved the entire set of media data in a usable format. Go figure!

Good you located the bug. I know I was seeing something like this earlier but that was using the command line getting exception errors. Using the editor showed me where to look for mismatches.

The wrench is on the very bottom of the printer so I am not worried about live circuits. I'll need to tip the printer on its side to get to it. I'm not one to volunteer wielding this 100# monster around on a whim. Someday I will need to remove it from its perch. Hopefully I'll remember there is a wrench in the works.

Now where was I... oh yea, converting PETG to PLA on Cube3 with a command line. Wait... no... making mods to merge a two-trace wall... that sounds more useful! ABS or PLA? PLA!

I have posted a new version that should fix the problem. Your test case now passes. Take a look.

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

I've been trying to get that wall-merge thing to work. Interesting. I could double the extrusion pressure but the heat buildup was too great. I went to 125% and still had heat issues. Basically, it maximized the 'blob' at the seam.

Looks like I will be looking into the blob some more. I have a feeling that the 2 modifiers on the retract command manages this.

- - - - - - - - - -

I've created another unhandled exception for you Buddy. I made the original .cube3 file read only. Maybe this fault solution is to write a new file with *.mod.cube3.

I like this option as I can keep a master file to experiment with rather than re-exporting it every time. It is taking some time to get use to the original being overwritten but I do appreciate the implications on a turnkey operation.

Quote:

---

Originally Posted by TommyDee

I've created another unhandled exception for you Buddy. I made the original .cube3 file read only. Maybe this fault solution is to write a new file with *.mod.cube3.

I like this option as I can keep a master file to experiment with rather than re-exporting it every time. It is taking some time to get use to the original being overwritten but I do appreciate the implications on a turnkey operation.

---

Yeah, I figured that would appear sooner or later. So, let me post another option:

original.cube3
original_nnn.cube3

where nnn will increment as you save it, starting with 001, 002, etc.

Sure, that I am use to also. I was leaning to an exit for the fault condition. The user would purposefully protect their original file and therefore the default correction mode is to create a new file. This new file would become the current file in memory and can be overwritten at will now. That way, by default, if you just want to make a quick tweak to an exported .cube3 file, you don't generate a lot of clutter either. But developers can have a robust method to maintain their test originals with a simple tick in properties. Its pretty much what I am doing with testing... keeping an ORG file on the side and copying it to the work-space. A lot of renaming though.

Which reminds me... if you do "saveAs"... does that make the memory-workfile the new filename to which subsequent saves go to? That might work just as well!

- - - - - - - - - -

Bug report... saved BFB files have no LF's that Notepad recognizes... [but this forum does! :p]

Attachment 3328

- - - - - - - - - -

Bug report: The "Load Script" in the editor is not loading the M227 values on the retracts. M228 does update.

findings: when you use the view script, it shows the read script but the view BFB still shows the values as the UI shows the original values.

Pressures updated correctly.
Temp changes still ignores zero values in the script. Also 'replace with zero' in the UI doesn't do anything. Only add 'minus the value' works.

I'm on the latest "v15"

Thank you for the bug reports! Keep them coming.

I added some further exception handling. I don't know if I covered all of the bases, but there is more.
I modified the save process to automatically add a _MOD to the end of the filename, thereby preserving the original file.
I modified the filebackup process to use a file format of filename_mod_XXXX.cube3. It will only keep the last 5 latest files around and will continue to increment.
The save BFB and Script now add carriage return/line feed to lines.
I modified the code to add the currently loaded file in the titlebar of the UI. This makes it clear what file is in memory.

I am beginning to see some settings come about with what you want to do.

1. Preserve original cube file.
2. If preserving original file, text to add to the end of the original filename.
3. Enable backups
4. Number of backups to keep
5. Allow 0 to be set as a temperature.
6. Remove extra data from CUBE3 file when saving (this would need an asterisk or warning that the file will not be able to be sent over WiFi if you do this)

Any other options you might want to see? I would likely make these command line options as well.

I took note of the bugs and will get them fixed soon. I assume that M227 is your highest priority?

- - - - - - - - - -

Oh, yeah, new build:

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

- - - - - - - - - -

One further update tonight (almost this morning :)). I corrected the M227 issue.

- - - - - - - - - -

Okay, last update for tonight. I just fixed the temperature issue you discovered. For the other bug comments above between the M227 and the temperature, was that all evidence for the M227 issue you found?

Thanks Buddy. These look like great solutions. Yep, M227 was just being overlooked in the import.

M227/M228 is where opportunity exists. It is where the blob is managed. Properly tuned, you should be able to pull away from your part and no drool comes out of the nozzle. I saw this in printing a 70 micron print that allowed each layer to cool due to its small size. That is where I am trying to get for 200um prints. This is one of those that should have a simple routine to adds a final tweak to all files of certain types.

On the UI; I am finding little value in the temperature change options. Basic use of simply changing the temp is probably more than sufficient.

You basically have 3 UI's right now. My initial vision had to do with an overall "multiplier" in the temperature UI rather than options on each field. Basically, you would apply a 80% to all values or reduce all values by 10% as a single button that would affect the set rather than individual values. As I am learning about the temperature profiles, these options may not be overly useful on temperature profiles. Their temperature profiles are fairly fixed for specific functions by the slicer. What would be useful with applying an overall calculation to is the M108 pressure values. These I am taking outside using the script and converting them en mass with Excel to re-enter them in the UI or the script.

On another note; Yesterday I did another ant tray set converted to Cubepro. Turns out 75-80% of M108 values works just about perfectly for conversion. Also using 250 for 450 and 200 for 400 for M227/M228 along with modifyers of 300/700 respectively. The only thing I noticed in earlier prints was that the part fan turns on much later in the print. One has to add an M106 somewhere.

Excellent work Buddy! I would put my suggestions on low heat as I know you are working Cube3 on many fronts. I put these observations here in case you are also seeing some of this as well.

New version posted

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

This sets the default configuration of the modification type field to "Replace".

- - - - - - - - - -

I updated the zip file again. I am in the process of generating a preferences dialog to set some values. Please let me know what you think. You can find it under Edit->Preferences.

The command line will use the preferences last saved. I am thinking of allowing them to be overridden with command line options:

-pr:[on|off] preserve original cube file On or Off. If not specified, will use last saved preference from UI.
-b:n create backups of n > 0 (-b:5). Disable if n is 0 (-b:0). If not specified, will use last saved preference from UI.
-z:[on|off] enable zero temperatures On or Off. If not specified, will use last save preferenced from UI.
-max:n.m sets maximum temperature to n.m. If not specified, will use last saved preference from UI.
-mc:[on|off] enables(on) or disables(off) minimizing the cube3 file size. If not specified, will use last saved preference from UI.