You are not logged in.
Pages: 1
I had this happen the other day....something crashed or got stuck due to bad gCode....the lamp just stayed on for hours...not good.
anyway I propose a separate thread that will deactivate the lamp if not touched by the main process for some reasonable max period...or maybe the cure time is
on a separate thread that even if the parsing or gcode fails or something hangs it can reset the serial connection (if needed for RAMPS systems) and shut off the lamp.
I am going to look at my firmware and see if there is a way to do this there but having it both places seem like it could still be good.
Offline
Watchdog in middle would not work well. If nanoDLP crashes anything watching on nanoDLP side would crash too. On light source side, projector and etc go to sleep automatically.
Our best shot is to make sure nanodlp does not crash, if you have gcode sequence which crashed nanodlp. It will be quite helpful to prevent any crash in future.
Offline
Didn't keep the exact code but I think it had to do with comments in lines with calculations...I removed the comments and all was well...
This was just a thought, I concur it should probably be taken care of on the printer side...I am looking into firmware changes for that.
Offline
Pages: 1