You are not logged in.
Pages: 1
I'm trying to commission a prototype DLP, using nanoDLP build 1919 on RPi 3B+. The interface to the external motion controller is working (I'm temporarily using a Duet 3D printer controller) and the projector displays the calibration screens correctly. I am having two issues:
1. I can't seem to generate the calibration plate. I select Plates then click on Generate next to Calibration Plate. I accept the defaults (sometimes I change the plate height but that doesn't make any difference), then I press Generate. A couple of seconds later it returns to the Plates screen. If I then click on the Preview icon, I get what looks like a partial image and a message "This plate is still being processed, the image of some layers is still missing." It doesn't matter how long I wait or switch back to Plates and click on Preview again, the preview doesn't change. The latest message in the Application Log is: "Applying mask file public/plates/mask.png" twice.
2. [possibly related] If I try to print the calibration plate, nanoDLP sends the commands to the external controller, waits for them to complete, then hangs. It doesn't display an image on the projector. The only way I can get out of that is by using Force Stop, whereupon it displays the first (incomplete) later image on the projector, waits for 50 seconds "curing" and then stops.
The disk free space was originally 460Mb, but I used the facility to expands the filestore and it is now 13027Mb. It didn't change the symptom
What am I doing wrong?
Last edited by unladedSwallow (2018-12-05 17:21:58)
Offline
PS - I've also tried generating and printing a very simple image. The preview looks OK and doesn't show the ""This plate is still being processed" message. However, when I try to print it, the behaviour is the same: it homes the printer and under "Layer" shows 1 of 30. But nothing on the projector.
One odd thing is that it also says "The 3D printer is idle. Click on 'Plates' menu to start printing.". But the Plates page shows that the file is printing.
Application log:
Info 1 2018-12-05 13:28:10.530526 Logging Suppressing duplicate logs
Notice 1 2018-12-05 13:28:10.525382 Terminal Received Data From RAMPS: ok
Notice 1 2018-12-05 13:28:10.516588 Terminal Received Data From RAMPS: ok
Notice 1 2018-12-05 13:28:10.514243 Terminal Received Data From RAMPS: ok
Info 1 2018-12-05 13:27:56.681884 RAMPS Sync Waiting for Z_move_comp response from RAMPS
Debug 1 2018-12-05 13:27:56.681769 Gcode Transfering Data M650 D5.0000 S1.0000
M651
G4 P1000
G1 Z0.1
Debug 1 2018-12-05 13:27:56.680875 Gcode Transfering Data M98 P'shutterclose.g'
Debug 1 2018-12-05 13:27:56.680273 Shutter Shutter Close
Debug 1 2018-12-05 13:27:56.680195 Image Clear screen
Notice 1 2018-12-05 13:27:56.679424 Gcode Position set to 0
Debug 1 2018-12-05 13:27:56.679057 Gcode Transfering Data G28
G90
RAMPS terminal:
G28
G90
M98 P"shutterclose.g"
M650 D5.0000 S1.0000
M651
G4 P1000
G1 Z0.1
ok
ok
ok
ok
ok
ok
ok
Last edited by unladedSwallow (2018-12-05 14:45:58)
Offline
Just a thought: does nanoDLP expect any response to the GCode commands it sends other than "ok" ?
Offline
I just tried build 1928 instead of 1919. Both issues are still present: it doesn't generate the calibration plate, and it hangs on the first layer with the projector not displaying anything if I try to print a plate, displaying message "Test 1 The 3D printer is idle. Click on 'Plates' menu to start printing." (Test 1 is the name of the file I am trying to print).
Last edited by unladedSwallow (2018-12-05 16:29:34)
Offline
Here's the latest debug log in case it's helpful: nanodlp.debug.1233349461.zip
I notice that "printer: imageLayer.c:255: destroyImageLayer: Assertion `result == 0' failed" has come up a few times, but I'm not sure if it only happens when I do a restart.
Offline
I just imported an STL and generated a plate from it. It previews perfectly, but when I print it, same thing happens as always: it homes the printer, shows Layer 1, and sits there doing nothing. Application log and terminal log as before. It sent 7 GCode commands to the motion controller, and received 7 "ok" responses. The motion controller debug indicates that it has has no pending commands to execute.
What does nanoDLP wait for before it opens the shutter and puts the layer 1 image on the projector?
Last edited by unladedSwallow (2018-12-05 17:17:29)
Offline
You need patched RAMPS firmware to preserve current settings.
Offline
@Shahin, thanks for replying. However, your reply is not at all helpful because I am not using RAMPS. As I said in my original post, I am using Duet electronics as a prototyping platform, for modern electronics that will be smaller, cheaper, better and much more suited to manufacturing than the ancient and clunky Arduino/RAMPS system. If you are saying that RAMPS is the only external hardware platform that you are prepared to support, then IMO you are being seriously short-sighted.
The firmware that I am using is far more functional and configurable than the patched Marlin that runs on RAMPS, and I am able to make any modification needed. So if nanoDLP needs any response from the electronics other than the standard "ok" response after each command or the standard additional responses to commands such as M114 and M119, please tell me what they are.
Here again is the terminal transcript:
G28
G90
M98 P"shutterclose.g"
M650 D5.0000 S1.0000
M651
G4 P1000
G1 Z0.1
ok
ok
ok
ok
ok
ok
ok
You will see that there are 7 GCode commands sent by nanoDLP, and 7 "ok" responses.
Last edited by unladedSwallow (2018-12-05 22:40:01)
Offline
On RAMPS, OK response being send just after receiving the command and it does _not_ indicate task completion. For movement synchronization Z_move_comp response should be returned from 3rd party board to NanoDLP.
Gcode you are using ask nanodlp to wait for such response from RAMPS/3rd part boards for syncronization.
There are other ways to support synchronization, please check forum as there are couple of posts on this topic.
Offline
Hi, thanks for responding again.
In GCode the "ok" response may or may not indicate completion, depending on the command. Some commands such as G0 and G1 movement commands are buffered, so "ok" only indicates that the command has been accepted, not completed. Many other commands are unbuffered - in particular M400 and G4 - so "ok" is only returned when they have completed. There is a reasonable explanation of this at https://reprap.org/wiki/G-code#Buffering.
The usual way to wait for movement complete in GCode is to send M400. It waits for all movement to complete, and only then returns "ok". For those few firmwares that don't support M400, a G4 command with a short delay parameter accomplishes the same thing.
When I start a print, while the machine is homing Z I see the status in nanoDLP read "Waiting for Z_move_comp response from RAMPS", but when homing is complete it changes to "Received Data From RAMPS: ok". So I didn't think nanoDLP was waiting for Z movement to complete.
However, I've now looked at https://github.com/mUVe3D/Marlin-mUVe1D … n_main.cpp and I see that it has been patched to echo "Z_move_comp" when a G1 command is processed. But it echoes that before the move has completed, not after! So I think that patch (and nanoDLP waiting for that response) is redundant. The G4 P1000 command is sufficient to ensure synchronisation, if nanoDLP waits for the "ok" response to it. The move is only 1 layer height, so it will execute very quickly anyway.
Anyway, I'll patch the firmware we are using to send the "Z_move_comp" response when a G1 command is received
Offline
On the recent builds we are supporting a new keyword called [[ResponseCheck ExpectedOK BufferSize]]
It mainly developed for SLS and laser based SLA systems. But this keyword not tested in production much and I am not confident enough to recommend it for DLP/LCD based printers. If anyway you want to test it you can use it like [[ResponseCheck 1 1]] after commands returning ok response.
Offline
Pages: 1