Magnetic Linear Encoders

[Jason von Nieda]

Ran across this post on Reddit: https://www.reddit.com/r/3Dprinting/comments/4zd8lk/magnetic_linear_encoders_testers_wanted_free_stuff/

Looks like this guy is doing some really cool stuff with making magnetic linear encoders readily accessible. Could be a very interesting way to close the loop on stepper based PnPs.

Jason

[Graeme Bridge]

Funny as i stumbled across a bag of bits from an old inkjet that used a optical encoder with a long thin plastic strip and wondered if to would be transferable to PNP

[Wireb]

Yes if you have the read head and the strip from a printer (AND the strip is long enough) you could use it on a PnP or other robot. It is just a standard quadrature encoder with a plastic vs glass scale. Not sure what the resolution would be...

[John Socha-Leialoha]

That's cool. The chip is an NSE-5130: http://www2.mouser.com/ProductDetail/ams/NSE-5310-ASSU/?qs=%2fha2pyFadujwWeCVPQ7t%2fAe8FHe8eluR8K1iOsE43vBsrD75a6kWbw%3d%3d&utm_source=octopart&utm_medium=aggregator&utm_campaign=985-NSE-5310-A

Looking at the datasheet, they mention that you can use the end of the strip to detect the zero position, which would also be useful. Does anyone know about what types of strips you have to use and where you can get them? 

[Jason von Nieda]

The poster of the Reddit thread has the strips in his store: http://aus3d.com.au/mag-strip-300mm

Jason

On Wed, Aug 24, 2016 at 1:01 PM John Socha-Leialoha <jo...@socha.com> wrote:

That's cool. The chip is an NSE-5130: http://www2.mouser.com/ProductDetail/ams/NSE-5310-ASSU/?qs=%2fha2pyFadujwWeCVPQ7t%2fAe8FHe8eluR8K1iOsE43vBsrD75a6kWbw%3d%3d&utm_source=octopart&utm_medium=aggregator&utm_campaign=985-NSE-5310-A

Looking at the datasheet, they mention that you can use the end of the strip to detect the zero position, which would also be useful. Does anyone know about what types of strips you have to use and where you can get them? 

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/2cc40a53-ef33-4796-853a-b44e63ced384%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Joao Matos]

This looks pretty cool.

You can find the magnetic strips on their website: http://aus3d.com.au/mag-strip-300mm

Also this page provides more suppliers: http://ams.com/eng/Products/Magnetic-Position-Sensors/Magnets2/Recommended-Magnet-Suppliers

Does anyone know how linear encoders compare to rotary encoders for PnP purposes? Which one would be "best"?

If I understand correctly, linear encoders will generally give you absolute position whereas rotary ones are usually incremental?

 

[Jason von Nieda]

These linear encoders are also incremental. The position resets every 2mm, so the onboard microcontroller keeps track of how many resets there have been to create an absolute position.

The nice thing about linear over rotary is that linear encoders show you exactly where your axis is, where rotary just shows you where your motor is. It doesn't account for any slop there may be in the drive system - belts, gears, pulleys, etc.

So, IMHO linear encoders would be perfect for PnP. Rotary is also good, but I think linear is better.

Jason

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/940fbf40-49da-41f4-ae85-da9ab996c18f%40googlegroups.com.

[Michael Anton]

This is another closed loop option: https://www.kickstarter.com/projects/tropicallabs/mechaduino-powerful-open-source-industrial-servo-m, though it is rotary magnetic, and replaces the motor driver.  I backed this campaign, so I'll post an update when I have a chance to try them.

Mike

[Michael Anton]

Yes, linear would be the best.  Their solution doesn't seem to correct in real time though, which is unfortunate, but that may just require firmware changes in order to speed up the correction rate (it probably isn't trivial however).

Mike

[Jose Silva]

Take a look on this site

http://ams.com/eng/Products/Magnetic-Position-Sensors/Linear-Position

 

[Oz-Ron]

Jason,

I agree the linear absolute position feedback is perfect. 

Plenty of encoder chip options.  (they do need tight clearance gap control though)

Anyone know where to buy the accurate magnetic strips ~600mm length?

 

Cheers,

Ron

[Peter Betz]

On Wednesday, August 24, 2016 at 3:25:16 PM UTC-7, Michael Anton wrote:

Yes, linear would be the best.  Their solution doesn't seem to correct in real time though, which is unfortunate, but that may just require firmware changes in order to speed up the correction rate (it probably isn't trivial however).

Are you assuming that because of his blog and test print/ video? I don't think that shows that it isn't real, or nearly real time, as the driver was thermally shutting down for that test and you don't know how many correction commands were sent to it before the driver came back online and responded.

Peter.

[Michael Anton]

That's true, but given how much it printed in the wrong location, I'm assuming not real time correction.  Once it started moving again, it should have corrected very quickly, like during the first move.  A better test would have been for them to force the steppers to skip, by applying a force, and then seeing how long it took to recover.

The rotary closed loop drivers that I posted a link to shouldn't have this problem, as they correct the motor position at something like 3kHz.  They respond quickly to a disturbance.  Now, perhaps the linear ones could be used in a similar fashion, but anytime I've seen a linear encoder used to close the loop, it isn't used to handle the dynamic response part, which is usually done by a rotary encoder on the motor.  The linear just closes the loop in a slower fashion, as the other mechanical dynamics can cause all sorts of oscillations if you were to try to correct in real time.

[Peter Betz]

I didn't watch the video, so maybe you saw something there that isn't apparent in the test pieces. I assumed an instant correction once the affected driver came back on line, it would continue printing out in space until that happened, it truely is an exaggerated worst case scenario, not like missing a couple steps.

 Only thing with a rotary encoder (on the stepper) is that you wouldn't get any of the other cool attributes, like axis calibration or compensation for mechanical looseness etc.

[Michael Anton]

Watch the video, and then you will understand what I was referring to.  It was obvious to me that something went pretty off in the test pieces.  With faster correction, this likely wouldn't have been the case.

I think the ideal is rotary, and linear, like servo based CNC machines use.  The rotary encoder deals with the motor dynamics and position error due to the motor, and the linear deals with removing the remaining sources of error.

[Mark Harris]

There's no reason there should be a delay in a linear encoder, any more than there should be in a rotary system. Its all down to the feedback loop quality. Just because his implementation (may?) be poor, at at the very least his demo of it, doesn't mean that it is a bad system. All inkjet printers have encoder strips (pretty expensive ones) as do all epilog lasers (which is hilarious as they have to be cleaned A LOT due to laser residue build up hehe) - those systems are very well proven.

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c11cab9e-eae2-402c-8160-da3b3dd7e5c3%40googlegroups.com.

[Michael Anton]

Printers may not use the encoder strip for motor control however.  They maybe just respond to the current position, which is a different thing entirely.

I know from a CNC control standpoint, that the fastest part of the control loop is usually done using a rotary encoder as feedback (a servo for instance).  There are many mechanical delays associated with a linear encoder system, that makes doing a high speed control loop very difficult, or at least that is my understanding of it.  Again, the delays are not in the linear encoder per se, but in the mechanics before the linear encoder.  A linear encoder does work well to close the final position loop, but they usually are not directly coupled well enough to close the dynamic part of the control loop, which is why rotary encoders are used for that purpose, since they are directly coupled to the motor.

I wasn't implying that a linear encoder system is bad in any way, but rather that the demonstrated implementation didn't look that great, and that they are not necessarily a substitute for a rotary encoder in all cases.

On Thursday, August 25, 2016 at 9:06:39 PM UTC-6, Mark Harris wrote:

There's no reason there should be a delay in a linear encoder, any more than there should be in a rotary system. Its all down to the feedback loop quality. Just because his implementation (may?) be poor, at at the very least his demo of it, doesn't mean that it is a bad system. All inkjet printers have encoder strips (pretty expensive ones) as do all epilog lasers (which is hilarious as they have to be cleaned A LOT due to laser residue build up hehe) - those systems are very well proven.

On 25 August 2016 at 20:27, Michael Anton <3d.m...@gmail.com> wrote:

Watch the video, and then you will understand what I was referring to.  It was obvious to me that something went pretty off in the test pieces.  With faster correction, this likely wouldn't have been the case.

I think the ideal is rotary, and linear, like servo based CNC machines use.  The rotary encoder deals with the motor dynamics and position error due to the motor, and the linear deals with removing the remaining sources of error.

On Thursday, August 25, 2016 at 4:26:05 PM UTC-6, Peter Betz wrote:

I didn't watch the video, so maybe you saw something there that isn't apparent in the test pieces. I assumed an instant correction once the affected driver came back on line, it would continue printing out in space until that happened, it truely is an exaggerated worst case scenario, not like missing a couple steps.

 Only thing with a rotary encoder (on the stepper) is that you wouldn't get any of the other cool attributes, like axis calibration or compensation for mechanical looseness etc.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

[Cri S]

Linear encoder have the advantage of include more error source. It include backlash or imprecision from linear rail,tension loosing or over strength problems on belt, eccentricity from pulley just to name some. On pick and place linear encoder are used to scale speed when there are no part on head driving the stepper at faster speed where step loss occurs.

[Lisandro B]

bringing this thread back to life, I have found that leadshine makes standalone motion controller that seems to be able to close the loop in circular al linear at the same time (not completely sure yet)
kind of expensive, almost 5x the price of an original smoothie,  but somehow "justifiable" if you are up to that level of precision
https://www.aliexpress.com/item/Free-shipping-SMC6480-4-Axis-Standalone-Motion-Controller-with-Ethernet-Supporting-Leadshine-Basic-Programming/32268147966.html?spm=2114.01010208.3.45.62Nod4&ws_ab_test=searchweb0_0,searchweb201602_4_10065_10068_10000032_119_10000025_10000029_430_10000028_10060_10062_10056_10055_10000062_10054_301_10059_10099_10000022_10000012_10103_10102_10000015_10096_10000018_10000019_10000056_10000059_10052_10053_10107_10050_10106_10051_10000053_10000007_10000050_10084_10083_10000047_10080_10082_10081_10110_10111_10112_10113_10114_10115_10000041_10000044_10078_10079_10000038_429_10073_10000035_10121,searchweb201603_9,afswitch_1,single_sort_1_price_asc&btsid=607ed97c-5b4a-49ae-ac14-c4c31b16a2cb 

[Lisandro B]

another and way cheaper alternative will be to implement a "final point compensation" this could be done with a fast arduino like teensy, uno32,  or any other that has enough cuadrature encoder inputs (2) reading the  linear encoders, then, on arrival to position, openpnp could use this data to apply correction between actual/commanded position.

The hardest part, for openpnp coders, may be to implement some sort of backlash measure  that should be done once so the correction  loop knows this error beforehand

And, fantasizing a bit more, this could also be use for what is known as "screw mapping" , where you  make a complete map of errors in the whole travel of an axis. Linuxcnc has this function. Overkill? maybe, but it doesn't seem to difficult to implement

 

[Jason von Nieda]

Screw mapping is something that will probably get added in one form or another in the next few months. I am in the process of building a screw based machine with cheap 1605 ball screws and I expect to need screw mapping to get the accuracy I need. 

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/58a00f3c-6266-4a3c-8fbb-5fd41d3ea97d%40googlegroups.com.

[Lisandro B]

Im thinking on the same but plan to use 1616 or 1620 screws, almost same price but speedier. However, this "screw mapping will be usefull for belts as well.

What do you thing about final point compensation? Im willing to help you in all there I can, arduino, hardware and betta testing, except java
It makes perfect sense to me since openpnp doesnt have to "worry" about traveling errors meaning that we are not milling a piece


http://www.galilmc.com/learn/online-videos/dual-loop-compensation-methods 

[Jason von Nieda]

Lisandro,

I feel that in both cases this would be something that is done in the motion controller firmware, rather than in OpenPnP. Having OpenPnP do this would tie it to very specific pieces of hardware. I think it's better if OpenPnP just says "Go to this position" and the motion controller does it's best to get there, whether that includes screw mapping, final point compensation, closed loop control, etc.

Jason

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/0b6fa1e3-5c1c-4199-a980-4fda8a48f97c%40googlegroups.com.

[Lisandro B]

I do think the same, but unfortunately, the motion controllers that are capable of that, are too expensive, of course they have toons of features but few are usefull in here

Dont want to be too pushy , but the more I think of it, the more it makes sense, 1 send position,2 read this "DRO", 3 If the error is not too big (stall), compensate (to a certain level to avoid oscilation)

[Lisandro B]

About specific hardware, i don't think this is much different than, ie, a camera, there are lots of providers as there a lots of mcus with cuadrature inputs and enough speed...
As for linear encoder, also a lot of providers, from cheap magnetic to sub micron glass encoder.
Of course this is a optional improvement, as it is a bottom vision or more than one nozzle

[Mark Harris]

Nice find, that motion controller looks great. I'm a really big fan of what Leadshine have done with their stepper/servo drivers.

One particularly interesting thing: Pulse output rate up to 5 MHz

It seems to have gcode interpretation on it, as well as an API... and it mentions a 5.6" and a 7" HMI as optional... very very interesting.

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/77f8eddb-8c53-4175-be92-b814b2da2620%40googlegroups.com.

[Jason von Nieda]

Lisandro,

I understand a bit better now. What about doing this with a Raspberry Pi? The Pi could act as a filter between OpenPnP and the motion controller.

It would look like this: OpenPnP <--> Raspberry Pi <--> Smoothieboard (or whatever you like)

The Raspberry Pi would run a simple program, could be written in Python. The program would accept commands from OpenPnP on one port and send the commands out to the motion controller on the other port. Most commands would just pass through. But motion commands would handle the final point compensation. So, a motion command would look something like this:

OpenPnP sends "G0X1Y1" to Pi

Pi sends "G0X1Y1" to Smoothieboard

Smoothieboard positions to 1,1 as best as it can and sends back "ok"

Pi checks encoder and sees that it is at 1.1,1.1

Pi sends "G0X0.9Y0.9" to Smoothieboard

Smoothieboard positions to 0.9,0.9 and sends back "ok"

Pi checks encoder and sees that it is at 1,1 and sends "ok" back to OpenPnP

This would allow you to do any level or complexity of correction without having to write a line of Java. OpenPnP doesn't care as long as it can send commands and get "ok" back at the end.

What do you think?

Jason

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/77f8eddb-8c53-4175-be92-b814b2da2620%40googlegroups.com.

[DAniel Dumitru]

Generaly LEadshine seems to be a serious company , BUT  I would stay away from any of those chinese motion controllers.

Why it's not Smoothie enough ?  Last time when I have been speaking with ARthur , was posible to configure it to run with 70K pulses per second.

What microstepping are you planning and what speed are you willing to achieve ?

I would stick to open source world...

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAJMBTyQ56swoAae6gAbgnXDPJThwQnThmtbeVnpEqxWwiCwtpg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

---

Acest email a fost scanat contra virușilor de către programul antivirus Avast. www.avast.com

[Mark Harris]

Running servos at full resolution with 10k/rev encoders (leadshine) means a LOT of steps but also a lot of speed/accuracy. 125kHz the smoothie can run will lead to a rather slow machine. Other motion controllers i've seen based on the beaglebone can get to 2mhz... something like an ethernet smoothstepper gets to 4mhz as do other mach IO cards... but those are pretty much all closed source and have no documentation.

On 3 February 2017 at 10:40, DAniel Dumitru <dand...@gmail.com> wrote:

Generaly LEadshine seems to be a serious company , BUT  I would stay away from any of those chinese motion controllers.

Why it's not Smoothie enough ?  Last time when I have been speaking with ARthur , was posible to configure it to run with 70K pulses per second.

What microstepping are you planning and what speed are you willing to achieve ?

I would stick to open source world...

La 03.02.2017 19:29, Mark Harris a scris:

Nice find, that motion controller looks great. I'm a really big fan of what Leadshine have done with their stepper/servo drivers.

One particularly interesting thing: Pulse output rate up to 5 MHz

It seems to have gcode interpretation on it, as well as an API... and it mentions a 5.6" and a 7" HMI as optional... very very interesting.

On 3 February 2017 at 10:25, 'Lisandro B' via OpenPnP <ope...@googlegroups.com> wrote:

About specific hardware, i don't think this is much different than, ie, a camera, there are lots of providers as there a lots of mcus with cuadrature inputs and enough speed...
As for linear encoder, also a lot of providers, from cheap magnetic to sub micron glass encoder.
Of course this is a optional improvement, as it is a bottom vision or more than one nozzle

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/77f8eddb-8c53-4175-be92-b814b2da2620%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAJMBTyQ56swoAae6gAbgnXDPJThwQnThmtbeVnpEqxWwiCwtpg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

---

Acest email a fost scanat contra virușilor de către programul antivirus Avast. www.avast.com

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/608a3d06-d8cc-dab9-ba1a-47476fdf3b4c%40gmail.com.

[Lisandro B]

Not a bad idea Jason, I need to think about if its any posibility that any accumulative error can get big anough so the difference between openpnp "assumed" position and the real one could bring any issues, like crashing the head onto a rail

El viernes, 3 de febrero de 2017, 14:40:42 (UTC-3), Daniel escribió:

Generaly LEadshine seems to be a serious company , BUT  I would stay away from any of those chinese motion controllers.

Why it's not Smoothie enough ?  Last time when I have been speaking with ARthur , was posible to configure it to run with 70K pulses per second.

What microstepping are you planning and what speed are you willing to achieve ?

I would stick to open source world...


La 03.02.2017 19:29, Mark Harris a scris:

Nice find, that motion controller looks great. I'm a really big fan of what Leadshine have done with their stepper/servo drivers.

One particularly interesting thing: Pulse output rate up to 5 MHz

It seems to have gcode interpretation on it, as well as an API... and it mentions a 5.6" and a 7" HMI as optional... very very interesting.

On 3 February 2017 at 10:25, 'Lisandro B' via OpenPnP <ope...@googlegroups.com> wrote:

About specific hardware, i don't think this is much different than, ie, a camera, there are lots of providers as there a lots of mcus with cuadrature inputs and enough speed...
As for linear encoder, also a lot of providers, from cheap magnetic to sub micron glass encoder.
Of course this is a optional improvement, as it is a bottom vision or more than one nozzle

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/77f8eddb-8c53-4175-be92-b814b2da2620%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAJMBTyQ56swoAae6gAbgnXDPJThwQnThmtbeVnpEqxWwiCwtpg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Lisandro B]

mesa boards are also capable of running at  ridiculously high step rates, I have a 5i25 on my cnc for years now and Im very happy, they can spit step way faster than what my steppers could handle

[Lisandro B]

Jason: just an idea, could this compensation be made in an openpnp script instead of using an intermediary like a RPi?

[Jason von Nieda]

Lisandro,

Not really. It would need to be done at the driver level. 

The reason I am pushing back against adding this to OpenPnP is that it means OpenPnP needs to learn about quad encoders, their protocols, how to connect to them, hysteresis, maybe PID loops, etc. All stuff that is extremely machine specific. That means adding new UIs for setting all of that up, too. It's a lot of work (for me) that only benefits a small percentage of users with a particular type of setup.

This is why I always try to make any machine specific functionality happen outside of OpenPnP. It keeps OpenPnP (relatively) simple and lets people go wild with their imaginations on their hardware. If I try to put every kind of hardware functionality into OpenPnP we will end up with a program with a billion options and each person will only use 1% of them. See Mach 3 for a good example of this. 

Things like cameras are different. Every PnP needs cameras and we can connect to them in a generic way, using UVC, so this is easy to support. But adding support for encoders directly, along with the algorithms that will be needed to work with them adds a lot of complexity that is not generally useful to most people.

If you really wanted to do this inside OpenPnP then the way to do it would be to write a custom driver. The system is designed to allow this, simply by creating a new class and adding your functionality to it.

Hope you understand. It's not that I think this is a bad idea, but it's not something that I can spend a lot of time on.

Jason

On Fri, Feb 3, 2017 at 12:50 PM 'Lisandro B' via OpenPnP <ope...@googlegroups.com> wrote:

Jason: just an idea,  could this compensation be made in an openpnp script instead of using an intermediary like a RPi?

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b4800f8a-75b7-4ae1-99f1-06df4c81a09f%40googlegroups.com.

[Lisandro B]

Don't worry Jason, I completely understand your points.
Nonetheless a couple of comments about this lines

"OpenPnP needs to learn about quad encoders, their protocols, how to connect to them, hysteresis, maybe PID loops"

This is not the case and please forget me if I didn't explain this better:

-No need for quad encoder in openpnp, the quad should be read by an arduino, openpnp should poll this arduino on position arrival, both the arduino sketch and the protocol will be open. This is not very different than the current sub drivers, very very similar in fact.
- No need for PID, this is only needed on single or dual compensation, but since p&p process is a point to point one, just applying end point compensation is more than enough

Again, don't want to insist to much, you know I'm extremely grateful for what you have done so far and only take this thread this far because IMHO this is a good feature and doing it this way will enable many people to use it without spending hundreds.
Please only allow me to ask this one last time, could this script be possible? :
-Triggered on destination arrival
-interrogate this "sub driver" for the real position
-calculate the difference
-tell openpnp to move to this compensated position

Sorry again and promise not to bother anymore if you still find this unsuitable

[Cri S]

Trinamic have motion controllers that have encoder inputs and closed loop behavior
and can be driven from step / dir input or from rs232/can port.
Further that controllers are accessible from price if you could make the PCB for it.

[Jason von Nieda]

Lisandro,

We don't currently have a destination arrival event, but that's easy enough to add.

There are two main problems with this:

1. All hardware access in OpenPnP is done through the driver interface. I don't know how much programming you've done, so I don't know if this concept is familiar to you, but basically OpenPnP has a very strict set of operations it can perform at a hardware level. In short, they are: move to a position, trigger an actuator, pick, place, home. That is all that OpenPnP itself knows how to do. The individual drivers can do more, but it's up to them to do it and it is hidden from OpenPnP itself.

The issue, then, is that there is no "read real position" type command. 

2. The biggest problem is that when OpenPnP tells the driver "move to X, Y, Z, C" it expects that when it's done it will be at X, Y, Z, C. If you to then tell it to move to Xn, Yn, Zn, Cn then everything OpenPnP knows about the current position would be off by n. The DROs would display the wrong position, calculations would be based on the wrong position, capturing values in the UI would be incorrect, etc.

This is why this functionality would need to be buried inside a driver, at least. The driver could hide the offset (n) and just let OpenPnP believe that it is at X,Y,Z,C even though it's really at Xn,Yn,Zn,Cn.

So, the correct way to do this in OpenPnP without making large changes would be either:

1. Write a driver that knows how to connect to the Arduino, read the values and make adjustments. Or,

2. Modify the GcodeDriver to support this functionality. Or,

3. Handle it outside of OpenPnP, like with the Pi idea.

Option 1 and 2 requires writing a good amount of Java code. I still think that option 3 is the best solution, because this models how OpenPnP treats all hardware currently, but if you really wanted it to be in OpenPnP then option 2 would be the best way to go. 

The reason I mentioned PIDs is that you would need to account for what happens when you make your correction move but you still don't get to the right position. For instance:

1. You move the motor to X.

2. The encoder says you are at X-1

3. You move to X+1

4. The encoder says you are at X-0.25

5. You move to X+1.25

6. The encoder says you are at X-0.01

etc, etc, etc

So, in summary, it's possible, but it will require work done in at least the GcodeDriver or another driver. If you are willing to do that work then I'll be happy to accept it, but I personally believe this doesn't belong in OpenPnP. I think it's the wrong point in the chain for this type of functionality.

Jason

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/0ccde9c9-2105-4ec2-a26c-f5edaf861467%40googlegroups.com.

[Rich Obermeyer]

@Jason,

After reading this I ask, 

At what level in the software is the nozzle change done?

If you wanted to check a component for proper value?

Thx

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/0ccde9c9-2105-4ec2-a26c-f5edaf861467%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jwRuzYdvYkW5vBDw5hcU5yn2NAPpf_c809oxpUy7eX%2B4g%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Rich

[Jason von Nieda]

Rich,

May be better to start another thread if you want to discuss those topics in depth, but in brief:

* Nozzle change is handled at a high level in ReferenceNozzle and ReferenceNozzleTip.

* Checking component values is not supported. If you wanted to add it it would be relatively complex and would require similar changes as discussed above. 

Jason

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/0ccde9c9-2105-4ec2-a26c-f5edaf861467%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jwRuzYdvYkW5vBDw5hcU5yn2NAPpf_c809oxpUy7eX%2B4g%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Rich

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAOvy4mYJgODez_7_TDJdF-zHCtKjsSkV2dxom%3DFD5WYRpDkAgg%40mail.gmail.com.

[Lisandro B]

May I ask how do you plant to implement the screw mapping?


-PID is still not necesary, as said before, on end point compensation you could set an aceptable level error, otherwise it will oscilate

[Jason von Nieda]

Re: screw mapping: I'm not sure yet. The machine is likely going to be using Tarocco servo drivers, and since the firmware is open source I may do it there. Alternately, I may end up having an intermediary controller on the machine that handles the high level commands and do it there. That is all depending on whether I find it's needed at all. I'm still not sure of that yet. I've just started down this path. So far all I have is a screw sitting on my desk :)

Jason

On Fri, Feb 3, 2017 at 5:09 PM 'Lisandro B' via OpenPnP <ope...@googlegroups.com> wrote:

May I ask how do you plant to implement the screw mapping?


-PID is still not necesary, as said before, on end point compensation you could set an aceptable level error, otherwise it will oscilate

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/76bb4820-5167-420d-be80-ada39d373699%40googlegroups.com.

[Paul Jones]

I don’t think it belongs in OpenPnP either. Motion control problems are the domain of the motion controller. Using OpenPnP to compensate for a lack of functionality in the motion controller seems to be the wrong way to do things. Especially since all the discussion so far is about theoretical problems on machines under design, rather than an actual experienced problem.

Engineer types (me included) seem to have problems with premature optimisation… J

 

 

Paul.

 

 

From: ope...@googlegroups.com [mailto:ope...@googlegroups.com] On Behalf Of Jason von Nieda
Sent: Saturday, 4 February 2017 6:00 AM
To: OpenPnP <ope...@googlegroups.com>
Subject: Re: [OpenPnP] Re: Magnetic Linear Encoders

 

Lisandro,

 

Not really. It would need to be done at the driver level. 

 

The reason I am pushing back against adding this to OpenPnP is that it means OpenPnP needs to learn about quad encoders, their protocols, how to connect to them, hysteresis, maybe PID loops, etc. All stuff that is extremely machine specific. That means adding new UIs for setting all of that up, too. It's a lot of work (for me) that only benefits a small percentage of users with a particular type of setup.

 

This is why I always try to make any machine specific functionality happen outside of OpenPnP. It keeps OpenPnP (relatively) simple and lets people go wild with their imaginations on their hardware. If I try to put every kind of hardware functionality into OpenPnP we will end up with a program with a billion options and each person will only use 1% of them. See Mach 3 for a good example of this. 

 

Things like cameras are different. Every PnP needs cameras and we can connect to them in a generic way, using UVC, so this is easy to support. But adding support for encoders directly, along with the algorithms that will be needed to work with them adds a lot of complexity that is not generally useful to most people.

 

If you really wanted to do this inside OpenPnP then the way to do it would be to write a custom driver. The system is designed to allow this, simply by creating a new class and adding your functionality to it.

 

Hope you understand. It's not that I think this is a bad idea, but it's not something that I can spend a lot of time on.

 

Jason

 

.

[Lisandro B]

"theoretical problems on machines under design"

Not really, real issues on real machines

[Jason von Nieda]

Lisandro and Rich,

I have just added some new functionality that may help you both with your questions: https://github.com/openpnp/openpnp/blob/develop/CHANGES.md#2017-02-05

This allows you to read values from connected sensors and devices and could potentially be used, along with scripting, to solve the issues you brought up. I still think the final point compensation will  be difficult because of the problems I mentioned, but this would allow you to experiment with it, at least.

Jason

On Sat, Feb 4, 2017 at 7:54 AM 'Lisandro B' via OpenPnP <ope...@googlegroups.com> wrote:

"theoretical problems on machines under design"

Not really, real issues on real machines

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/5a9095b1-2a2a-4709-90cc-96a3502fe1d7%40googlegroups.com.

[Maddog]

@jason
Can you start a new thread titled "new feature ideas"?
Then we have a place to ponder new things good and bad.

[Glen English]

For TVM920  I implement a faux location arrived event in the MyTVMDriver.java  :

1) When a MOVE_TO is issued , the TVM920 responds with an ESTIMATED COMPLETION TIME, and begins the move.

2) The MOVE_TO command then blocks waiting for the TVM920 to let it know it has finished OR a  timeout,  whichever happens first.

MEANWHILE

the Get Location commands (coming from a separate thread)  are passed and returned and the screen XYZC is updated in real time.

Multiple threads can issue commands simultaneously. A command ID tracking cookie is added to the TVM920 command. ( (a sequencial number) 

However there is a single receiver-consumer thread that gets all the TVM920 responses and returns them to the waiting threads (like the Move_to () or the GetLocation() which come from separate threads.

It knows which responses belongs to what thread  because the return from the TVM920 has the thread tracking cookie

Have been busy lately, will get back onto OPNP later this wek.

-glen

[Paul Jones]

Is your machine running and in use yet? Is it placing 0402s or smaller?

 

Paul

 

From: 'Lisandro B' via OpenPnP [mailto:ope...@googlegroups.com]
Sent: Sunday, 5 February 2017 12:54 AM
To: OpenPnP <ope...@googlegroups.com>
Subject: Re: [OpenPnP] Re: Magnetic Linear Encoders

 

"theoretical problems on machines under design"

Not really, real issues on real machines

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/5a9095b1-2a2a-4709-90cc-96a3502fe1d7%40googlegroups.com.

[Glen English]

Hi Paul

The machine places 0402s OK with  factory software and factory camera. I am close to placing 0402s with OpenPNP, been busy with work-work, maybe end of the week... WIll advise. OpenPNP should all just work now the feeders are sorted.

glen

[Lisandro B]

Sometime ago, there where a discussion if stay in this group or migrate to a forum, the consensus was (if I remember correctly)  to stay here but use sub groups for that

https://ist.njit.edu/google/googlegroupsfaq.php#a7

[oliver jackson]

I've read this topic through in full and don't understand. Can someone try to explain to me why openpnp needs to change at all? How is what you want to do any different to what you can do with e.g. Trampas' nano stepper as drivers, except using linear encoders not rotary? There openpnp sends position to smoothie or whatever and that just sends steps/dir/en to a nano stepper. Neither openpnp or smoothie know there's a closed loop controller at the end

[Jason von Nieda]

Oliver,

That is exactly the discussion at hand. My position is that OpenPnP should not need to know about these kinds of machine details. Lisandro's position is that it would be beneficial to have this feature in OpenPnP so that it doesn't have to be done in the motion controller or at a lower level. We disagree, and discuss :)

Jason

On Mon, Feb 6, 2017 at 9:33 AM oliver jackson <analogmon...@gmail.com> wrote:

I've read this topic through in full and don't understand. Can someone try to explain to me why openpnp needs to change at all? How is what you want to do any different to what you can do with e.g. Trampas' nano stepper as drivers, except using linear encoders not rotary? There openpnp sends position to smoothie or whatever and that just sends steps/dir/en to a nano stepper. Neither openpnp or smoothie know there's a closed loop controller at the end

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/01930B9F-227B-4EBB-BF3E-F6808F7EAFCC%40gmail.com.

[oliver jackson]

Thanks, I didn't miss a thing then. I really don't want closed loop control to be initiated so far up the chain, it should be the motor controllers responsibility. However what you have just added is really useful, could be a way to add DRO for literally anything you want.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jy-svHUdqodPGNQww7PbUd9XQnZ3nCxwF138FLo%3DtLT9Q%40mail.gmail.com.

[Jason von Nieda]

One thing to keep in mind is that OpenPnP is designed to allow for this sort of thing, as long as you are willing to put in the work. The driver model allows for any type of control you want. That's why I said that if Lisandro really wants to do it this way it is certainly possible but he will need to write a hunk of Java. 

I think it's important to be able to support anything that people want to throw at OpenPnP, so it is designed with a very flexible model that allows you easily replace almost any part of the functionality with affecting other users. Many people have done just that. If Lisandro wants to go this path then it will work fine for him, and it will not affect anyone who doesn't want to use it.

The only real issue is whether I am going to spend *my* time on it. IMHO it's not a feature that would be generally beneficial, and I don't personally have the need for it, so I am not going to write it. But if Lisandro wants to then by all means go for it, and I will help as much as I can along the way.

We can all work together! :)

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/B92764B7-D44E-4AAE-A993-87BD133D838D%40gmail.com.

[Lisandro B]

Look, im not the one who started this thread, Im just picking up what i think is a great idea, there are scales on pro machines for a reason.. 

And yes, also think this should be done properly in the motion controller, as I said many times, motion controllers that implement this are very expensive and hard to justify for only that feature in this particular application when this doesn't requires anything special on the software side

Now I think this read regex feature is a step in the right direction, enabling all sort of "feedback" to the machine, like vacuum pressure sensor, nozzle pressure, a laser to compensate for pcb bending...

Thank you as allways Jason

[Jason von Nieda]

Hi Lisandro,

I hope you didn't feel like I was picking on you. I certainly didn't mean to. I consider this a very useful discussion and I think some good learning and ideas have come from it.

Part of running any project is deciding what you will and won't implement, and this is just one of those ideas that I don't think I should work on. But like I said, that doesn't mean someone else can't!

Jason

On Mon, Feb 6, 2017 at 10:31 AM 'Lisandro B' via OpenPnP <ope...@googlegroups.com> wrote:

Look, im not the one who started this thread, Im just  and yes, also think this should be done properly in the motion controller, as I said many times, motion controllers that implement this are very expensive and hard to justify for only that feature in this particular application when this doesn't requires anything special on the software side

Now I think this read regex feature is a step in the right direction, enabling all sort of "feedback" to the machine, like vacuum pressure sensor, nozzle pressure, a laser to compensate for pcb bending...

Thank you as allways Jason

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1f05d32a-9e61-4f85-93dc-c4944f9fdc7d%40googlegroups.com.

[Lisandro B]

I didnt think that at all, sorry if i give that impression. Lets close this discussion, at least until I find time to start testing

[Jason von Nieda]

All's well! Putting this to rest, for now.

Jason

On Mon, Feb 6, 2017 at 10:51 AM 'Lisandro B' via OpenPnP <ope...@googlegroups.com> wrote:

I didnt think that at all, sorry if i give that impression. Lets close this discussion, at least until I find time to start testing

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c32e0865-bb55-4e2c-9877-fab919d3765b%40googlegroups.com.

[Lisandro B]

out of topic:

"
Sometime ago, there where a discussion if stay in this group or migrate to a forum, the consensus was (if I remember correctly)  to stay here but use sub groups for that

https://ist.njit.edu/google/googlegroupsfaq.php#a7
"

Also, I will be very happy to donate the cost of a year of hosting in a server if you wish to make a forum, It will be a small contribution compared with all your efforts

[Jason von Nieda]

This has been brought up several times in the past, and as recently as last May. There is a lengthy topic on it here: https://groups.google.com/d/msgid/openpnp/43d2eeae-9ca6-4909-b670-84f0c9baf7d7%40googlegroups.com

The end result is that the majority doesn't feel strongly about it, I do feel strongly about it staying a mailing list so that's what we are sticking with.

Jason

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/aca6ca67-6c0f-4c51-8cfc-ff40428e8ec3%40googlegroups.com.

[oliver jackson]

I enjoy that this forum is amazingly civil most of the time, way better than other places. So mine was a genuine question, what is it you hope to gain by having openpnp do it? I agree proprietary closed loop controllers are expensive but there are recent options that are really affordable.

The way I saw it, openpnps role is to tell the machine what to do, not to tell it how to do it. The machines role is to do what it's told. Inaccuracies are it not doing what it's told. If it's inaccurate it's the machine's job to correct it, not the host software.

Lisandro, have you tried any closed loop controllers in the way I described earlier? Was there something you were unhappy with? Or is this just down to people looking at doing the same thing with different approaches?

I backed both ustepper and mechaduino on Kickstarter and I've had a good look at nano0stepper. I've only played with them on weekend project robot designs but so far they've performed how I expected. I've not had them on CNC machines yet but I definitely want closed loop for x and y on my pnp. My ideal would be something like the above 3 but instead using a linear position encoder. In fact I'm sure it would be quite easy to modify the existing firmware to accept positioning from the I2C of the magnetic encoder in the Reddit post earlier, or a glass slide encoder

On 6 Feb 2017, at 16:51, 'Lisandro B' via OpenPnP <ope...@googlegroups.com> wrote:

I didnt think that at all, sorry if i give that impression. Lets close this discussion, at least until I find time to start testing

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c32e0865-bb55-4e2c-9877-fab919d3765b%40googlegroups.com.

[Glen English]

In my opinion

Open PNP is the high level process

All aspects of motion control should be the domain of the motion controller.

The motion controller takes care of getting it where it is going.

Open PNP is the passenger, the motion controller is the transit bus.

There is plenty of facility in the existing driver system to provide asynchronous notifications.

[Oz-Ron]

The other aspect is collision management.  Having a gross error check periodically to halt a job if something goes wrong would be a good safety feature.  Maybe Smoothie (V2?) might be able to handle this as it would be good for all machines.  Arthur?

Cheers,

Ron

[Lisandro B]

Oliver, please read the entire discussion and you will see what we are talking about
I too think this is a very Civil place, and being civil also means to be correctly informed before making an opinion

[oliver jackson]

I'm honestly really sorry I dont mean any negative tone at all, I did read through and I'm trying to be correctly informed but I don't understand. Would you mind explaining it again?

> On 7 Feb 2017, at 02:02, 'Lisandro B' via OpenPnP <ope...@googlegroups.com> wrote:
>
> Oliver, please read the entire discussion and you will see what we are talking about
> I too think this is a very Civil place, and being civil also means to be correctly informed before making an opinion
>

> --
> You received this message because you are subscribed to the Google Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/84ed815a-c37e-4b3d-a246-11cd8f12fb4e%40googlegroups.com.

[Glen English]

For anti -collision I have an algorithm that I use to check if the point is inside a polygon.

I need to to prevent camera crashes.

If it is , it is not permitted to go there unless at Z=0 (which is my safe Z)

Of course, I have a fairly sophisticated bit of software between Open PNP and the actually motion controller (the machine itself)

inspiration came from

http://paulbourke.net/geometry/polygonmesh/

What I need to do is modify it for "Line inside a polygon", I will do that later this with and update GIT.

[Oz-Ron]

Glen that is clever work to avoid collision with known obstacles.  

By collision management I was referring to post collision with unexpected obstacles when things go wrong.  This would be a safety feature. Some Chinese desktop PnP’s do this.

The Smoothie LPC1769 has only one quadrature encoder module, but I am sure there would be ways to use Linear Encoders via Smoothie or other controllers as gross error feedback, or to put it another way, periodic coarse position checks.  

It would need a module to be added to OpenPnP at the very least to respond to an alarm from the motion controller that sensed position did not correspond to commanded position.  Like everything, there would be many ways to do it and that is where discussion & suggestions can lead to an even better project.

 

Ron 

[Trampas Stern]

You can also look at the Smart Stepper boards, like the Nano Zero Stepper http://misfittech.net/product/nano-zero-stepper/

These are simple add on board to your existing stepper motor, just requires gluing a magnet on the back of your stepper motor, see: http://misfittech.net/2016/11/29/installing-the-nano-zero-stepper/

The Smart Steppers then measure the rotational angle of the shaft and turn your motor into a closed loop servo. 

These work with the step/dir/enable signals that is already on your host board so that it requires no to little modification to your controller, for most people it just requires removing the step sticks. 

Using the Smart Steppers you can control the torque of the motor (aka current), so for example you can do collision detection: https://www.youtube.com/watch?v=9BcHgHxcJtc

Also the Smart Steppers do phase prediction which allows stepper motors to move faster than normally possible with step sticks, for example here is unloaded motor running at 750RPM with less than 1 degree of error. Note the limit on the step input is around 50Khz, so around 800RPM with 16x microstepping is about the limit before the error increases too high. 

https://www.youtube.com/watch?v=9EQ9Z9q5NG8&t=2s

Trampas

www.misfittech.net

[Oz-Ron]

Trampas, WOW!  That is really impressive work! How good would it be to harness it into OpenPnp somehow? :-)

[Trampas Stern]

I am working on building my OpenPnP machine currently, I have been a bit slow, as I have also been working on the NEMA23 version of the Smart Steppers. 

I would like to modify smoothie firmware such that it communicates with the Smart Steppers so that limit switches can be removed. This would be nice on the PnP head, that is in theory it could detect when part hits the PCB, or when head touches part during the pick up operation. 

One customer was doing something neat with his Smart Steppers, he was using the USB interface to send back position and error, he was then mapping his machine to see where the binding points were in the machine.  However the applications of such as system is huge, for example from the error mapping in X,Y and Z you can create a model of the system for collision avoidance.

For 3D printers you can use error output to detect when extruder hits bed for bed leveling.  You could use the error output on a CNC mill for doing 3D scanning of objects.  You could also in mill application use the error to zero bit height to stock.  

 

However right now most people are using the boards in 3D printers such that they never miss a step again. For example, often the extruder in a 3D printer puts a blob on the print, then as the next layer is being printed the extruder hits the blob and binds machine such that the stepper motors miss a step. This basically ruins the whole print job, so they love the Smart Steppers in that with it they never miss steps again. 

Trampas

www.misfittech.net

[Lisandro B]

Trampas: congratulations on such a nice development! couple of questions:

I know there has been improvements in hall efect based angular sensors, but how do they compare today with traditional optical encoders? in terms of precision and speed

Have you plan to do a nema 23 version?

In this thread we been talking to use both, motor encoder and linear, what do you thing about making a product with both input? the best system uses dual loop compensation but for "point to point" machines like p&p, a simple end point compensation with some error margin to avoid resonance will suffice.

on a side note, big p&ps use force feedback on the nozzles,  a product such as this one will enable openpnp to set the part regardless of part height or pcb bending ....  nice!

[Trampas Stern]

The Smart Steppers use the AS5047D encoder, this is a 14 bit encoder: https://ams.com/eng/content/download/595083/1609657/file/AS5047D_DS000394_2-00.pdf  

Here is some information on the test results I got during the design stage: http://misfittech.net/2016/09/02/nano-stepper-zero-engineering/

Here I estimated the error to be +/-0.0439 degrees

In general my thoughts are that you need accuracy to the microstep level, so 16x microstepping on a 1.8 degree motor is 0.1125 degrees, this would require an optical encoder with 3200 pulses per rotation.  Again according to my error measurement (not done over temperature, etc) it is possible to achieve this result.  Now do you need this level of accuracy and can your mechanics support it, most likely not. So at some point you reach the limit of diminishing returns.  However the results of the magnetic encoder is very good. 

As far as speed the Smart Steppers are reading the encoder using SPI, it could be done through the ABI interface which is faster. However the AS5047D supports speeds up to 14500 RPM according to datasheet. However I have ran at 20,000 RPM.  The real issue with the speed is that you are not measuring the position accurately, that is you get a position reading but it might have lag. The AS5047D does have some internal speed measurement to compensate the reading for more accurate estimate of position. 

The error in the magnetic encoder will be due more to the calibration than the sensor. That is the Smart Steppers calibrate by moving motor to full step locations, and assuming that each step is 1.8 degrees for a 200 step motor. However motors are not that accurate for each step so this will be the largest part of your error. 

NEMA23

Yes I have ordered production PCBs for a NEMA23 3.2A  12-36Vdc version and have done lots of work on a NEMA23 10A version. I am working on the third PCB spin on the 10A version, which will have 24-48V operation.  I have prototypes of the 10A version that works on the website, http://misfittech.net/product/nema23-high-current-firmware-development-board/,  but I am not happy with the current control method and need a faster processor, hence the board spin.  https://www.youtube.com/watch?v=wavZsEWxjqI

Linear Encoder

Linear encoders are great and would be much better than rotational encoders as the rotational encoder has error due to belts and mechanics. However my opinion, for what it is worth, is that I would rather have rotational and optical. The rotational will get you really close, and the optical can fine tune the last little bit. The optical is already there on most PnP systems and hence is no cost. Additionally optical is the sensor at the point of interest, that is it takes into account all backlashes, mechanical tolerances and everything else.  The biggest problem is getting the camera aligned with the head. so they see close enough to same spot to allow optical alignment.  Then there is the processing time for optical alignment, which of course can be solved with horsepower. 

Finally no amount of encoders and sensors can fix a bad mechanical design, therefore your best bang for the buck is to make good mechanical system first. 

Trampas

www.misfittech.net

Smart Stepper Google Group: https://groups.google.com/forum/#!forum/smart-stepper

[oliver jackson]

When you say optical do you mean using computer vision for compensation?

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f29d318c-90bb-4c5e-a726-ca5d9a588c30%40googlegroups.com.

[Trampas Stern]

correct I mean the camera/vision.