nanoDLP

Almost all of the encoders which I have seen were auto-correcting transparently. Could you share a link to popular one which require change on nanodlp side?

For SLA type printers there are many more worries regarding resin choice, vat release, projector calibration which play a far greater role in accuracy than Zlayer height. Any chinese stepper with a half decent linear unit can easily satisfy Z axis needs.

I have not experienced skipped steps with my printer yet. So I agree with Adam, it is probably least of concerns with SLA printers and encoder would not add much. But we are going to use same code (nanodlp) for our CNC project, so having encoder support could be really helpful.

I totally agree with backXslash about Z accuracy, it is very important for fine resolution printing. But if you make a good rigid mechanical construction and use a quality ballscrew with minimal backlash, you will achieve the same result.

My goal isn't strictly about skipped steps or anything like that, it's about repeatability and ease of accurate set up.

Encoder support allows NanoDLP to tune and monitor the Z-Axis movement in real time, and automatically calculate steps per mm among other things.

I had to trial and error my Z-Axis to find the correct steps per mm, and I'm still not satisfied I got it 100% correct. Granted, the error is something like 0.05mm over 50mm, so.... not the HUGEST deal, but it's still avoidable with an encoder.

More than that, micro stepping introduces repeatability errors. It may allow you to move in smaller steps, but those steps aren't always the same size, they just average out to be correct over a certain scale. That's not a huge deal when we're talking about 100mm objects, but when we're looking at say 10mm objects it CAN be a big deal.

All I'm saying is this - it can't hurt, it can only help. Shahin didn't write NanoDLP because there was other, more adequate software available. He did it because he's obviously not the kind of guy to settle for mediocrity, for whom "just enough" is enough. Why settle for the way everyone else does things when we can rise above and deliver a more feature rich versatile and flexible platform that's future forward, not mired in the status quo?

In short, support encoders, they'll support you!

Last edited by backXslash (2016-05-31 12:50:25)

Any chance there's been any headway on the encoder support?

I think I've got a real problem with my Z-axis, but it's cause I have no idea what the lead screw actually is, so I can't really find the "sweet spot" of repeatable or ideal layer heights.

Also, I'd really just like feedback from the system so that errors over time or distance can be corrected and accounted for.

I think good news is coming regarding encoder support  , check this : http://tropical-labs.com/index.php/mech … comment-53
they are running a kickstarter now . all hardware & software is open source and arduino compatible !

Good to know it supports i2c, probably compatibility with nanodlp will be easy.

Ok, all my hardware arrived, and I've got the code almost completely worked out. The board I made keeps track of the current position of the Z axis and will report it when queried. It also accepts a home command to zero the current position at the start of a print.

I used a highly developed quadrature encoder library from PJRC while developing which (I think) simply counts clicks and reports that, so the last thing I need is to code the conversion from clicks to mm and we're good to go!

If I can get a good enough idea of workflow, or find a library that will do step and dir signals, I may convert the board to a full closed loop controller. I'm thinking that because NanoDLP basically just parrots the GCode you put in the box out to a specified serial port, I can instead custom code my own pared down command set and then allow the controller to handle making sure the axis "got there" before firing off the movement sync message to NanoDLP.

Thoughts? Suggestions? The hardware cost for this project has been very minimal, and if there's any interest, I'd be happy to publish to GitHub or something.

Working on it. NanoDLP isn't set up for encoders yet, so.... I'm not sure how to integrate the two without just completely offloading everything to a separate board.

If you had time, I'd love to get your input on it. The "system" is under active development on my bench...

Not sure about absolute position using the AS5306, but the encoder library I've been using certainly appears to function as if it IS absolute. The code I've written so far requires that you home the system before movement commences, if you want it to be accurate anyway. Really, it's not exactly tolerant, or even user friendly, but it IS functional!

It takes a few set commands, the most useful one being "seek [location]". It evaluates the current position, decides which direction to move it, and then pulses the stepper by one full step pulse. The pulsing continues until the desired position is reached. This doesn't take into account desired speed, nor does it account for positions that your axis simply can't hit.

It's important to note that in order to effectively use this code, you have to know how far your axis is going to move in a single full step. This determines the base multiple of achievable positions on your given axis. As a for instance, my Z axis uses a 0.9° step angle motor with a 9.525mm per revolution lead screw pitch and a 1:1 gear ratio. This means my axis will move 0.0238125mm per full step. That in turn means I can't hit certain heights, 10mm for example. The reason for that is that 10mm would be 419.94750656 full steps. I can, however, hit 10.00125. Also worth noting is that this system has a rated accuracy of 0.015mm, so that's gonna play a part in which positions you can and can't achieve.

Things I need to do:

     - Make the code more tolerant, add some "fuzziness" to the evaluation to allow for how the axis actually moves
     - Incorporate any suggestions I get here

I've posted the .ino Arduino project here. It's disgusting, and alpha as all hell, so... be gentle I suppose. I'll take any help I can get, but I'll also try to incorporate any suggestions I see here.

It's a... quadrature encoder? The board takes 5v, and has three channels, A B and index. Index is pulled logic high on every state change, A and B are 90 degrees out of phase, so you can use that to determine direction.

Two great eresources I used are here and here.

Really all you need is two GPIO pins, and allow NanoDLP to count clicks. Provide drop downs for which GPIOs the encoder is connected to, and then allow the user to specify the distance per click of the encoder strip, and the rest is just a simple count. It's all in the (hella alpha) example code I linked.

Last edited by backXslash (2016-07-20 04:38:46)