You are not logged in.
Pages: 1
Build 1220
I prob. have a configuration issue and this makes me unable to do any prints from plates.
All things work seperatly (Z axis movement, Display Calibration images, Send G code commands, Take snapshot from camera)
Nevertheless, when I sliced a STL and made a print-plate and start it), it hangs on the first layer.
Nothing particular is seen in the log, and it's not possible to stop a print (it prompts if I like to stop > yes) then it's back to the same.
This message has been noted though on occation : ActionSkipping db/calibration.json file. stat db/calibration.json: no such file or directory
Debug log:
https://dl.dropboxusercontent.com/u/512 … 965043.zip
PS.
Thanks for adding total number of layers
Regards
Offline
Are you using patched firmware to handle [[WaitForDoneMessage]] command?
Probably it is waiting for response from RAMPS. Try force stop from setup page / tools tab to see if you could stop printing.
Offline
When you say patched firmware, you think of Marlin FW?
I can see in the Terminal that Ramps respond with 'OK'
But is that message not interpreted as [[WaitForDoneMessage]] command?
How do I patch the FW?
Offline
No Z_move_comp response from RAMP is required.
https://github.com/mUVe3D/Marlin-mUVe1DLP-Running
You can find link to patched grbl too, on download page of nanodlp.
Offline
That's to bad ... I did several of my own changes to Marlin FW (like custom M-commands) to update Display and control dimming/onoff of LCD (not using projector).
So I will need port M650 and M651 then?
(Or perhaps port my own commands to this FW).
Offline
I think so. I know muve3d version patched at-least couple of times to work perfectly with nanodlp.
Offline
I successfully ported my commands to the muve3d version of Marlin.
(All my commands work, and I get the response z_move_comp) on z axis movements.
I only need to re-configure my printer-profiles again to verify that it works.
Then I will close this Bug Report.
m
Offline
After many experiments I found that NanoDLPs started prints can't be stopped if [[WaitForDoneMessage]] can't be delivered.
This is not optimal, and force stop from setup page does not help.
I would recommend to check for "Stop" criteria in the [[WaitForDoneMessage]] loop.
Last edited by Kvirre (2016-09-01 07:31:05)
Offline
[[WaitForDoneMessage]] loop is checking force stop command. If it does not work for you, please share debug file.
Offline
Debuglog found in the beginning of the thread
Last edited by Kvirre (2016-09-02 08:41:55)
Offline
Have you tried pressing force stop twice?
Offline
Pages: 1