Cube3 File Editor

You need Win10 and absolute virgin install of the toolkit. It is like cat experiment thing... its both dead and alive until you look at it. And when you do, it no longer registers as a connected Cubify printer. Touchy as all getout! But I can connect (right side port of course). I've used it. But I break the driver the moment I query it.

Not thrilled being dongle'd to the printer with my laptop. Needs a way around that too ;p

Thing is, 3D Builder is exactly the same slicers* as CubePrint. I've inspected the lot and yep, 3DB is a new front-end for the old slicer. *=outdated allowing rafts.

I have posted a new version of the cubeutils with cube3editor. This new version, when you click "Generate Cube3" will generate the combined file with updated index file and cube3.

I have not tried using the script to generate a file, but the save routine for both UI and command line is the same process. The end file is a little smaller since the included XML file has some of the whitespace removed.

Link to updated files

- - - - - - - - - -

One more thought. This implementation only updates the type, materials and CRC tags. I haven't added any code for support/sidewalks...

Got it. That material matching for supports and sidewalks could be a manual edit in the "RAW BFB". If it was the last thing that kept WiFi from working - because the app couldn't parse the file... well then now you know where to look ;p

Okay, last update for today. :) But there could be more. I modified the RawBFBView to update the in memory BFB with changes that are made in the editor, so no need to save the BFB, encode as a CUBE3. You can make your changes, and then just close the editor and they will be applied automatically. I suppose I should add an apply button so that you can force the changes to be applied and allow changes to be discarded if necessary. That's tomorrow's change. :)

You get it here.

Nice! Yes, that is part of the workflow i cannot see. When things are committed. But that is what is helping me to stumble around in the dark to see what I'd 'like' to do. You certainly caught a glimpse of this in this update. Excellent work!

Okay, here is the Raw BFB Editor with the apply button to allow for live updating.

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

- - - - - - - - - -

Sidewalks and supports can only be set to left or right, not simultaneously. And it gets set to the color on that side. So, if your Extruder1 color is Dark Grey(101) and your Extruder2 is Yellow PLA (85), and support is set to Dark Grey and sidewalk is set to Yellow, then Supports is 101 and Sidewalks is 85.

Yes, the logic is certainly there. And if either or both is -1, those are left alone.

The challenge of course is to know which color was assigned originally to E1 and E2 and lock any changes reliably to the sidewalk/support settings when not -1.

- - - - - - - - - -

Okay, give me a Use-Case that I can throw at this thing... anybody.

The most logical one to pursue is PETG to PLA (EKOCYCLE to CUBE3) as I am really starting to like that slicer a lot more
seeing how it is implemented with more finesse than the PLA slicer. Of course, EKOCYCLE is limited in options. No Infinity rinse; no 70-micron prints; - but everything I print with PETG using this slicers comes out very nice with only a few tweaks! The toolkit is perfect for this type of thing. I appreciate all the work you are putting into this. My goal is to contribute through some characterization of the variety of slicers we do have in BFB format, primarily the various Cubify slicers.

Do any work in Cura?

Interesting. So, I see what you mean about the color. If I change the left extruder color from red to blue and I had sidewalks on for the left extruder, then I will need to update the left extruder color too.... Hmm. Yeah, the logic I see is this:

Code:

---

if I change extruder n color then
  if sidewalks is not -1 and sidewalk color equals extruder n original color then
    update sidewalk color to match extruder n new color
  end if
  if supports is not -1 and supports color equals extruder n original color then
    update supports color to match extruder n new color
  end if
end if

---

I have done a little bit with Cura, but it is a bit overwhelming. Do you have a basic setup for cura?

Yes... correct on the logic. Loop that twice for each extruder and you got it. That's why it is good to use in the color parsing algo.

Cura is missing something I really like in Cubify... a type of internal wall support when the overhand goes negative... say upper hemisphere.
However, Cura has a BFB output with post-processing. Worth noting ;p

- - - - - - - - - -

I am just stumped at how useful this little tool can be. I continued my conversion 'therapy' with a project I am currently working on; a tray for Argentine ant bait.
These little pests are unbelievably prolific. They once found a hummingbird feeder and completely devoured it! Hence my hummingbird feeder trap on Thingiverse.

Well, I have since learned how you must deal with these pests. Something about boric acid at levels under 2% with whatever you can get the ants to come to. Well, I've learned that there is very little these ants won't come to... but certain things help. I've decided that a 1% solution to 49.5% sugar and 49.5% water would produce a bait that will not exceed 2% and is nominally delivered at 1%. My first tests were to fill bottle caps. Unfortunately I've killed a lot of worker-ants that should be bringing the bait back to the hive. With this particular tray, the ants have a much better chance to swarm the tray without drowning. This is kind of like drowning in beer for an alcoholic. A good friend of mine had a pretty good joke about that.

Anyway, I printed 2 of the trays using CubePro v2.02 as a baseline. The Cubepro does a pretty nice job of this piece. One thing Cubepro doesn't do well is make for a solid bottom. You'll see in the images that the fill for the bottom is fairly sparse. I suspect they did this to help with warping but that's just a guess. In my world, I like solid bottoms even if you can see every trace. This baseline makes for very functional parts.

Attachment 3319
300um Cubpro v2.02 print; baseline 1

Next I put the same two models in CubePrint V4.03. I ran them as ABS with sidewalks. Knowing how these print with ABS on the Cube3 will get me the second baseline I need. Needless to say, these two models are still a world apart in similarity. The Cubepro-sliced print is smaller and the details are more 'correct'. The Cube3 print on Cubepro was 'fat' or 'thick'.

I changed the Cube3 file using Buddy's most excellent cubeutils. The temperatures were already current but 'M104' needed to be removed.
I used the editor and went straight for the BFB viewer. I copied the content and removed all and pasted that into notepad. I searched out all the M104's and removed them. Then I re-selected everything and pasted it back in the viewer's UI. Immediately the temperature fields updated to show only 2x M104 present at 0 degrees.

The second part of the modifications required me to understand the settings that Cubepro would use for retractions. I ran these same models in Cubepro v1.87 (different computer) and saw that the retractions were 250 and the two modifiers are 300 and 700. I changed the cube3 file to conform to these values using the editor.

Then I needed headers. I set this all up as a right extruder print as I wanted yellow trays form the Cubepro. This meant I needed a right side 'doner file'. I sliced any-ol'-file using the right extruder only without sidewalks or supports (forcing -1 to these entries) in the Cubepro v1.87 app. Considering these values have no meaning in conversion (slicer and app settings only) this keeps the header simple. I cropped everything between the 'init complete' and the last time-stamp replacing the void with the BFB from the cube3 file in between, cropped similarly.

Long story short, I opened the file in Cubepro v2.02 and it provided the preview expected. I then sent the file onto the printer to be run. The output was one solid puck of Ant Tray! If you want a fast way to get ABS prints to be "thick", this is certainly it!

I am taking another run at these prints this morning. I've decided that I would try backing off the extruder pressure to 75%. There is maybe 7 or 8 entries ranging from 40 down. I ran the script maker and pasted the values in Excel to do the calculations. Since all the numbers were whole numbers, I replaced the values with their rounded whole number value. I also decided to place a tape dot under the z-level switch to get a little more gap out of the first layer. ...the quick way to increase the Cubepro gap.

I am convinced that there is a proper pressure percentage that will get a Cube3 ABS print to look identical on Cubepro. I don't know that the correlation of the existing data is simple as both pressure and velocity work together and the Cubepro profiles are completely different from the Cube3 profiles. However, this percentage-correction should cover all basic for this type of conversion. When I get to the point of getting the final percentage number, I will need a different test model with 'bridges'. I'm just trying to get to a ballpark using this method and being productive at the same time.

Attachment 3318
Cube3 ABS w/ retraction correction applied.

I have long thought on using these pressure changes to make files compatible across platforms. There is no easy way to do this without the help of something like the cubeutils. Now the change is as simple as knowing the conversion factor you want to apply. Just know that some prints only have a few variations... others have many more.

So this is my first go at platform conversion with ABS. As I only run ABS in the Cubepro duo, a full library of conversion will not be published but for anyone trying this for themselves will understand the process and hopefully share their findings as well.

I did run into one bug that was not reproducible, Buddy. I was changing extrusion pressure values in the editor UI and when I got the second-to-last entry, it would not take it nor let me move to the another value. It was acting as if a buffer filled. I exited out of the program and re-opened the file and this time worked the pressures from the bottom up and all worked as expected. Just in case you thought you'd seen this before, this might suggest you actually had. No additional errors were observed in any other operation in this experiment.

Cubepro shortcoming...
Attachment 3320
left: Overextruded cube3 file - right, CubePro v2.02 @300um

- - - - - - - - - -

Seems 75% is a very good number.

Attachment 3321

Very comparable to the Cube3 printed ABS version. The z-level dot alteration helped. The part was still very stuck to the build plate.

Here is a comparison of all three trial pieces:

Attachment 3322
top right; Cubepro v2.02
left; straight conversion Cube3-ABS to Cubepro-ABS
Bottom right; left version with retractions reduced to 75%

- - - - - - - - - -

And if you're still wondering how to merge the walls? Try increasing extruder pressure to say 125% on the Cube3/Ekocycle platform. You might increase the heater block bias temperature by a percentage as well to make sure there is enough melt available.

- - - - - - - - - -

Definitely finding a bug in the extrusion pressure algo. Two means by which this attempt failed and one work-around.

The attached file has a script file and a native Cube3 ABS print file. When I open the file with the cube3editor and import the script (load script), it gives me an apparent 'null' error. ... "[]". However, it does take some of the data and wrongly updates the extrusion pressure data. Basically it replaces the wrong numbers when 2 entries fail; third and forth. Also updated are the retraction values as input with the script. What is unique in this file set is that I am not affecting the temperatures with the script file.

The other bug I noted yesterday is definitely there. You start filling in the extrusion pressures and at some point the 'curser gets stuck'. You can escape out of it but no further editing can resume on other fields. I again edited from the bottom up (lots of entries!) and it worked fine.

Wow, you have been busy. Sorry for my lack of response -- been dealing with trying to get Cura building. :) I am close, but not successful, yet. I will take a look at the extrusion pressure bug you found.

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.

Very nice solution! Norton had a fit trying to run the editor for some reason (Win7). I was able to trust the file and it ran fine.

I'll give those command line options a go today.

The command line options are currently not implemented, but will be for the next update. Also, these options are not currently plumbed in. I was just getting the interface setup and asking for your thoughts.

Aha... Thanks for the heads up :) I'm still working on a very targeted 'circlip'. That will keep me busy today.

And for your viewing and cube editing pleasure... I have plumbed the preferences dialog as well as the command line options.

Option	Description
-pr:[on|off]	Enable or disable original Cube3 file preservation. On: enables preservation Off: disables preservation. If enabled, will add a _MOD_XXXX to the end of the filename. Default: ON
-b:n	Disable or set the number of back files to create. To disable backup file creation, set n to 0. Default: 5
-mt:n	Set the maximum temperature allowed. The minimum value is 0, but the maximum allowed setting is 300. Default: 265
-mc:[on|off]	Enable or disable creating minimum sized Cube3 files. Enabling this option will not allow files to be transmitted to the Cube3 printer over WiFi. Disabling this option allows files to be transmitted to the Cube3 ptiner over WiFi. Default: OFF
-z:[on|off]	Enable or disable allowing temperatures to be set to 0. Default: ON
-help	Display help.

These options will override and update the settings configured from the UI dialog. Default values are from the first run are highlighted in bold above.

Nice!

- - - - - - - - - -

Hey buddybu, hope things are well.

Finally tracked down that material issue I've been having...

Included are two files to do the simple test;
1) open the editor
2) open the each file noting the material color

observation;
The PLA file shows PLA Neon Green correctly (testcube_LP11100.cube3).
The ABS file shows CP_ABS Neon Green incorrectly (testcube_LA11100.cube3)

You will also note that when viewing the BFB, the color code is indeed changed.
Correcting the field in the UI will correct this.
My worries is that a command line operation with Cube3 ABS in the .cube3 file will corrupt it with the incompatible Cubepro color code.

BTW: is that link a few posts back the latest with command line updates wired in?

- - - - - - - - - -

...And yes, the app is opening the re-encrypted file for Wifi submission!
That is a feat in my book any day. Way to go buddybu!

Well, interesting. The code in the decoded BFB for the ABS file is 256, which is CubePro ABS Neon Green. The code for Cube3 ABS Neon green is 141. How did you create the ABS file? Where did you get the number for the color? I got the color codes by creating a Cube3 and CubePro file with that specified each color and material so that I could capture these numbers.

ABS Color	CubePro	Cube3
Teal	260	76
Purple	262	77
Brown	261	78
Silver	263	79
Glow in the dark Green	264	80
Glow in the dark Blue	265	81
Forest Green	267	105
Navy Blue	268	106
Coral	269	107
Dark Grey	270	108
Pale Yellow	271	109
Gold	272	110
Bronze	273	111
Red	252	132
Green	257	133
Blue	258	134
Yellow	255	135
White	250	136
Black	259	137
Tan	254	138
Magenta	251	139
Orange	253	140
Neon Green	256	141
Industrial Grey	266	N/A

Oh, that's kind of my point... the file has 141 in it. Opening the file changed it to 256. So there is a conversion going on somewhere.
Therefore, for PLA, it is not making a change, but for ABS, it convert the value to Cubepro upon opening.
This has been going on since very early. I just couldn't isolate the bug until I noticed that PLA acted normally.

Basically, all CUBE3 (type) converts all ABS to CP_ABS upon opening.

Thanks for the consolidated list BTW :)

- - - - - - - - - -

Here are your other materials;

Ekocycle

300 RED
301 White
302 Black
303 Natural
304 Gray

Cube3

500 Infinity Rinse


Cubepro

501 Infinity Rinse

That should complete the list to the best of my knowledge until you get to Cubepro advanced materials.

Well, that was quite ah, I'll just say you are right and I made a really novice mistake... and you should pull the latest version of the zip file. It is now corrected. Thank you for the Infinity Rinse values. I didn't have those values and they are now implemented. I also added a new feature that shows which sides are empty and disables the ability to select a color. The same is true for Infinity Rinse. If you choose that, you get InfRinse as the color and you can't change it.

:) I have a programming background from, let's say, 'a previous life'. My head is fairly 'calcified' too.

Good that you included the InfRinse protection. It is a really isolated choice in the slicers.
And the protection of empty bay(s) is also a great idea!

Where did you want me to grab the latest ZIP from?

You should be able use the previous link, but here it is:

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

:) Ah calcified. Yeah. I spend my work days learning something new every day about Java. Writing this set of utilities in C# has been keeping me fresh in that arena.

Aha... that link :)
Nice!
Ekocycle seems to be plugged in too now.

Quick programming note - your material type drop-down doesn't contain EKO. You only see it when you load an Ekocycle file.

Is Exit and Close wired in the UI?

I am getting 'unable to save' errors when I try preserving the original file in default preferences. Save-as returns the same error.
No issues when I untick preserve and tick history.
Something is not responding to the error state blocking the overwrite.

- - - - - - - - - -

I do mechanical CAD similarly. Plenty of new features to explore.
Making any headway with Cura?

New version, same URL, but just in case:

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

Close and Exit are now wired up. I also did some clean up on the dropdowns, so that if you select EKO, you only see EKO colors.... :) Same for PLA vs ABS. PLA has "Natural" and ABS does not. Of course, in today's world, Natural would be a no-no, and it would be called Peach or light orange, or light pink, or...

I haven't done a ton with Cura. I got back to work and was immediately swamped with a release coming up in a couple of weeks.

Um, I think natural means unadulterated... No color filler pellets introduced into the hopper.

Hmm...
Attachment 3337

Well, that doesn't look very clear. :) Looks like beige or maybe even egg-shell'ish.

- - - - - - - - - -

So, what you are saying is that Natural is the natural color of the PLA without any color pellets.

- - - - - - - - - -

And I am just being very, ah, tongue-in-cheek here. Not really being very serious. ;)

LOL... Yea I know. But yes, PLA is a fairly translucent clear I thought and ABS is that like ivory but slightly translucent. Some of the nicest ABS I have for statues and figures.

However, we could talk 'nude'... and that's a tough color to find! I had a Hatchbox filament that came close to both opaqueness and color. You want a supplier that can assure a pantone color of choice reliably. And you do want to get a good saturation of color pellets in the hopper to get that excellent opaqueness of 3DS filaments.

Clear is simply another formulation. I really like the translucency of PETG.
https://robosavvy.com/store/media/ca...RNatural_1.jpg

- - - - - - - - - -

And I just ordered PLA today. Should have added that to 'eligible' free shipping ;( ....gotta go put it in the basket.

- - - - - - - - - -

Darn! I am trying to find 3DS' description of the M227 command.

As a further request, I would ask that the script also outputs and reads the last 2 variables on the M227 command.
I know I am asking a lot. This is turning out to be useful.

M227 P%d S%d G%d F%d

P should be reverse feed rate
S should be feed rate (same as M108 Sn?)
G is unique; has relevance in reaction time
F is most likely velocity, same as on G1.

I have found these 4 characteristics defined in an XML somewhere before. I need to keep looking.

You're going to have to come up with a way I can properly thank you for this most excellent effort, Buddy!

Aha;

M227: PrimeSteps		450	375
ReverseSteps		450	375
PrimeExtruder		600	400
ReverseExtruder		800	800
M228 PrimeHoldOff		0	0
ReverseHoldOff		450	375

Still doesn't make sense, but that's what I got.

Oh Interesting.

let me see what I can work up for the G and F parameters. Do you want this in the UI as well as script support? :)

The UI already has these for edit in the second screen. Just the script generator that doesn't have these.

Oh, duh, yes, let the UI read these in through a script.

So, I was using my own tool, gasp, and I found, dun-dun... dun-dun... (jaws music), a BUG! Yes, you heard it here first! It has to do with preserving the original file. It actually will now. :D

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

- - - - - - - - - -

I was looking to break out the P, S, G and F values for the retract start commands. It will look something like:

MODIFY RETRACTSTART XXXX REPLACE PPPP SSSS GGGG FFFF

an example:

MODIFY RETRACTSTART 450 REPLACE 225 225 800 9000

the script generator will still generate the old format:

MODIFY RETRACTSTART 450 BY REPLACE 225

And the script processor will accept both formats, but the original command will leave G and F unchanged.

The adding the new command was fairly quick to add. I will post the update once I do some testing. I will see about also generating the new command.

- - - - - - - - - -

New version posted that will use both formats of the retractstart line. (at least from the load-script case from the UI). I will do more testing, but I thought I would get it out so that others can beat on it too...

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

You Rock Buddy!

- - - - - - - - - -

Crumb... is it this simple...

M227 P%d S%d G%d F%d


M227:
PrimeSteps 450 375 FALSE
ReverseSteps 450 375 FALSE
PrimeExtruder 600 400 FALSE
ReverseExtruder 800 800 TRUE
M228
PrimeHoldOff 0 0 TRUE
ReverseHoldOff 450 375 FALSE

Steps are stepper steps, that's easy... but the "extruder" values should be 'velocity' similar to the F-values on G1 commands.
These two values are not part of a generic offering of GCode M227.

Now to figure out what M228 ReverseHoldOff means.