You are not logged in.
Second though,
It could be possible through DMA, as we do not need to control length of pulses and just need to count pulses.
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.
Well, number of clicks is 100% already done with my current code.
Offline
Actually, my current code and board would cost less than $40 all in for the sensor and board and strip.
At the moment, the board accepts a list of commands:
- ZERO: homes or zeros the position of the sensor (I recommend doing this at the "top" or starting point of your build, so that the count is accurate, but it's there so you can decide)
- POS: responds with the current position of the axis expressed either as a number of clicks or a float equal to the mm distance traveled
- SEEK: this will move the axis in one full step increment until it reaches the requested position (Be aware, this is currently in clicks not mm, I need to fix that)
- STEP: this simply moves the axis by one full step increment (useful for determining the step to click count of your axis)
All communication is over USB serial interface, and is just shockingly smooth and accurate (which I wasn't expecting because let's be honest, the code is shit.)
How would you like me to proceed so that the project can be better integrated with NanoDLP?
Offline
Will it be open sourced or is it similar to any established solution available? I would prefer add support for hardwares which wide range of people could use.
Offline
Well, I'm offering to build and code it to your specifications. More than that, you provided NanoDLP to us, it wouldn't be very fitting for me to not reciprocate.
Honestly, I'm trying to make this a core feature of NanoDLP, because I really do think it'll make axis use and calibration easier and more reliable and repeatable for everyone (or at least everyone who chooses to use an encoder enabled axis).
So... you tell me what's best / easiest for NanoDLP
Offline
Current spec looks very good. I have to find a way to support it on both direct control and RAMPS method.
Are you going to wire it directly to nanodlp?
Offline
Current spec looks very good. I have to find a way to support it on both direct control and RAMPS method.
Are you going to wire it directly to nanodlp?
I hate to be a smartass, so if I'm coming off that way, I apologize in advance, but I'll wire it however you tell me to wire it. I'll work this weekend / next week on it, both as a standalone board as well as seeing what I can accomplish with the RPi's GPIO's alone and I guess we can go from there.
I'm a functional programmer, not a good one, by which I mean I'll get the job done and it'll work, but it may not be pretty or best practices. I'm more familiar with C / C++, but I have passing familiarity with Python, Java, Ruby, Perl, Bash, and whatever flavor of JS you want to write Node.JS apps in.
What's NanoDLP actually written in so maybe I can start with that? Otherwise we'll probably end up having to port Python code.
Offline
nanodlp have written in go (golang) with some C and ASM.
I came up with following scenario.
We have USB (serial) encoder. (i2c will be more suitable I am not sure how hard will be implementation on your side)
The encoder needs to support two commands
POS - current click counter value
ZERO - reset counter
On nanodlp side we will have two new configurations.
Click size
i2c or serial address for encoder
For direct control:
Before each movement zero command will be sent.
After movement position will be requested and if needed another movement will be sent based on reported position
For RAMPS two new keywords will be supported which will be usable on gcode boxes.
[[EncPos]]; in mm
[[EncZero]]
Will it be enough?
Offline
nanodlp have written in go (golang) with some C and ASM.
I came up with following scenario.
We have USB (serial) encoder. (i2c will be more suitable I am not sure how hard will be implementation on your side)
The encoder needs to support two commandsPOS - current click counter value ZERO - reset counter
On nanodlp side we will have two new configurations.
Click size i2c or serial address for encoder
For direct control:
Before each movement zero command will be sent. After movement position will be requested and if needed another movement will be sent based on reported position
For RAMPS two new keywords will be supported which will be usable on gcode boxes.
[[EncPos]]; in mm [[EncZero]]
Will it be enough?
Sold. I'll get it done as soon as I can!
Offline
I can make it ready until the end of next week. How is your progress on the hardware side?
Offline
I can make it ready until the end of next week. How is your progress on the hardware side?
Stalled at the moment, I haven't had a chance to sit and work on it. I'll try to get it to the top of my list again here shortly. The real world has intruded a bit recently.
Offline
We are working on software for CNC machines and such encoders could be very useful.
Offline
We are working on software for CNC machines and such encoders could be very useful.
may I ask how many axis it will support ?
and is there possibility of simultaneously movement at least 4-axis , better if 5-axis ?
and what kind of surface toolpaths generator will support nurbs or mesh ?
Offline
backXslash,
For response as number of clicks, I believe format such as n+n could be prove useful.
Lets say we send command to platform already on vat floor to go down 10 pulses down, after 5 pulses vat floor push the motor back for 5 pulses.
DLprinter,
Even if it does not help increase accuracy on one axis. It still could prove handy for mechanical and electronic fault detection and floor detection.
Offline
DLprinter
Lets continue CNC discussion here.
http://www.nanodlp.com/forum/viewtopic.php?pid=1136
Offline
backXslash
sorry man , but you spend time for nothing .
believe me as man who create the first 5-axis cnc for jewelry wax mill in the world
Can't say my time was wasted, after all, it was my time to spend. Nice that you've got a wax mill I suppose though... good for you? The ... is with you people telling me that encoder support is a bad idea or a waste of time? The ... do you care? It's my time, I think it's a worthy pursuit, and even if you don't happen to use it with NanoDLP, it'll probably end up being a useful feature to someone at a later date.
Jesus christ you entitled ...
End rant, I suppose, and thank you Shahin for your patience and support.
Offline
I guess lack of English skill and etc cause these misunderstandings.
Please, keep it cool and focus on the topic. I prefer not to remove or edit comments, help me keep it this way.
Offline