You are not logged in.
Shahin -
It would be awesome if we could implement encoder support in the GPIO's for closed loop positioning or at the very least hardware based movement sync. Adding an encoder to a given axis isn't very hard at all, so adding the support for it in NanoDLP would be KILLER as far as reliability, repeatability, and software based tuning for better more consistent prints.
Offline
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?
Offline
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?
http://www.usdigital.com/products/encod … ary/kit/E2
These are essentially bolt-on additions. All they do is "click" a certain number of times per revolution. If NanoDLP was set upto pay attention to that, then we could change the z axis setup to be nearly automatic. Just enter the number of clicks per revolution of your encoder, and then pulse the stepper a set number of times. Measure the distance the z axis traveled, and enter that, NanoDLP does the rest because it's simple math at that point. For the more obsessive among us, you could even allow multiple measurement sessions to ensure complete accuracy.
Once calibrated, NanoDLP's built in movement sync functionality becomes even more impressive, because if we told the stepper to move 5mm, and we know that 5mm of travel is equal to X number of clicks of the encoder, if the encoded clicks more or fewer times than X, the movement was wrong, and we can self correct seamlessly and transparently.
It would ensure near-perfect layer height every time. The only other factor would be light bleed if your resin doesn't have enough pigment.
Offline
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.
Offline
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.
For your set up, probably. Not so much for mine.
Aside from which, I have yet to find a single person in any 3D printer community for any printer type that complains about their printer being TOO accurate.
Encoded support is a good idea.
Offline
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.
Offline
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.
Well if it's getting added to the code base I for one would personally greatly appreciate it if it would be added to Nano dop as well even if it's just an option that very few use. For those of us who can use it, it's a big deal.
Offline
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.
Offline
In most cases gravity takes care of backlash, so there's not even a need for an expensive ballscrew for SLA printers. The bottleneck is clearly not Z, but pixel size. There are banding artifacts even with antialiasing that can be really annoying for demands in very high visual quality of the printed models. Lots of people brag about their 5 micron z resolution while they print on a platform which has 50+ micron XY resolution.
What would really interest me is how Env1s1ontec gets their machines to print such smooth models.
Offline
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)
Offline
What would really interest me is how Env1s1ontec gets their machines to print such smooth models.
Maybe this one? http://www.google.com/patents/EP1894705A2?cl=en
Offline
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.
Offline
I became very busy lately. I have it in my to do list after mask generation feature.
Offline
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 !
Offline
backXslash wrote: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 !
Oh yes, I'm about | | this close from buying one. I'm also looking at a magnetic linear encoded that would go along the Z axis itself and provide true micron level feedback to the host.
Just waiting for a sample kit to arrive and I'll know a bit more.
Offline
Good to know it supports i2c, probably compatibility with nanodlp will be easy.
Offline
So my sample strip arrived yesterday. I've been at a show all weekend, but I did have time to look at the strip. It perfectly fits the entire usable area of my z-axis. I don't know the first thing about what's under the hood of nanodlp, but I do know a tiny bit about python and a tiny bit about arduinos.
Monday or Tuesday the actual encoder board should arrive, and I'll hook it up. My plan is to set up the encoder as a stand-alone DRO type of thing, with a Teensy++ I found in one of my drawers. I haven't decided which yet, but I'll either code the Teensy to watch the encoder and store the current position and simply reply with that position when polled, or I'll code a python daemon to watch the Teensy's serial line and store the value. Either way, that value should then be accessible from NanoDLP as a python or syscall, and I can replace the movement sync portion of my g-code with it and kind of... pseudo-close the loop on the Z-axis.
Hopefully that'll be a workable stopgap until Shahin can find time to fold real encoder support into the actual software.
-EDIT-
I forgot to mention - the encoder in question is an AS5306, and SHOULD provide 15 micron resolution. We'll see what's up shortly, and I'll try and keep this thread updated as I learn more.
Last edited by backXslash (2016-07-10 03:34:48)
Offline
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.
Offline
nanodlp could generate step/dir signals. Do you have sample code for communication with the encoder?
Offline
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...
Offline
Still not sure we could get absolute position from encoder or not but If I could get absolute position through i2c or serial, it will be really easy to add support.
Offline
Still not sure we could get absolute position from encoder or not but If I could get absolute position through i2c or serial, it will be really easy to add support.
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.
Offline
Requiring zero point is fine, even if we could set correct position on encoder, it will be better as we do not need to do unnecessary movements for axis without endstop.
If the other encoders working in similar fashion, supporting encoders will be really easy on nanodlp side, even without RAMPS help.
What kind of connection the encoder use to connect to the RAMPS?
Offline
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)
Offline
If GPIO is going to be main interface, unfortunately OS based software could not keep up with counting job very well. In high speed movements 0.015mm resolution will be lots of pulses per second.
Even if we could get number of clicks through board itself, without any direction or other info. It will be enough to achieve high accuracy.
Offline