You are not logged in.
Pages: 1
NanoDLP is unreliable at setting exposure time specially if you add a delay to the shutter code (like needed for slow 4K display on Pi3b+)
Please add a variable [[ExposureTime]] to allow users to pass the NanoDLP generated layer exposure (static or dynamic) to a G4 P[[ExposureTime]] command and sync with [[WaitForDoneMessage]]
Offline
All variables being calculated in realtime, cure time being calculated in middle of before/after code boxes get processed. So it is not possible to access it. (eg. you want to get cure time by calling external script which measure sensor and etc)
Shutter calls are async and should not affect printing at all. Could you share the issue details we may could solve the underlying issue.
Offline
- If the Exposure time is calculated during shutter then why can't the variable be accessed there?
Using pi3 as a 4K display means that the image takes about 1 to 2s to be displayed, the only way to make sure the image is correctly displayed is to delay the shutter in order for the image to load.
Even if i add the same delay after i have mesured the time and it is not reliable always shows less time.
IMO The LED ON time should be delegated to the real time microprocessor for reliability. What i want to do is to access the calculated variable on shutter and pass that argument as a dwell to the micro and do a waitfordone message to sync
Here is the implemented code, and here is the patched version of GRBL i'm using: https://github. com/opensourcemanufacturing/grbl-NanoDLP-Patched (Phenom Defaults)
----
Boot
$X; Unlock GRBL
G92 Z[[CurrentPosition]] Y0 X0; recover current position from NanoDLP and set it in GRBL
M5; LEDs OFF
Shutdown
$X; Unlock GRBL
G91; Put GRBL in relative move
G1 Z50 F100; Bring the platform above the resin level
G4 P0.1; (Dwell 0.1s) Request Z_move_ok
[[WaitForDoneMessage]]
G90; Put GRBL in absolute mode
M9; Stop Fans
Start print
$X; Unlock GRBL
G91; Put GRBL in relative
[JS]
feed = 80
zmove = 20
gcode = "G1" + " Z"+zmove + " F"+feed
if ([[CurrentPosition]]<380){ output=gcode }
[/JS]
G4 P0.1; (Dwell 0.1s) Request Z_move_ok
[[WaitForDoneMessage]]
G90; Put GRBL in absolute mode
$H; Home GRBL
G4 P0.1; (Dwell 0.1s) Request Z_move_ok
[[WaitForDoneMessage]]
[[PositionSet 1]]; Set the current position as 1mm in NanoDLP
G92 X0 Y0 Z1; Set our new homed position as the origin
G4 P0.1; (Dwell 0.1s) Request Z_move_ok
[[WaitForDoneMessage]]
M8; Start fans
Resume Print
$X; Unlock GRBL
G90; Put positioning in absolute mode
G92 Z[[CurrentPosition]] Y0 X0; System crashed so we need to recover current position from NanoDLP and set it in GRBL
G1 Z[[LayerPosition]] F100; Move to layer position
G4 P0.1; (Dwell 0.1s) Request Z_move_ok
[[WaitForDoneMessage]]
M8; Start fans
Stop Print
$X; Unlock GRBL
G91; Put GRBL in relative move
G1 Z50 F100; Bring the platform above the resin level
G4 P0.1; (Dwell 0.1s) Request Z_move_ok
[[WaitForDoneMessage]]
G90; Put GRBL in absolute mode
M9; Stop Fans
M5; LEDs OFF
Manual Move
G1 Z[[Position]] F100;
Shutter Open
[[Delay 2]]; Raspi3 4K needs a bit to show image
M4; LEDs ON
[[Delay 4]]; Raspi3 4K needs a bit to show image
Shutter Close
M5; LEDs OFF
Code Before Layer
G1 Z[[LayerPosition]] F[[ZSpeed]] ; Move to the correct layer height
G4 P0.1; (Dwell 0.1s) Request Z_move_ok
[[WaitForDoneMessage]]
[[PositionSet [[LayerPosition]]]] ; Save the current position in NanoDLP
Code After Layer
G1 Z{[[LayerPosition]]+[[ZLiftDistance]]} F[[ZSpeed]] ; Lift to wait position
G4 P0.1; (Dwell 0.1s) Request Z_move_ok
[[WaitForDoneMessage]]
[[PositionChange [[ZLiftDistance]]]] ; Again update position
Offline
You are right 4K (specially monochrome) is slow on pi3.
I have done many optimization which was overdue for a year or two in past couple of days, it should bring down delay for 4K (hopefully) below 100ms. Could you try the latest beta and give me feedback. I think not much left to optimize on the software side to speed up image display with the latest changes.
Regarding shutter it is more complicated. Let me explain what happening now.
- Before layer gcode
- Shutter open (on different cpu thread)
- Display frame
- Wait for cure time
- Close frame
- Shutter close (on different cpu thread)
- After layer gcode
I do understand what you want to achieve, but consider all printers are not LED based. We need to find more general solution. Anyway will add new functionality if we could not sort it out.
I guess one of the things that may improve the issue is to swap two actions below:
- Shutter open (on different cpu thread)
- Display frame
To:
- Display frame
- Shutter open (on different cpu thread)
So GPU delay does considered before shutter command send out.
Offline
Pages: 1