Phrozen Transform gcode Delay Ignored

#1

I started to look into understanding the gcode a bit as I’m not savvy with coding but I can understand the basics. As the title says I have the Transform and wanted to implement to use my gcode for this machine as I had over a year of experience and yes I even use the super fast print speeds but I wanted to control my layer print delays and layer speeds accordingly.

Apparently when I send over the file to the printer with gcode all works fine but G4 P# doesn’t get registered or completely ignores it. I have read several topics here about the gcodes and even tried the ;DELAY# but the printer goes crazy and the LCD either does 0 ms print times or just hangs.

My question comes in the gcode I setup, does it matter what order things are written as? If so having a ;DELAY# or G4 P# before a line item make a difference? I’m constantly testing and want to see where exactly I can add the delay before the LCD turns on. G4 P($SliceNr < 10?5000:1000) is something I would like to do but the printer wont read the G4 regardless of what times I use even if I just use G4 P3000.

;LAYER_START:$SliceNr
;currPos:($SliceNr * $LayerThickness)
M6054 “($SliceNr+1).png”;show Image
G0 Z($ZLiftDistance + ($SliceNr * $LayerThickness)) F($SliceNr < 10?$ZBottomSpeed:$ZLiftSpeed);
G0 Z(($SliceNr+1) * $LayerThickness) F($SliceNr < $BtmLyrs?$ZBottomSpeed:$ZLiftSpeed);
G4 P0; optional extra light delay.
M106 S255;light on
G4 P($SliceNr < $BtmLyrs?$ExTimeBottom:$ExTime);
M106 S0; light off
;LAYER_END

#2

Don’t bother trying to do anything in gcode with the Transform UNLESS you have converted it to NanoDLP (See my tutorial in the Phrozen Transform Facebook group)

The gcode interpreter from Shitu in the standard Phrozen firmware is completely broken.

#3

I think yea this is what I’m starting to think. It seems the Transform did fail with us trying to configure it to our liking.

I also did find your tutorial and I’m having a lot of trouble connecting or recognizing the printers IP. I even tried different memory cards and got your .img but I’m failing to connect it thru SSH on my PC. I’ve been at it for 3 days now but not giving up yet.

I here some use the Mac to connect it… maybe I’ll set it up thru that way and use the PC once it’s connected.

#4

Are you connecting via cable, or WiFi? You need to connect via cable first in order to set up the WiFi

#5

I knew it! I don’t have the printer close enough witch is what was going thru my mind and used WiFi.

#6

Hi,

So first thing about the gcode on the older machines is the extension of the file:
if .phz” ==> the machine will import the run.gcode file and use it instead of the default resin profile
if “.zip” ==> the machine will ignore the run.gcode file and use the build-in resin profile

If i’m correct the machine is based on a PI.
And then probably another controllerboard that handles the axis movement.
It’s not a single board handling all gcode like i.e. in a simple CNC machine with GRBL.

That being said; the G4 is a problem child. You don’t know what the settings are in the chip handling the gcode; and how it handles this and communicates back to the PI. I don’t know either at this point.
The implementation can go different ways.

By coincidence I was working with phrozen last week on some gcode and this came up as well.
I will check back if a solution was found for this.

Elco

#7

@formware I have played around with the Transform extensively, and have even been able to convert it to running NanoDLP on the native hardware. It’s basically a single board machine based on the OrangePi PC and includes the MCU onboard loaded with an extremely badly configured version of GRBL; For example, GRBL can be configured to use only a single axis, but Chitu (not Phrozen) have not configured it to do this, and it actually relies on the the X axis homing erroring to end the homing cycle.

The GCode interpreter is also extremely badly coded (Another Chitu mess), and it exhibits extremely strange behaviour.

Chitu have made such a complete mess of it, that if you want fine grained control of the machine, there’s no point even attempting it with the rubbish Chitu have given Phrozen, it’s far better to just load the latest version of Armbian for the OPi PC on the SD card, and install NanoDLP

BTW, i gained enough of an understanding of the absolutely horrible stock firmware that I wrote a resin calibration file for the machine that many users found very helpful in getting their machines set up.

#8

@formware Indeed it is a bit complicated. I even taken the time to explore how Chitubox exports the gcode and even then it ignores the G4 regardless of what you adjust it to. For some reason the ;DELAY does something to it where it does stop completely or it changes the Bottom Burn Layers to extremely different numbers example: I use 30s Bottom burn layers and it output as 300ms while adding ;DELAY in the gcode. I think @fcollingwood is correct, I dont think you can do much with gcode with this printer. It seems the printer self adjust the file and reads only what the firmware is suppose to do and outputs those settings to print the file.

@fcollingwood after a complete concentration and a full energy drink until 5 am I managed to install NanoDLP and I’m at the stage where I can connect it with Wi-Fif and the NanoDLP web os is showing up. Is there anything special I need to configure or its good to start adjusting settings for printing. I’m not good with coding but I’ve gotten this far already.