I doubt the new switches were implemented from the lists I've already submitted here.
I am now looking at Cura to get a flavor for what it takes to get our script out.
I was hoping that Axon would make things a lot easier just by being simpler to start with.
Within an hour I was finding what I needed in Cura.
I already looked at the code and saw that we need to reroute a lot of the newer routines/commands/whatever you call the M-things.
We just need to get a good setting for velocity, feed, retracts.
I am not sure that Cura will let you invent switches though... which we appear to need on the retract; G and F.
In simple words, 3DS BFB files are archaic!
But we can glean the machines and extruder profiles by zeroing in on the output result.
I am pretty certain that the G and F code is some kind of dwell and velocy settings specifically after it lands (from experiments).
These can be mimiced at the appropriate time, which is every M101/M103 instance.
What I need to find is if Cura lets you edit the assigned code for each option. I found the BitForBytes BFB "style" and it does pretty well.
However, Cura insists on using its interpretation. It seems you have to go through a 3rd party plugin to do further processing.
I'm already doing that in notepad. Excel would do quick work of the "adjustment" if that is the right route.
The other side of the work is characterizing the Cube3 in all it's modes... That's 8-factorial on the face of it; then confirm the color/material list.
So here you need an end game.
You either admit that the Cube3 slicer isn't that bad and just hack at the decoded BFB or wholesale replace models from other slicers.
The retract, z-drop, change in "modes" (min layer time in the slicer for instance), all the various scripts for nozzle changes, the standard layer change routine...
Again, I know you've already noticed this... 3D Systems has managed this with their printer with an insanely small command set! I am actually impressed by their slicer. Problem is the lack of buttons to tickle it. 3DS basically said "You Can't Touch This!" ...apparently since Axon 3 by what you've foundAnd I appreciate that!
I should be able to use Cura to do enough to slice good models for my personal preferences. Do some global replacements in the gcode output and be good to go for a header and footer addition. I just need good triggers for the search and replace to catch the details that 3DS has put in there for success.
I have to do all this anyway because my next printer will be the MP Select Mini V3. I will certainly use what I'm learning by picking this code apart.
- - - - - - - - - -
- - - - - - - - - -
Interesting... a bit of time on the Ultimaker forum and it is pretty clear Cura is not designed to simply write what you need in a gcode file.
However, I did find where the command lines managed.
Here's how I see it so far:
Cura's input is rate of speed (time based) and it converts the data to stepper steps. Which means somewhere these is a distance/steps calculation.
We need to backtrack the equivalency to the Cube3. Shouldn't be too hard. We just don't know what the maximum functional speed of the Cube3 is.
Cura uses M104 and M109 for "temp" and "temp/wait" respectively. 3DS uses M104 Sn P1 as M104 (easy conversion) and M104 Sn for M109 (also easy)
The tricky one is the retract.
Cura uses M227 Pnnn Snnn where 3DS uses M227 Pnnn Snnn Gnnn Fnnn. The Gnnn and Fnnn will need to be a new line with whatever function these provide.
M228 has no option in Cura where 3DS for some silly reason adds the Snnn that matches the M227 Snnn value. Again, easy conversion.
Now I understand why people were looking for specific Cube3 information. That should be simple.
Stepper motors, basic stepper motors have a 200-positions per revolution ignoring microstepping.
Metric belt drive pitch is easily found. So whatever the pitch diameter of the gears are, divide that by 200 (x/y/z, 2000 for filament driver for the /10)
So now we know that we need to back-annotate the step values to MM in Cura's machine configs.
We only need to get a few values to match. A complete list will help us to focus on setup files.
One interesting things going all the way back to the advent of BFB is the what seems to be backwards from all other code development...
They start with a description and convert that to a code... where normally, people develop code and assign definitions.
This is strange, but knowing this you have a better insight to what you find the 3DS driver DLL files.
I have found an outline of the command descriptions used almost universally in BFB/GCODE.
I suggest focusing on one profile and getting to know all aspects. I've already begun with single left extruder ABS.
I'm quickly becoming intimately familiar with the way the Cube3 slicer deals with it.
I am aware of the data gleaned from the 3DS DLL files and how they answer some questions (not many... but very helpful when you zero in on machine specific data).
I already saw one thing 3DS did better than Cura on the face of it... If you watch what the Cura slicer does you will see that solid layers are just back-and forth zigzags.
3DS takes the time to sidestep before returning making all the traces parallel. Yes, that is a sign of quality implementation.
Cura probably has this option somewhere too.
Am I looking at Simplify3D being a similar animal as Cura in this regard?
And yes, I also confirmed that post processing is pretty much what I was doing with notepad. This can be done inside Cura. What's better, it can do scripts.
I suspect that we will need to write the script to make automate this process function.
I need to make and analyse some of the Cura files to understand how typical slicing happens outside the 3DS universe.