Phrozen version

derekC · 2021-03-08 18:25:12 UTC

Hi, I’m looking to buy this software, but have noticed Phrozen have their own version, does anyone know what the difference is, I own a Phrozen printer by the way.

formware · 2021-03-09 09:10:55 UTC

Hi Derek,

Yes that’s correct we supply various OEM versions to the market.
The OEM license versions are usually included with the printers. (for the higher end machines at least)

An OEM license is a ‘commercial license’ in that you can use it for commercial activity.
The support goes over the OEM.
The machine/print profiles are mostly available in the OEM version only. Phrozen offers theirs as well in our installer. They are maintained by the OEM themselves.
Some OEM’s choose to hide certain functionality that is not needed or have some slight changes in settings.

Hope this answers your question.

kind regards,
Elco

derekC · 2021-03-09 15:25:58 UTC

Many Thanks Elco,

I have realized that Phrozen give away their software version with the higher end machines, mine is a Mighty so it falls out of that category. I’ve been playing with your version and the Phrozen version and they both give the same results and as you say they both have the Phrozen resin profiles are in yours.

I noticed that my machine in your version is a beta version, do you know when that will be a steady state version?

another quick question, can you look at the G-CODE that is created to make the print, I’m assuming the .ctb since that is what is put into the printer. I’m curious to see the makeup as I am an NC Programmer, programming 26 axis machine tools for wing production.

Regards

Derek

formware · 2021-03-09 15:58:03 UTC

Hi Derek,

Interesting to hear I’ve been watching a lot of CNC tutorials/movies lately.

The .ctb format doesn’t have any GCode usage. You can load the .ctb file (load printjob form the menu) and then view it’s properties to see what is inside the file header as variables.

Basically all ‘lower’ end of the market printers that use i.e. chituboard hardware and basic LCD screens dont’ have a GCode (NC) interpreter. They use fixed implemented algoritms to move 1 axis.

The more expensive Phrozen machines do have the ability to use the GCode…

Elco

derekC · 2021-03-09 18:13:17 UTC

Thankyou Elco,

Derek

fcollingwood · 2021-03-10 06:26:55 UTC

Elco, I have to disagree with you here.

The commented header statements in the run.gcode file included in the .ctb OVERIDES the default settings of the machine.I have proved this by unpacking a .ctb file using uv3dp, editing the header in run.gcode and repacking the file and running the print. I am able to override the default slow section height of 7mm, amongst other things. I know what the default settings of the machine are, as I have extracted them from the machine. BTW, I have a LOT of experience with Chitu boards, and know them well

This is why I have created my own profile for the Mighty 4K instead of using yours. However, I have opened a bug report, as Formware is still not writing the run.gcode file correctly in the .ctb file as per my custom gcode.

formware · 2021-03-10 08:12:47 UTC

Hi,

So just to be clear; you are talking about the binary format from the chituboards? (.ctb?)

To be exact when you are using uv3dp you are refereing to this format:

github.com

ezrec/uv3dp/blob/master/ctb/format.go

//
// Copyright (c) 2020 Jason S. McMullan <jason.mcmullan@gmail.com>
//

package ctb

import (
	"fmt"
	"image"
	"io/ioutil"
	"math/rand"
	"sort"
	"time"

	"encoding/binary"

	"github.com/go-restruct/restruct"
	"github.com/spf13/pflag"

	"github.com/ezrec/uv3dp"

This file has been truncated. show original

I can’t seem to find any gcode information of what sort in this format.
There are only variables for all movements?

Elco

fcollingwood · 2021-03-10 08:25:50 UTC

Hi Elco.

No. I have installed uv3dp on a Debian VM (You must also install Go). With it I am able to convert the v3 .ctb that the Mighty 4K uses to a zip file. The zip file contains the layer image .png files, the preview .png files and the run.gcode file. I can unzip the zip file, edit the run.gcode file, zip it back up and convert it back to a .ctb using uv3dp. I can then observe when running the print that the changes I have made have taken effect.

For example, the commented header that Formware produces in the run.gcode is incorrect, as per my bug post earlier today. I can fix this manually using the above and then the .ctb works as it should, overriding the default settings that Phrozen have set in the printer firmware at the factory

formware · 2021-03-10 08:30:05 UTC

Hi,

Yes i was just reading your other post.
Just to be clear; the .CTB format is a binary format. It does not contain GCode. See the source link I provide you. So a ‘comment’ in gcode makes no difference in the binary .CTB file. Even a command like G0 Z05, it’s not in there.

The fact that you use uv3dp to convert files back and forth makes no sense to me for this reason. Unless of course you want to manipulate the PNG images.

Can’t you change the parameters in the uv3dp app without the double conversion?
So my question would be which parameters (exposure/movement) are wrongly defined in our export?

Elco

fcollingwood · 2021-03-10 08:41:27 UTC

uv3dp uses the header of the gcode file in the zip to create the .ctb headers when converting zip to ctb, and uses the header values of the ctb to create the header of the run.gcode when converting from ctb to zip.

As the Mighty 4K has a few internal issues (like when told to move at 30mm/min, it actually moves at 20mm/min), I’m seeking to force the machine to behave as it should via the calculations in the gcode. However, Formware is not taking any notice of the calculations whatsoever.

Even Chitubox (The Chitu slicer) has a gcode section for the Mighty 4K to allow fine control, which is converted to ctb headers. But I don’t want to use chitubox for anything.

The reason why I have to convert from Formware ctb to zip using uv3dp and back again, is that while no gcodfe is stored in the ctb files, the ctb headers are set by the gcode header in the zip file.

BTW, the Phrozen Transform phz is merely a zip file containing exactly the same contents as a ctb converted to a zip by uv3dp - Slice images, two preview images and a run.gcode file.

fcollingwood · 2021-03-10 08:44:30 UTC

BTW, you are looking at the wrong file. You need to look at this one to see how the gcode header maps to the ctb header:

github.com

ezrec/uv3dp/blob/master/czip/format.go

//
// Copyright (c) 2020 Jason S. McMullan <jason.mcmullan@gmail.com>
//

package czip

import (
	"archive/zip"
	"bufio"
	"bytes"
	"errors"
	"fmt"
	"image"
	"image/png"
	"io"
	"io/ioutil"
	"reflect"
	"strconv"
	"strings"
	"time"

This file has been truncated. show original

The czipConfig construct lists the run.gcode header variables.

If Formware can pull these (calculated) values from the gcode definition in the slice setup instead of direct from the resin profile movement and exposure tab, that would be great

formware · 2021-03-10 08:53:45 UTC

The file you are referencing to creates a .zip archive that includes .png images (line 248) and run.gcode as a text file (line 283).

So if your printer can read that (there are older types of chituboards combinations that apparently can) then this is of course more powerful to use.
But then you are not using .ctb files. You are using .zip files to send to your machine?

Btw, the phrozen profiles on our system are managed by Phrozen themselves. So my guess is the reason the gcode is not 100% ok is because it’s not being used by the .ctb file…

The parameters on the other hand is strange and something i would need to check if you think it’s off or missing.

Elco

formware · 2021-03-10 08:55:38 UTC

Now a short reply to your previous answer.

I think i’m understanding what you are trying to do.
You want to have scripting control over what is outputted to the CTB file per layer?

fcollingwood · 2021-03-10 09:05:25 UTC

I showed you the czip file so you can see how the header of the gcode:

;fileName:ResinXP2-ValidationMatrix_200701.stl
;machineType:Phrozen Sonic Mighty 4K
;estimatedPrintTime:1601
;volume:1.651
;resin:Siraya Fast - 40 Micron
;weight:1.6514
;price:0.0826
;layerHeight:0.04
;resolutionX:3840
;resolutionY:2400
;machineX:199.68
;machineY:124.8
;machineZ:1.4
;projectType:mirror_LCD
;normalExposureTime:3.1
;bottomLayExposureTime:3.1
;bottomLayerExposureTime:3.1
;normalDropSpeed:450
;normalLayerLiftHeight:20
;zSlowUpDistance:5
;normalLayerLiftSpeed:42
;bottomLayCount:5
;bottomLayerCount:5
;mirror:1
;totalLayer:35
;bottomLayerLiftHeight:20
;bottomLayerLiftSpeed:42
;bottomLightOffTime:25.5333333333333
;lightOffTime:25.5333333333333

is mapped to/from the internal header of the ctb file:

cfg := czipConfig{
MachineType: machine,
EstimatedPrintTime: float32(uv3dp.PrintDuration(printable) / time.Second),
Volume: 0.0,
Resin: “default”,
Weight: 0.0,
Price: 0.0,
LayerHeight: size.LayerHeight,
ResolutionX: size.X,
ResolutionY: size.Y,
MachineX: size.Millimeter.X,
MachineY: size.Millimeter.Y,
MachineZ: printable.LayerZ(size.Layers - 1),
ProjectType: “mirror_LCD”,
NormalExposureTime: exp.LightOnTime,
LightOffTime: exp.LightOffTime,
BottomLightOffTime: bot.LightOffTime,
BottomLayExposureTime: bot.LightOnTime,
BottomLayerExposureTime: bot.LightOnTime,
NormalDropSpeed: exp.RetractSpeed,
NormalLayerLiftHeight: exp.LiftHeight,
ZSlowUpDistance: exp.RetractHeight,
NormalLayerLiftSpeed: exp.LiftSpeed,
BottomLayCount: bot_count,
BottomLayerCount: bot_count,
Mirror: 1,
TotalLayer: size.Layers,
BottomLayerLiftHeight: bot.LiftHeight,
BottomLayerLiftSpeed: bot.LiftSpeed,
}

I have a particular problem with my Mighty 4Ks where the ctb produced by Formware is NOT using the calculations from the gcode header I have defined when it writes the values to the ctb header. So I have to convert the Formware ctb to a zip file, edit the header of the gcode file, then convert back to ctb to get the machine to behave how I need it to behave. This is extremely frustrating.

Like I said, I am NOT using the profiles supplied with Formware, I have made my own. So I am not using the Phrozen profiles.

What needs to happen is that Formware needs to use the calculated header values from the gcode job start definition:

fileName:$FirstPartName
;machineType:Phrozen Sonic Mighty 4K
;estimatedPrintTime:$PrintTimeEstimate
;volume:$VolumeMl
;resin:$ProfileName
;weight:$Weight
;price:$Price
;layerHeight:$LayerThickness
;resolutionX:3840
;resolutionY:2400
;machineX:199.68
;machineY:124.8
;machineZ:($SliceCount * $LayerThickness)
;projectType:mirror_LCD
;normalExposureTime:$ExpTimeSeconds
;bottomLayExposureTime:$ExpTimeBottomSeconds
;bottomLayerExposureTime:$ExpTimeBottomSeconds
;normalDropSpeed:$ZRetractSpeed
;normalLayerLiftHeight:$ZLiftDistance
;zSlowUpDistance:5
;normalLayerLiftSpeed:($ZLiftSpeed * 1.4)
;bottomLayCount:$BtmLyrs
;bottomLayerCount:$BtmLyrs
;mirror:1
;totalLayer:$SliceCount
;bottomLayerLiftHeight:$ZLiftDistance
;bottomLayerLiftSpeed:($ZBottomSpeed * 1.4)
;bottomLightOffTime:(((60/$ZBottomSpeed)*5) + ((60/$ZRetractSpeed)*($ZLiftDistance - 5)) + ((60/($ZRetractSpeed*0.5))*($ZLiftDistance - 3)) + ((60/$ZBottomSpeed)*3) + 3)
;lightOffTime:(((60/$ZLiftSpeed)j*5) + ((60/$ZRetractSpeed)*($ZLiftDistance - 5)) + ((60/($ZRetractSpeed*0.5))*($ZLiftDistance - 3)) + ((60/$ZLiftSpeed)*3) + 3)
;START_GCODE_BEGIN
G21;
G90;
M106 S0;
G28 Z0;

;START_GCODE_END

for the ctb header variables instead of using the values direct from the movement and exposure tab