From: Jon E. <el...@pi...> - 2011-04-28 15:39:57
|
I've been mulling over how to use later Fanuc brushless motors that have the serial encoder. I have gotten just a little bit of data about them. Apparently, they send a 77-bit string at 100K bits/second. So, the readout takes almost a ms. Now, a lot of people would want to convert this to quadrature. One problem shows up immediately, they have 65K and 1 million count/rev versions. At 1800 RPM, the million count encoder would need to send 30 million quadrature counts/second, even the 65K version would send 2 million cts/sec. The encoders take a request command to initiate reading and sending the position. I can see a way to synchronize the readout of the encoder with EMC's reading of the position count, but at a 1 ms servo thread, the first servo cycle would read out the encoder, then during the second servo cycle, a converter board would send the quadrature counts in a burst. Now, the dilemma. I'm not a controls guru, but it seems to me that having a 2 servo cycle delay between position changes and the availability of that position data to the PID component might make tuning really messy. I can also envision making a board that would read the Fanuc serial code directly and make the data available to EMC. At the start of every servo cycle, it would command the encoder to take a reading. Thsi way, there would be an exact one-cycle delay to the data. That should make the PID work a lot better. So, does anyone have any comments on this, especially from a control law perspective? Thanks, Jon |
From: Chris R. <ch...@ti...> - 2011-04-28 16:03:57
|
On Thu, Apr 28, 2011 at 10:39:45AM -0500, Jon Elson wrote: > So, the readout takes almost a ms. Now, a lot of people would want to > convert this to quadrature. > One problem shows up immediately, they have 65K and 1 million count/rev > versions. Converting it to intermediate quadrature seems like a losing proposition. Wouldn't you want the hardware to receive this serial and then present it in HAL directly? By the time you've received all the serial you're already running behind - and now you have to generate a whole mess (arbitrary number?) of quadrature edges at breakneck speed (but slow enough for regular encoder hardware to count them correctly). I can't see how you can even be sure of being able to burst enough edges in another whole servo cycle. If nothing else this will fool a timestamp based sub-period velocity estimate algorithm into giving you something crazy, which defeats our new pid features. It seems like a custom firmware to read the protocol is the way to go here, not custom hardware that tries to convert to quadrature. |
From: Jon E. <el...@pi...> - 2011-04-28 17:56:33
|
Chris Radek wrote: > On Thu, Apr 28, 2011 at 10:39:45AM -0500, Jon Elson wrote: > > >> So, the readout takes almost a ms. Now, a lot of people would want to >> convert this to quadrature. >> One problem shows up immediately, they have 65K and 1 million count/rev >> versions. >> > > Converting it to intermediate quadrature seems like a losing > proposition. Wouldn't you want the hardware to receive this serial > and then present it in HAL directly? Yes, I'm sure you are right. Maybe this is a real "edge" for me! To use these motors with a typical CNC control, you have no choice but to convert to quadrature, and I think we agree this has a big downside. I think I can re-code the encoder board for my PPMC to read the format. I'd need to write a new module to the ppmc driver to accept both position and commutation data, but that won't be a big deal once I decode the data format. > By the time you've received all > the serial you're already running behind - and now you have to > generate a whole mess (arbitrary number?) of quadrature edges at > breakneck speed (but slow enough for regular encoder hardware to count > them correctly). I can't see how you can even be sure of being able > to burst enough edges in another whole servo cycle. > This takes a lot of calculating to make sure the worst-case number of encoder counts can be sent within the available time. At least with my PPMC, I can trigger the encoder to send data synchronized with the EMC servo cycle. What I imagined was to send the serial data during one servo cycle, then send the quadrature counts during the next. This would avoid having the quadrature pulses split across servo cycles, which would cause a dither effect. > If nothing else this will fool a timestamp based sub-period velocity > estimate algorithm into giving you something crazy, which defeats > our new pid features. > Yes, bursting counts would ruin the timestamp velocity estimation. The PPMC doesn't have this feature yet, only the UPC. I will have to work on that, too. > It seems like a custom firmware to read the protocol is the way to go > here, not custom hardware that tries to convert to quadrature. > Yes, I definitely agree. But, this also wrecks the velocity estimation, you only get about one update per ms if the numbers I've been given are right. From the data I have, it works just like a UART, only the data word is 77 bits long. I'm a little worried about staying in sync for 77 asynchronous bits. But, I guess crystal clocks are accurate enough for that. Jon |
From: Chris R. <ch...@ti...> - 2011-04-28 18:32:29
|
On Thu, Apr 28, 2011 at 12:56:21PM -0500, Jon Elson wrote: > Chris Radek wrote: > > If nothing else this will fool a timestamp based sub-period velocity > > estimate algorithm into giving you something crazy, which defeats > > our new pid features. > > Yes, bursting counts would ruin the timestamp velocity estimation. The > PPMC doesn't have this feature yet, only the UPC. I will have to work > on that, too. If you really have 65K-1M per rev, though, dP/dt is going to give you a better than usual velocity estimate. If your hardware can measure the real dt instead of the driver trusting the pc latency to be negligible, even better? |
From: Jon E. <el...@pi...> - 2011-04-29 05:33:55
|
Chris Radek wrote: > If you really have 65K-1M per rev, though, dP/dt is going to give you > a better than usual velocity estimate. If your hardware can measure > the real dt instead of the driver trusting the pc latency to be > negligible, even better? > > Well, this is somewhat confusing. Apparently, these Fanuc encoders have an interpolator that increases the resolution of a basic 2048-line encoder wheel. At low speeds, the absolute position report is good to either 65K or 1 million counts/rev. At some speed, it apparently zeroes out the interpolated part and only reports the 4096 count/rev part direct from the encoder. Probably at those speeds, there is no problem with that, but it seems there might be some kind of discontinuity as the interpolation is switched on and off. Well, as none of this seems to be available in external documents, I will just have to experiment with it. I have a guy sending me a motor to work with. Jon |
From: Peter C. W. <pc...@me...> - 2011-04-29 14:04:07
|
On Fri, 29 Apr 2011, Jon Elson wrote: > Date: Fri, 29 Apr 2011 00:33:49 -0500 > From: Jon Elson <el...@pi...> > Reply-To: EMC developers <emc...@li...> > To: EMC developers <emc...@li...> > Subject: Re: [Emc-developers] Fanuc converter > > Chris Radek wrote: >> If you really have 65K-1M per rev, though, dP/dt is going to give you >> a better than usual velocity estimate. If your hardware can measure >> the real dt instead of the driver trusting the pc latency to be >> negligible, even better? >> >> > Well, this is somewhat confusing. Apparently, these Fanuc encoders have > an interpolator that increases the resolution of a basic 2048-line > encoder wheel. At low speeds, the absolute position report is good to > either 65K or 1 million counts/rev. At some speed, it apparently zeroes > out the interpolated part and only reports the 4096 count/rev part > direct from the encoder. Probably at those speeds, there is no problem > with that, but it seems there might be some kind of discontinuity as the > interpolation is switched on and off. Certainly at high speed the interpolation is not of much use, but the interpolator will of course also go bad at 0 speed. We've considered using such and interpolator with our embedded motion controller to avoid the (expensive if embedded) divide used for velocity estimation. The interpolator is just a second order DPLL, fairly easy to build into the encoder logic, and has the advantage that the velocity falls out directly from the first accumulator. > > Well, as none of this seems to be available in external documents, I > will just have to experiment with it. I have a guy sending me a motor > to work with. > > Jon Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your (")_(") signature to help him gain world domination. |
From: Jon E. <el...@pi...> - 2011-04-29 16:24:57
|
Peter C. Wallace wrote: > Certainly at high speed the interpolation is not of much use, but the > interpolator will of course also go bad at 0 speed. > No, the analog values from the encoder disc should be perfectly accurate at 0 speed. It is just analog sin/cos interpolation of the optical output from the disc. > We've considered using such and interpolator with our embedded motion > controller to avoid the (expensive if embedded) divide used for velocity > estimation. The interpolator is just a second order DPLL, fairly easy to build > into the encoder logic, and has the advantage that the velocity falls out > directly from the first accumulator. > If you are trying to interpolate an already-digital signal, then what you say is true. But, analog interpolation works at zero speed, and can improve positional resolution as well as velocity. Jon |
From: Peter C. W. <pc...@me...> - 2011-04-29 16:30:51
|
On Fri, 29 Apr 2011, Jon Elson wrote: > Date: Fri, 29 Apr 2011 11:24:50 -0500 > From: Jon Elson <el...@pi...> > Reply-To: EMC developers <emc...@li...> > To: EMC developers <emc...@li...> > Subject: Re: [Emc-developers] Fanuc converter > > Peter C. Wallace wrote: >> Certainly at high speed the interpolation is not of much use, but the >> interpolator will of course also go bad at 0 speed. >> > No, the analog values from the encoder disc should be perfectly accurate > at 0 speed. It is just analog sin/cos interpolation of the optical > output from the disc. >> We've considered using such and interpolator with our embedded motion >> controller to avoid the (expensive if embedded) divide used for velocity >> estimation. The interpolator is just a second order DPLL, fairly easy to build >> into the encoder logic, and has the advantage that the velocity falls out >> directly from the first accumulator. >> > If you are trying to interpolate an already-digital signal, then what > you say is true. But, analog interpolation works at zero speed, and can > improve positional resolution as well as velocity. > > Jon Yes, I was thinking digital, The sine/cosine ones typically go bad at higher speeds. Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your (")_(") signature to help him gain world domination. |
From: Brian <tur...@gm...> - 2011-04-30 14:59:34
|
If the problem is bursting that many counts, why not make the converter divide the counts down to something manageable like 2500 per rev? Brian On Fri, Apr 29, 2011 at 12:31 PM, Peter C. Wallace <pc...@me...> wrote: > On Fri, 29 Apr 2011, Jon Elson wrote: > >> Date: Fri, 29 Apr 2011 11:24:50 -0500 >> From: Jon Elson <el...@pi...> >> Reply-To: EMC developers <emc...@li...> >> To: EMC developers <emc...@li...> >> Subject: Re: [Emc-developers] Fanuc converter >> >> Peter C. Wallace wrote: >>> Certainly at high speed the interpolation is not of much use, but the >>> interpolator will of course also go bad at 0 speed. >>> >> No, the analog values from the encoder disc should be perfectly accurate >> at 0 speed. It is just analog sin/cos interpolation of the optical >> output from the disc. >>> We've considered using such and interpolator with our embedded motion >>> controller to avoid the (expensive if embedded) divide used for velocity >>> estimation. The interpolator is just a second order DPLL, fairly easy to build >>> into the encoder logic, and has the advantage that the velocity falls out >>> directly from the first accumulator. >>> >> If you are trying to interpolate an already-digital signal, then what >> you say is true. But, analog interpolation works at zero speed, and can >> improve positional resolution as well as velocity. >> >> Jon > > > Yes, I was thinking digital, The sine/cosine ones typically go bad at higher > speeds. > > > Peter Wallace > Mesa Electronics > > (\__/) > (='.'=) This is Bunny. Copy and paste bunny into your > (")_(") signature to help him gain world domination. > > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Emc-developers mailing list > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-developers > |
From: Peter C. W. <pc...@me...> - 2011-04-30 15:11:57
|
On Sat, 30 Apr 2011, Brian wrote: > Date: Sat, 30 Apr 2011 10:59:26 -0400 > From: Brian <tur...@gm...> > Reply-To: EMC developers <emc...@li...> > To: EMC developers <emc...@li...> > Subject: Re: [Emc-developers] Fanuc converter > > If the problem is bursting that many counts, why not make the > converter divide the counts down to something manageable like 2500 per > rev? > > Brian I think the point was to retain the high count (mainly for better velocity estimation), Since the interface has the raw position data, there really is no need to convert to quadrature at all. Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your (")_(") signature to help him gain world domination. |
From: Jon E. <el...@pi...> - 2011-04-30 19:06:59
|
Brian wrote: > If the problem is bursting that many counts, why not make the > converter divide the counts down to something manageable like 2500 per > rev? > No, I don't think that is the problem. The delay introduced seems to be a minimum of one servo cycle. Maybe by reducing resolution, then the burst of counts could still be fit into the tail end of one servo cycle, so maybe that would be an improvement. The worst case would be to have the burst of counts extend past where EMC2 samples the count, then it could introduce a variable delay in getting the exact position. Jon |
From: Jon E. <el...@pi...> - 2011-05-01 17:43:42
|
Well, after much fooling around, I finally found the magic recipe to make the encoder send a report. It turns out the bit rate is 1 Mbit/second, not 100 K bits/sec. So, the entire report can be sent in about 80 us. That sounds a lot better. It seems there is an absolute position group that contains a count of revs as well as the angular position count, and then a repeat of just the angular part without the rev count, that would be useful for commutation. At the end, there is likely a cyclical redundancy check. One thing that comes to mind is how to handle encoder index. If the angular data resets when it reaches the index pulse, then that is taken care of. If it does, though, that means there is no angular info until the encoder has passed its index position, and thus commutation is not reliable until that point. I'm trying to get away from having to supply battery power to the encoder as Fanuc did, but it might be necessary, but kind of messy. Jon |
From: Dave <EMC@DC9.TZO.com> - 2011-05-02 03:23:23
|
On 5/1/2011 1:43 PM, Jon Elson wrote: > Well, after much fooling around, I finally found the magic recipe to > make the encoder send a report. It turns out the bit rate is 1 > Mbit/second, not 100 K bits/sec. So, the entire report can be sent in > about 80 us. That sounds a lot better. > > It seems there is an absolute position group that contains a count of > revs as well as the angular position count, and then a repeat of just > the angular part without the rev count, that would be useful for > commutation. At the end, there is likely a cyclical redundancy check. > One thing that comes to mind is how to handle encoder index. If the > angular data resets when it reaches the index pulse, then that is taken > care of. If it does, though, that means there is no angular info until > the encoder has passed its index position, and thus commutation is not > reliable until that point. > > I'm trying to get away from having to supply battery power to the > encoder as Fanuc did, but it might be necessary, but kind of messy. > > Jon > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Emc-developers mailing list > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-developers > > That sounds better. I have been told that all absolute encoders lose their rev position on power down. Some controllers apparently write the last rev count to flash memory on power down. Of course if the encoder is rotated through a turn it would never know that on power up since it would use the old rev count and be out of position. Battery backup might be a better option. There is likely a command that you can send to the encoder to zero or preset the encoder. Some systems call that a passive homing routine. Absolute encoder systems can be really handy on machines that are difficult to home with a conventional home switch search. If the encoder always knows where the rotor is at (since the encoder is absolute), isn't commutation pretty simple after the initial angle setting of the rotor position? Dave |
From: Jon E. <el...@pi...> - 2011-05-02 03:54:10
|
Dave wrote: >> There is likely a command that you can send to the encoder to zero or >> preset the encoder. Some systems call that a passive homing routine. >> Yes, that seems very reasonable, but I have no idea how to find out what code to send to the encoder to make it home on index. It was hard enough to figure out how to make it report the position. >> Absolute encoder systems can be really handy on machines that are >> difficult to home with a conventional home switch search. >> I can see this on robots, but it doesn't seem all that big a deal on conventional machine tools. >> If the encoder always knows where the rotor is at (since the encoder is >> absolute), isn't commutation pretty simple after the initial angle >> setting of the rotor position? >> Well, I'd like to skip the battery if I could. But, if the encoder has no idea where it is, and just calls the location on power-up zero, then commutation is NOT simple. Apparently, it may provide the 4-bit Gray code commutation that has been used on earlier Fanuc brushless encoders in that state. That would at least allow the motor to operate. Then, it may send some useful signal when it passes the index position. But, if the encoder is only sampled once per ms, the "index has been seen" indication is not very precise. Hopefully, Fanuc does something more intelligent with it. Jon |
From: Dave <EMC@DC9.TZO.com> - 2011-05-02 15:35:54
|
I stumbled upon this document. Might be helpful. I'm surprised that you don't go into information overload trying to figure this stuff out. http://www.mitchell-electronics.com/downloads/Catalog_PriceList/TI5000EXManual.pdf http://www.mitchell-electronics.com/downloads/Catalog_PriceList/Price%20List%20by%20Part%20Number.pdf Apparently they make encoder test systems. I sure could have used one of these the other day as we found a bad Heidenhain encoder on a new motor but only after a lot of swapping of parts and wasting a lot of time. I think the encoder was zapped when they miss-wired the 24 volt supply into some of the encoder data lines. These guys must know the ins and outs of the Fanuc encoders. Perhaps they would talk to you?? Might be worth a shot if you explain that you are not a competitor. Dave On 5/1/2011 11:53 PM, Jon Elson wrote: > Dave wrote: > >>> There is likely a command that you can send to the encoder to zero or >>> preset the encoder. Some systems call that a passive homing routine. >>> >>> > Yes, that seems very reasonable, but I have no idea how to find out what > code to send to the encoder to make it home on index. It was hard > enough to figure out how to make it report the position. > >>> Absolute encoder systems can be really handy on machines that are >>> difficult to home with a conventional home switch search. >>> >>> > I can see this on robots, but it doesn't seem all that big a deal on > conventional machine tools. > >>> If the encoder always knows where the rotor is at (since the encoder is >>> absolute), isn't commutation pretty simple after the initial angle >>> setting of the rotor position? >>> >>> > Well, I'd like to skip the battery if I could. But, if the encoder has > no idea where it is, and just calls the location on power-up zero, then > commutation is NOT simple. Apparently, it may provide the 4-bit Gray > code commutation that has been used on earlier Fanuc brushless encoders > in that state. That would at least allow the motor to operate. Then, > it may send some useful signal when it passes the index position. But, > if the encoder is only sampled once per ms, the "index has been seen" > indication is not very precise. Hopefully, Fanuc does something more > intelligent with it. > > Jon > > > |
From: Jon E. <el...@pi...> - 2011-05-02 16:41:39
|
Dave wrote: > I stumbled upon this document. Might be helpful. I'm surprised that > you don't go into information overload trying to figure this stuff out. > > http://www.mitchell-electronics.com/downloads/Catalog_PriceList/TI5000EXManual.pdf > > http://www.mitchell-electronics.com/downloads/Catalog_PriceList/Price%20List%20by%20Part%20Number.pdf > > Apparently they make encoder test systems. I sure could have used one > of these the other day as we found a bad Heidenhain encoder on a new > motor but only after a lot of swapping of parts and wasting a lot of time. > I think the encoder was zapped when they miss-wired the 24 volt supply > into some of the encoder data lines. > > These guys must know the ins and outs of the Fanuc encoders. Perhaps > they would talk to you?? Might be worth a shot if you explain that you > are not a competitor. > Hah, I seriously doubt it. They probably went to a LOT of trouble to figure all this stuff out. One of these boxes is about $5000! Anyway, the document gave almost no info on the encoder communication. Jon |
From: Dave <EMC@DC9.TZO.com> - 2011-05-02 21:51:23
|
On 5/2/2011 12:41 PM, Jon Elson wrote: > Dave wrote: > >> I stumbled upon this document. Might be helpful. I'm surprised that >> you don't go into information overload trying to figure this stuff out. >> >> http://www.mitchell-electronics.com/downloads/Catalog_PriceList/TI5000EXManual.pdf >> >> http://www.mitchell-electronics.com/downloads/Catalog_PriceList/Price%20List%20by%20Part%20Number.pdf >> >> Apparently they make encoder test systems. I sure could have used one >> of these the other day as we found a bad Heidenhain encoder on a new >> motor but only after a lot of swapping of parts and wasting a lot of time. >> I think the encoder was zapped when they miss-wired the 24 volt supply >> into some of the encoder data lines. >> >> These guys must know the ins and outs of the Fanuc encoders. Perhaps >> they would talk to you?? Might be worth a shot if you explain that you >> are not a competitor. >> >> > Hah, I seriously doubt it. They probably went to a LOT of trouble to > figure all this stuff out. > One of these boxes is about $5000! > > Anyway, the document gave almost no info on the encoder communication. > > Jon > > > A lot more than I knew (not saying much ;-) ). Those Fanuc encoders are not absolute SSI type gray scale or binary encoders, they are incremental with electronics attached. That's why they need the battery backup - to keep the electronics alive. Big difference. I'd call them if I were you. The worse thing that could happen is that they could slam the phone down on you! :-) The best thing is that you get some tech who tells all and sends you supporting docs. :-) $5000... yes but what do those Fanuc motors cost if you were to buy a replacement from Fanuc?? The two axes Allen Bradley servo card I was working with last week has two SSI encoder inputs, and two +/- Analog outputs for the servo drives. The card is about 5 inches square, a single board and it has a plastic bezel on the front about 1 1/2" wide. It costs $2500 (after a hefty discount) and requires a PLC CPU, a PLC Rack, and a PLC power supply. There were 4 similar cards in the PLC rack I was working on. When I called AB tech support they wouldn't talk to me unless I supplied a TechConnect support contract number that the customer also had to pay for. (Apparently AB needs the money.. the poor souls) You should figure these things out and then sell a Fanuc encoder debugger for $2500 - half the going price! Dave |
From: Jon E. <el...@pi...> - 2011-05-06 03:02:55
|
Well, I have the first cut at the Fanuc absolute encoder test unit working. I pretty much verified what I got off the oscilloscope, but in better detail. I am guessing there may be other commands that can be sent to the encoder to get other data and functions. But, anyway, what this particular unit provides is : A 15-bit angular position count and a 14-bit revolution count that are reset the first time the index position is passed. This can be read as a contiguous 29-bit signed binary number. A 15-bit unsigned angular position that is relative to where the encoder was when power was turned on. This does not reset when it passes index. These counts both have a bunch of LSB zeros to accommodate encoders with higher resolution. There seems to be an encoder model ID at the beginning and a 4-bit checksum at the end. I didn't find any sign of commutation info in the data stream I am getting now, so it would be hard to make a servo drive move the motor to the index position during the homing operation. But, I have seen the traditional Fanuc C1-C2-C4-C8 commutation signals on the encoder's PCB test points, so there probably is a different command that will make it send this info. Jon |
From: Dave <EMC@DC9.TZO.com> - 2011-05-06 12:39:08
|
http://www.renishaw.nl/nl/resolute-absolute-optische-encoder-protocollen-voor-seriele-communicatie--11018 I don't know if it would be worthwhile or not, but apparently Fanuc licenses their encoder protocols to various companies like Renishaw ... as mentioned in the link above. Dave http://www.renishaw.com/en/resolute-absolute-optical-encoder-fanuc-serial-protocol--11042 On 5/5/2011 11:02 PM, Jon Elson wrote: > Well, I have the first cut at the Fanuc absolute encoder test unit > working. I pretty much verified what I got off the oscilloscope, but in > better detail. I am guessing there may be other commands that can be > sent to the encoder to get other data and functions. But, anyway, what > this particular unit provides is : > A 15-bit angular position count and a 14-bit revolution count that are > reset the first time the index position is passed. > This can be read as a contiguous 29-bit signed binary number. > A 15-bit unsigned angular position that is relative to where the encoder > was when power was turned on. > This does not reset when it passes index. > These counts both have a bunch of LSB zeros to accommodate encoders with > higher resolution. > There seems to be an encoder model ID at the beginning and a 4-bit > checksum at the end. > I didn't find any sign of commutation info in the data stream I am > getting now, so it would be hard to make a servo drive move the motor to > the index position during the homing operation. But, I have seen the > traditional Fanuc C1-C2-C4-C8 commutation signals on the encoder's PCB > test points, so there probably is a different command that will make it > send this info. > > Jon > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Emc-developers mailing list > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-developers > > |
From: Jon E. <el...@pi...> - 2011-05-06 16:47:46
|
Dave wrote: > http://www.renishaw.nl/nl/resolute-absolute-optische-encoder-protocollen-voor-seriele-communicatie--11018 > > I don't know if it would be worthwhile or not, but apparently Fanuc > licenses their encoder protocols to various companies like Renishaw > ... as mentioned in the link above. > Interesting, I don't think this is the same protocol as the encoders I have. Also, they probably license it so other vendors encoders can be used with their controls, and not the other way around. Thanks, Jon |
From: Jon E. <el...@pi...> - 2011-05-12 04:00:13
|
Well, I think I have figured out most of what this encoder can do. It seems to have a 16-bit binary count per revolution plus a 16-bit signed count of revolutions, and these are battery-backed. It also has a 10-bit count of absolute angle per quadrant. If the backup battery doesn't save the high-res position, then it starts off counting from zero, and then jumps back to zero when it passes the index mark the first time. There is a bit to indicate it has found the index mark. So, I think I can see how one could use this with EMC, but it is just a little bit crude to deal with homing if you don't want to deal with the battery. What I am thinking is the 10-bit absolute angle could be sent to the bldc component for initial commutation alignment. The high-res angle part could be used, but the driver would have to watch for the jump when it passed the index the first time, and fudge the count with an offset so it didn't cause a following error. This fudging would be crude, as the encoder might only be sampled at 1 KHz. I guess the last velocity could be used to figure out about how fast you were moving each sample. Then, when the homing sequence searched for the index, the fudging offset could be removed when the rotation sign bit changed, and the system would be perfectly aligned at the index mark of the encoder. Only the 16-bit angular count would be used, and the driver could sign-extent the value for multiple rotations. There are two things I'm trying to accomplish with all this. First, if you don't use a backup battery, the encoder count jumps suddenly when it passes the index position the first time after power on. Second, there doesn't seem to be a command you can send to the encoder to zero the count at index. And, since the encoder is only sampled at some rate (about 10 KHz is the maximum) then you are likely to miss the exact moment when the index pulse is passed when homing, so you have to just accept that it happened recently, and the encoder count WAS zero at that moment. One other concern I have is that if the motor was to be rotated while encoder power was off, I believe the battery-backed count would no longer be correct. This seems to be a serious flaw in this serial absolute encoder scheme. Now, maybe the encoder actually re-zeroes EVERY time it passes the index position, so what would usually be a small error won't accumulate. (If you moved it more than a turn, then the count of turns would certainly be off.) So, anybody have any comments on this? There probably are quite a number of machines out there with these encoders on them, all newer than the very first series of AC "red cap" motors. Jon |
From: dave <den...@ch...> - 2011-05-12 04:47:44
|
On Wed, 2011-05-11 at 23:00 -0500, Jon Elson wrote: > Well, I think I have figured out most of what this encoder can do. It > seems to have a 16-bit binary count per revolution plus a 16-bit signed > count of revolutions, and these are battery-backed. It also has a > 10-bit count of absolute angle per quadrant. > > If the backup battery doesn't save the high-res position, then it starts > off counting from zero, and then jumps back to zero when it passes the > index mark the first time. There is a bit to indicate it has found the > index mark. > > So, I think I can see how one could use this with EMC, but it is just a > little bit crude to deal with homing if you don't want to deal with the > battery. > > What I am thinking is the 10-bit absolute angle could be sent to the > bldc component for initial commutation alignment. > The high-res angle part could be used, but the driver would have to > watch for the jump when it passed the index the first time, and fudge > the count with an offset so it didn't cause a following error. This > fudging would be crude, as the encoder might only be sampled at 1 KHz. > I guess the last velocity could be used to figure out about how fast you > were moving each sample. Then, when the homing sequence searched for > the index, the fudging offset could be removed when the rotation sign > bit changed, and the system would be perfectly aligned at the index mark > of the encoder. Only the 16-bit angular count would be used, and the > driver could sign-extent the value for multiple rotations. > > There are two things I'm trying to accomplish with all this. First, if > you don't use a backup battery, the encoder count jumps suddenly when it > passes the index position the first time after power on. Second, there > doesn't seem to be a command you can send to the encoder to zero the > count at index. And, since the encoder is only sampled at some rate > (about 10 KHz is the maximum) then you are likely to miss the exact > moment when the index pulse is passed when homing, so you have to just > accept that it happened recently, and the encoder count WAS zero at that > moment. > > One other concern I have is that if the motor was to be rotated while > encoder power was off, I believe the battery-backed count would no > longer be correct. This seems to be a serious flaw in this serial > absolute encoder scheme. Now, maybe the encoder actually re-zeroes > EVERY time it passes the index position, so what would usually be a > small error won't accumulate. (If you moved it more than a turn, then > the count of turns would certainly be off.) > > > So, anybody have any comments on this? There probably are quite a > number of machines out there with these encoders on them, all newer than > the very first series of AC "red cap" motors. > > > Jon How serious is the problem of using the battery, i.e. what is the expected life of the battery? Is the a real maintenance problem? Of course, the next question is accessibility to replace the battery and the cost. How do Fanuc people deal with this in the field? D > > ------------------------------------------------------------------------------ > Achieve unprecedented app performance and reliability > What every C/C++ and Fortran developer should know. > Learn how Intel has extended the reach of its next-generation tools > to help boost performance applications - inlcuding clusters. > http://p.sf.net/sfu/intel-dev2devmay > _______________________________________________ > Emc-developers mailing list > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-developers |
From: Jon E. <el...@pi...> - 2011-05-12 16:20:26
|
dave wrote: > > How serious is the problem of using the battery, i.e. what is the > expected life of the battery? Is the a real maintenance problem? > Of course, the next question is accessibility to replace the battery and > the cost. > > How do Fanuc people deal with this in the field? > Fanuc recommends replacing the 4 alkaline cells (I'm guessing AA size) every year, while the machine is powered on. What has me worried is the battery only backs up the position count in a memory chip, it doesn't power the encoder. So, if the machine is bumped while control power is off, the alignment would be wrong. I'm not sure, it may correct itself the next time it passes the index position, but there would then be a discontinuity in position at that moment, likely to cause a servo following error. Also, they have this procedure for indexing the encoder any time the power has been lost (swap motors, replace cables, etc.) You release the brakes (if any) and manually crank the machine to be close to the home position, power the encoder on and then crank it past the home index position. This sets the revolution count to zero over your home position. If I could get this type of encoder to work with the way EMC2 does homing, I'd feel a lot more comfortable with it. A couple months ago I could have gotten a motor with the serial encoder for under $100 on eBay, now it looks like they are all over several hundred $, even the broken ones. Well, I can keep this loaner for a while. Jon |
From: dave <den...@ch...> - 2011-05-12 17:07:28
|
On Thu, 2011-05-12 at 11:20 -0500, Jon Elson wrote: > dave wrote: > > > > How serious is the problem of using the battery, i.e. what is the > > expected life of the battery? Is the a real maintenance problem? > > Of course, the next question is accessibility to replace the battery and > > the cost. > > > > How do Fanuc people deal with this in the field? > > > Fanuc recommends replacing the 4 alkaline cells (I'm guessing AA size) > every year, while the machine is powered on. > What has me worried is the battery only backs up the position count in a > memory chip, it doesn't power the encoder. So, if the machine is bumped > while control power is off, the alignment would be wrong. I'm not sure, > it may correct itself the next time it passes the index position, but > there would then be a discontinuity in position at that moment, likely > to cause a servo following error. > > Also, they have this procedure for indexing the encoder any time the > power has been lost (swap motors, replace cables, etc.) You release the > brakes (if any) and manually crank the machine to be close to the home > position, power the encoder on and then crank it past the home index > position. This sets the revolution count to zero over your home position. > If I could get this type of encoder to work with the way EMC2 does > homing, I'd feel a lot more comfortable with it. > > A couple months ago I could have gotten a motor with the serial encoder > for under $100 on eBay, now it looks like they are all over several > hundred $, even the broken ones. Well, I can keep this loaner for a while. > > Jon Yep! Ebay is unpredictable. Sometimes this is good; other times not. What are you using for electronics to examine the encoder output? I keep thinking about an encoder with that resolution directly on the shaft of an indexer or even an A, B or C axis. Then again, maybe 10K counts/rev is good enough, using my usual 2500 ppr Koyo encoders. On my machines the computer is powered by 120V single phase and is independent of the 3 phase used for spindle, servo drives, etc. The computer is powered up all the time so any movement is tracked. Don't know if this is practical for everyone. Dave > > ------------------------------------------------------------------------------ > Achieve unprecedented app performance and reliability > What every C/C++ and Fortran developer should know. > Learn how Intel has extended the reach of its next-generation tools > to help boost performance applications - inlcuding clusters. > http://p.sf.net/sfu/intel-dev2devmay > _______________________________________________ > Emc-developers mailing list > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-developers |
From: Jon E. <el...@pi...> - 2011-05-13 01:41:46
|
dave wrote: > > What are you using for electronics to examine the encoder output? > My Universal PWM Controller has all the hardware needed, so I just made a different encoder module in the VHDL language to read the serial stream verbatim, and send it as ten bytes. It is not in any way a "finished product", just entirely a prototype hack. > I keep thinking about an encoder with that resolution directly on the > shaft of an indexer or even an A, B or C axis. Then again, maybe 10K > counts/rev is good enough, using my usual 2500 ppr Koyo encoders. > The aA1000 is one million counts/rev (actually I am guessing 1048576 or 2 ^ 20) just the same device with higher interpolation, I think.) > On my machines the computer is powered by 120V single phase and is > independent of the 3 phase used for spindle, servo drives, etc. > The computer is powered up all the time so any movement is tracked. > Don't know if this is practical for everyone. > Well, I'm sure that's the way most people run their Fanuc-controlled machines, the only time they are powered off is when the power goes out, or they are being serviced. Jon |