nanoDLP

Glacian22

Member

Registered: 2017-01-23

Posts: 4

Weird pausing/communication issue...

I'm running a pretty basic bottom up, single axis DLP printer, and installed added an Pi with Nanodlp recently to control the RAMPS board. Installation of everything was easy enough, and the web interface works nicely...except that it'll just disappear on occasion. As in, when I try to load up the IP address in a browser nothing will come up, and this usually lasts a minute or so before it suddenly reappears.

And worse, this shows up in printing as well...at least I think it's the same issue? Once I got my gcode set up the way I wanted it, I tried running some test prints. They'll work perfectly for a while until suddenly the printer freezes for a few seconds, and then everything is off. As in, if it freezes during a lift section, the lift stops dead, and then when the printer continues the position is off.

Any ideas? I've attached the debug zip. nanodlp.debug.-956800959.zip

*EDIT* I tried pinging the Pi at a time when the nanodlp interface refused to load, and the ping worked fine...not sure what that tells us though

*EDIT 2* It sounds pretty similar to this wifi power saving feature issue (https://discourse.osmc.tv/t/pi-3-wifi-unstable/14171) so I'll try their fix and report back if that solves the issue

*EDIT 3* Solved! The link in edit 2 had a fix for the wifi powersaving timeout issue, and my printer losing position during those events was tied to my new TMC2100 stepper driver running too hot and shutting off (vref lowered to .9 as measured by multimeter).

Last edited by Glacian22 (2017-04-22 09:00:16)

Shahin

Administrator

Registered: 2016-02-17

Posts: 3,541

Re: Weird pausing/communication issue...

You need kind of mechanism to synchronize movements with nanoDLP. One way is to use delay keyword but your formula return 0 for some layers. Another way is Z_move_comp//WaitForDoneMessage.
Outside of that I do not see anything abnormal.

Glacian22

Member

Registered: 2017-01-23

Posts: 4

Re: Weird pausing/communication issue...

Thanks for taking a look Shahin. With the formula I was running, it was designed to add an extra 6 second delay to the first 115 layers, and then no extra delay after that, because I had "Wait after lift" set at 9 seconds. Correct me if I'm getting this wrong, but the idea was that for the first 115 layers, the delay between exposures to allow for lift cycling would be 15 seconds (9+6), and then drop down to just 9 seconds. Does that work correctly? And is there a specific benefit to using WaitForDoneMessage instead?  Thanks!

Last edited by Glacian22 (2017-04-22 05:57:00)

Shahin

Administrator

Registered: 2016-02-17

Posts: 3,541

Re: Weird pausing/communication issue...

You need to give enough time for RAMPS to move down to printing position. By using delay after lift you could not do that.

WaitForDoneMessage automatically sync movements and you would not experience any unnecessary delay.