Shutter Close

181 views
Skip to first unread message

Larry Cluff

unread,
Apr 19, 2016, 11:12:41 PM4/19/16
to mUVe 3D Support Group
I decided to setup the shutter on my printer and it seems to work well. When I click RAMPS Shutter Close or Open, it works great and it also seems to work well during a dry run of a print. One question I have is that when the system boots up, the shutter opens 3/4 of the way up. I'd like it to be closed until I open it manually or until a print starts (to prevent any potential possibility of resin dripping on the lens). I tried to put the close gcode (M280 P2 S0) into the G-code Bootup field in nanodlp, but that doesn't seem to work. Any suggestions?

mUVe 3D Admin

unread,
Apr 20, 2016, 9:02:32 AM4/20/16
to mUVe 3D Support Group
Larry,

There's no real way to control that servo at bootup as the systems are resetting and checking things. Since the power and signal cut out and the processor reboots there's not much you can do about it. Putting the "Shutter Close" GCode in the bootup section is fine but it won't matter much until the system completely boots. So there's always going to be a period of time where the shutter moves around a bit.

The only way around this would be to make the shutter system more expensive and complex. Then we could possibly use a separate servo controller, or we could even use a stepper motor. Neither of those solutions would have the issue, but would cost 5x more and require a lot more wiring, power, etc.

The savior here is the projector protector, which should be installed when you're not printing. If it's always installed when not actively printing then the shutter jitter issue on bootup shouldn't be a problem.

mUVe 3D Support

Dangre

unread,
Apr 20, 2016, 9:31:36 AM4/20/16
to mUVe 3D Support Group
I'm wondering if because during startup the signal to the servo is 'floating' that noise is getting to the servo sending it wrong info?  Would a capacitor to ground filter these signals?  I switched to a cheap digital servo which seems to behave much better and is less susceptible to noise.

Larry Cluff

unread,
Apr 20, 2016, 11:13:37 PM4/20/16
to mUVe 3D Support Group
I'm wondering if this could be solved by having nanodlp modified to have a delay before sending the bootup gcode? Should I log a request?

mUVe 3D Admin

unread,
Apr 21, 2016, 11:57:18 AM4/21/16
to mUVe 3D Support Group
Larry,

The having a delay wouldn't do anything we don't believe. nanoDLP doesn't boot until the RPi and the OS boot since nanoDLP is just a program like any other PC program. So the message to close the shutter is being sent as soon as it's done booting and that's probably a good 10-15 seconds after apply power. The shutter is being reset to the inappropriate location as soon as power is pulled and reapplied, not because of an inappropriate command needing to be delayed.

mUVe 3D Support

Larry Cluff

unread,
Apr 21, 2016, 2:03:34 PM4/21/16
to mUVe 3D Support Group
I was thinking that the G-code bootup field is executed when the nanodlp comes up, but the RAMPS board is not ready to receive the command at that time. Otherwise, I don't understand why the servo wouldn't move to the closed position if the RAMPS board is ready to receive the g-code.  Once I can access the GUI, I can press the "RAMPS Shutter Close" button manually and it closes fine. So the question I am asking myself is why doesn't the nanodlp "G-code bootup" field gcode get executed? If a 15-20 second delay were added to nanodlp before it executes the "G-code bootup" gcode to assure the RAMPS board is ready to accept commands? I don't mind if the servo moves around at startup as long as it ends up in the closed position.

mUVe 3D Admin

unread,
Apr 22, 2016, 8:07:07 AM4/22/16
to mUVe 3D Support Group
Larry,

It should already work, this looks like a nanoDLP bug.

Do you have the Shutter GCode for closing the shutter also entered into the proper field on the settings page? There's a place for those codes now. If entered there it should also close the shutter at bootup as default as well.

Looks like we might have to submit a bug report, but first we need to determine what your setup looks like.

mUVe 3D Support

Larry Cluff

unread,
Apr 22, 2016, 3:59:17 PM4/22/16
to mUVe 3D Support Group
I think so... see attached picture.
2016-04-22 13_53_29-Setup - [mUVe 3D DLP] nanoDLP.png

Larry Cluff

unread,
Apr 22, 2016, 4:07:14 PM4/22/16
to mUVe 3D Support Group
Actually just saw this on nanodlp site for release 1139: "Bugfix: Give RAMPS board some time before sending bootup gcode"

http://www.nanodlp.com/forum/viewtopic.php?id=2

I plan to give this new version a trial. Anything to watch out for?

mUVe 3D Admin

unread,
Apr 23, 2016, 9:09:48 AM4/23/16
to mUVe 3D Support Group
Larry,

Not that we're aware of but unfortunately we haven't tested it yet. We'll let you know if we find any issues, we would appreciate if you could do the same. Best of luck.

mUVe 3D Support

Larry Cluff

unread,
Apr 23, 2016, 3:25:22 PM4/23/16
to mUVe 3D Support Group
Nanodlp build 1140 solves this issue with the shutter. Now to test everything else...
Reply all
Reply to author
Forward
0 new messages