You are not logged in.
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.
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...
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.
On the latest beta, the printer profile will not save correctly if there is a decimal present in the layer height field
It was my mistake on HTML side. I have fixed it now on beta version. All calculation are in float64, but in order to have tidy display it does some rounding only on display side.
That's awesome, thank you.
Any ideas on a calibration guide for resin layer height?
Hello,
It will be great (for those of us which use macro lenses) if there are software compensation of lens distortion.
Yes, yes it would. 2'nd-ed
Also, Shahin, why does NanoDLP limit the layer height to round number?
I ask because my Z-axis steps at 0.0238125mm per degree of motor rotation, so any layer height must therefore be some multiple of that. It would be nice to have NanoDLP support 47.625 micron layers, as that would assist in repeatability. The axis is effectively locked to a certain "sweet spot" of layering that things will tend to come out closer to anyway. I know there's not much of a real-world difference between 48 and 47.625, but still.
Does anyone know off hand if there's a guide or tutorial on calibrating the cure time for a given layer height?
I've found links to the UV light meter method for generating a mask, and I'm just waiting on parts to come in for that. But once they're in, I'm a little unclear on how to actually go about testing a given cure time or how to.... do it.
For instance, when I calibrated my Z-axis I set my steps per mm, sent a G01 command to move 10mm, measured, and did the math to find the correction. When I did my X/Y calibration, I "printed" a 10x10x10 mm cube over and over until I got it right, doing the math to zero in on the correct numbers iteratively.
How do I do that for resin curing?
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.
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.
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 do not have plan to add support generation to nanodlp. It will be resource intensive process which require much better performing hardware than current rpi.
Ah, so it's stand alone software
I guess we will complete support definition and manual placement during this week. The slicer badly delayed the project.
Is the support generator included in the newer builds? I've added a few STL's, but it looks like they're just being sliced, not supported.
Hi,
Very nice setup and print. What resin you use? I am curious is it possible to use B9 castable resins with top down systems?
Thank you! Honestly, there's really only one way to find out. I've always been an advocate of "well shit, try it", right?
Actually, to be specific, I've got a barrel distortion due to my lens set up. It's correctable in software, I think, just not sure how to get my projector to actually do it.
Do we have a guide for managing keystone-ing?
My projector needs a bit of a tweak, and I'm not 100% sure how to go about that, honestly. Obviously we want our prints to be uniform across all axises, but how do we test that? Just a few pointers would be great.
Actually at-least 3 different versions of mobile app for nanodlp in work. One of the by us for a customer which result would not be published by us. It is already possible to communicate with nanodlp as everything available as simple get/post requests.
There are also couple of hidden URLs to get setting from nanodlp.Regarding IFTTT, you can trigger it using our Syscalls by doing something like this
curl -X POST https://maker.ifttt.com/trigger/{event}/with/key/{key}
Nice! Thank you sir!
Pretty sure we add \r\n at the end of each command in ascii mode. Could you add \n to the end after \r and see if it is still working?
I did that actually, and the projector throws an error. It specifically wants JUST \r. The way that binary mode works is PERFECT, so far as I'm concerned, I wouldn't change it.
Is it possible to integrate NanoDLP with IFTT? Or add some kind of API to allow end users to communicate programmatically with it?
Really, just to allow potential for iOS / Android controller apps, and push notifications and such.
I am not sure if it is possible to copy output to the third port. Try tee.
Have you seen anything strange going on between minicom and nanodlp yet?
I actually got it working! NanoDLP wasn't appending the carriage return, which was good! I added \r to the end of the command, in ASCII, selected "binary mode" for the communication mode, and let 'er rip just to see what'd happen.
Works perfect!
Is there a way to simply view the data stream between the two? As in fork the data from nanodlp so I can see it, but also have it still go to the projector's serial port?
I'm having some trouble crafting the socat command I need. Basically, I'm thinking I should be able to create /dev/pts/1 and /dev/pts/2, point NanoDLP at the first one, connect Minicom to the second one. Also, I'd like to open the second one as a pipe, and echo everything that appears there to /dev/Projector, that way I can watch the entire data stream from NanoDLP to the projector, and see what's actually happening, as well as injecting commands to see the difference.
socat -d -d pty,raw,echo=0 pty,raw,echo=0is the first command
I had thought
socat -d -d PIPE:/dev/pts/6 OPEN:/dev/usb.Projectorwould work for the second, but it doesn't appear to echo or pipe anything to the correct port.
Ideas? Or would it be easier to somehow use the tee command?
Yes, run it on rpi.
➜ ~ socat -d -d pty,raw,echo=0 pty,raw,echo=0 2016/06/13 19:54:37 socat[2574] N PTY is /dev/pts/21 2016/06/13 19:54:37 socat[2574] N PTY is /dev/pts/22 2016/06/13 19:54:37 socat[2574] N starting data transfer loop with FDs [5,5] and [7,7]It will open two pipe like above /dev/pts/21 and /dev/pts/22. Enter one of them as the projector address on nanodlp and on minicom enter the other one. You could monitor exact commands going out of nanodlp.
Got it. I'm trying to find time to sit and mess with it.
Is there a way to simply view the data stream between the two? As in fork the data from nanodlp so I can see it, but also have it still go to the projector's serial port?
Run command below.
socat -d -d pty,raw,echo=0 pty,raw,echo=0It will open two path, enter one into minicom and other one into nanodlp.
That's the full command? I'm sorry, I confess, I'm not familliar with socat.
Could you check nanodlp (generic version) messages with minicom + socat and let me know what is the difference cause the issue with viviteks?
Sure! Ummm.... How do I do that?
Have tried hex mode, yet?
Ok, I tried hex mode. Doesn't seem to work.
I installed minicom on the 'Pi and in minicom the projector responds exactly as it's supposed to. Basically, I type V99S0001 and press enter and the projector responds 'P' (for pass) and then turns on. When it's on, I can type V99S0002 and press enter and it turns off. At any point, I can type V99G0004 and press enter and the projector responds with the lamp hours and the P for pass. Below is a copy and paste of a quick little session I just ran for demo.
V99G0004
P
V99S0001
P
V99G0007
P2
V99S0002
P
V99G0007
P3
V99G0007
V99G0004
F
V99G0004
F
V99G0007
P1
V99S0001
P
V99G0004
P163