hi frank,
I have added the extra height/speed variables in the mean time. Also added them in every layer data piece available to me. So i hope that solves the issue.
About to release but i need to double check the ctb files and all other exports, script engines etc. for this. So takes some time. Hope to have it ready on friday.
Resting times. What is the purpose of the resting times? i mean before exposure allowing the resin to settle i can understand. But the other 2?
It’s not just the height and speed variables that need to be in every layer header - It’s pretty much all of the ones I mentioned. Please have a look at https://github.com/fcollingwood/LiberatingMarsCLI - this is what you need to recreate, note that this works perfectly, I have been using it for my commercial prints since I first got my 8Ks
Re. Rest times - even after the UV turns off, there is some residual curing going on. I usually set my rest before lift to 0.5 or so seconds. Rest after lift is purely so that there is a decent slow down, stop and reverse instead of of lift-jerk-reverse.
yes i’m aware what variables there are per layer. It’s in the SDK description. However; one might have assumed these were optional. But probably they are not or the entire thing will return to default values with the latest firmware.
Rest times -> Thanks that makes sense. I will add them.
I’ve just uploaded V1041 to the website.
It has:
All variables visible in the image below are exported to the CTB SDK .ctb format.
The offtime variables are not used anymore in this case; only rest time variables.
Will be adding the other machines that are supported with this next couple of days.
Thanks @formware, I will give this a try when the current prints are complete.
Just to make things clear for me - you have two rows of two boxes for Z lift distance. Intuitively, I would think that the first row is for lift distances and the second row for retract, and the first column is for the slow section, and the second column for fast?
Oh @formware, I see the graphics at the bottom - I assume this changes as the settings are tweaked? If so, that is really great, as there can be no mistaking how the printer behaves. This looks very good indeed, a lot of thought has gone into this.
The only thing I would say is maybe can you reverse the sides the lift and retract data ar on in the graphic? Currently retract is on the left and lift is the right - it would make more sense if lift was on the left and retract on the right
Hi Frank,
I will switch the left/right of the image. You are right. Makes sense to put what’s first on the left. I left out further text description as I think the view was already getting cluttered… for a moment I thought about puting the textboxes on top over the images… but it would make more of a mess…
Perhaps a description for the distances ‘retract/peel’ would make more sense that shows when you activate the two stage motion.
I’ll publish an update later this afternoon. Some important bugfixes in various parts of the code base.
Elco
Hi @formware Elco
Minor bug. in the header, Layer Count Plus One (15th parameter in the encrypted section of the header IIRC) is being set, but Layer Count (61st parameter in the encrypted section IIRC) is not. I’m using v1.0.4.2 downloaded today
Edit: I’ve done a little bit more fault finding and found this:
I’m slicing an object with 35 layers in both Formware and Chitubox.
In Formware, Layer Count Plus One is being set to 35, Layer Count is being set to 0
In Chitubox, Layer Count Plus One is being set to 35, Layer Count is being set to 34
Now I may have the wrong info for the two fields (They may be Layer Count for the 15th parameter and Layer Count - 1 for the 61st, and it certainly looks this way), but it does look like you’re not putting a required value into parameter 61 of the encrypted part of the header
Another problem - the total height of the print is not being written to the relevant (7th) parameter of the encrypted part of the header.
Another problem. The profile is set up like this:
The first stage and second stage lift (light blue and dark blue) are working correctly as set up
The retract is not. Instead of dropping 16mm at 300mm/min and then 4mm at 30mm/min, it is dropping 4mm at 30mm/min, then 16 mm at 300mm/min.
This is on both Bottom and Normal layers
Hi Frank,
I do notice that when I open my sliced file in chitubox it first shows 1 layer more in the layer slider; but this corrects as you inspect a layer. So this seems to be something in CTB UI.
Where do you inspect these values you are talking about (as they are not my variable names, neither are they from CTB) ? (are you sure this software is flawless?)
As a background; i’m not putting any value on a certain location in the file. I’m just assigning 1 total value of the amount of layers to a parameters. I have no idea where the CTB SDK writes that to. (and how many places it writes to).
The other item with the lift distances i will check for the 4th time… last time I checked the files where the exact same. Maybe something changed or it’s a combination of settings; I don’t know. I have to assume that the descriptions in the CTB SDK are accurate… (of which speed/distance variable is which)… they are not descriptive of which part they are.
Elco
Regarding the speeds and distances.
I tested the following: took a 4mm cube, setup the slicing settings like in your profile. (bottom equal to normal layers)
Then I reload the file and inspect which variables i get:
The ‘Movement’ variables is what it’s about.
The naming convention is the one from CTB.
Basically everything which it denoted with a ‘2’ is the ‘fast’ movement.
Also the layer height variables by default are the sum of the slow+fast part.
The other variable has to be only the ‘fast’ part. (both up and down).
I’ve double checked again the SDK descriptions in their code and PDF manual of the SDK and this is consistent in naming with the ‘2’.
When I do the same setup with chitubox and load the file:
This looks to me as the exact same movement variables.
Iv’e also checked the individual layer variables in our debugger but they are also similar. (derived from the global variables)
To summerize I tested:
Slice FW -> CTB SDK save as .ctb -> CTB SDK read as .ctb -> view file info
Slice CTB -> CTB SDK read as .ctb -> view file info
So don’t really know at this point where it goes wrong…
Perhaps slice a simple cube in both your configurations and send me the files?
For completeness the profiles used:
@formware Hi Elco, you’ve definitely got the retract transposed (And your Chitubox settings in your example are incorrect - see the post below this one). This is a file sliced in Chitubox:
And here are the Chitubox settings:
This is the same file sliced in Formware, with the same settings:
And here are the Formware settings:
Now if I print the file, the one sliced in Chitubox behaves as expected. However the one sliced with Formware doesn’t - The first part of the retract is 4mm at 30mm/min, the second part is 16mm at 300mm/min.
BTW, my Chitubox settings are correct, yours are incorrect, see the images below.
Not only does the file I sliced in Chitubox behave as expected, but here is the Chitubox documentation regarding two stage (retract only shown, as lift works correctly in Formware):
Regarding layer counts and total height, they’re not a biggie. I’ve hacked my Mariner3D file handler to deal with them correctly. Strange that they are set by Chitubox, but not exposed in the SDK.
Hi Frank,
Thanks a lot for the clarification. That screenshot of your settings helps a lot as it verifies what the machine does.
I found the problem (and it’s not my fault this time 
) ;
it’s the SDK documentation that is wrong at several places
Just for reference of variable naming, this is the CTB SDK code from CTB (their comments):
This is the CTB SDK pdf documentation:
You can see that:
bottomLayerLiftHeight2 -> both of them say it’s fast section, that’s OK.
normalLayerLiftHeight2 -> both of them say it’s fast, thats OK
normalLayerDropHeight2 -> fast vs slow -> so this is wrong.
bottomLayerDropHeight2 -> fast and fast -> _probably this is double wrong then in both docs? as you would assume now that the ‘2’ in the downward movement is the ‘slow’ part every time. _
normalLayerDropSpeed2 / bottomLayerDropSpeed2 -> this is both fast and denoted as slow in the docs.
i’ll fix them asap and test with your CTB settings.
Elco
I’ve fixed the issue. I’ll publish a fix in 1-2 days. Need to finish some other bugs.
Just some other thing I noticed; that adds to the confusion.
If in CTB you use a printer without two stage motion; you have to leave the right column 0.
But that means that the meaning of the left column retract (drop) part changes. Now this is not anymore the fast part, but the slow part… just to add to the overal confusion.
@formware Great, thanks Elco. I’ve worked around it for now by swapping the settings. It works, but it doesn’t look great.
BTW, if you are able to share the SDK documentation with me, I can cross reference it with the info I have regarding the de-encrypted header and possibly come up with more suggestions for fields to use
Hi Frank,
Yeah of course, you could just swap them…
No i’m not allowed to share the documentation… it’s NDA’d
What I shared above in variable naming is I think strictly speaking also not allowed… but for sake of discussion and fixing their problems (of which they benefit if we report it) I think no problem.
Elco
I got my 8K just a couple of days ago, and have printed only a few test figures…
(OK, I only printed the chess piece, then went basolutely bananas…)
Then I printed a pair of ‘White Hare’ miniatures from Moonlight Minis, and all seemed well…
Today It printed the rest of the minis from that set(Alice and the ‘March Hare’), and when I got back home I started the usual cleanup and wash and so on…
Weird… Capital letters on the end of the name tag on the base?
(The minis have integral bases and the names embossed on them)
Every one of them has been mirrored.
The Printer Profile may need a ‘Flip slices in Y direction’
