piefum Posted July 5, 2010 Share Posted July 5, 2010 Hi All I am very interested in the use of two ACC-84E with a series of 6 Heidenhain EQN 437 Encoders (multiturn, full digital endat2.2) for a Stewart platform. First of all,how can I use the commutation/on going track of the encoder that has 25 bit per revolution. Am I limited to the 24 bit of the EncoderConversionTable? Then, I'd like to know if it is possible to read the Endat2.2 additional information via the ACC-84E (in my application, it will be very useful to read the temperatures of the six sensors). The manual does not cite any information on how to read the Endat additional information, but these information are standard in the endat2.2 protocol, so I'm assuming that a PLC can easily read them. thanks gigi Link to comment Share on other sites More sharing options...
Sina.Sattari Posted July 6, 2010 Share Posted July 6, 2010 [quote='piefum' pid='489' dateline='1278334754'] Hi All I am very interested in the use of two ACC-84E with a series of 6 Heidenhain EQN 437 Encoders (multiturn, full digital endat2.2) for a Stewart platform. First of all,how can I use the commutation/on going track of the encoder that has 25 bit per revolution. Am I limited to the 24 bit of the EncoderConversionTable? Then, I'd like to know if it is possible to read the Endat2.2 additional information via the ACC-84E (in my application, it will be very useful to read the temperatures of the six sensors). The manual does not cite any information on how to read the Endat additional information, but these information are standard in the endat2.2 protocol, so I'm assuming that a PLC can easily read them. thanks gigi [/quote] The ACC-84E reads the whole 25-bits of information. As the manual indicates, you only need to read the whole absolute position once upon start-up and then the ECT will take care of 24-bit roll-over issue as long as your speeds are less than 23-bit per servo cycle. Although the ACC-84E communicates with the EnDat 2.2 encoder, only two modes are supported (1) reading the position (2) resting the encoder error flag. Unfortunately we don't support reading the temperature mode. Link to comment Share on other sites More sharing options...
curtwilson Posted July 7, 2010 Share Posted July 7, 2010 The commutation source in Turbo PMAC is limited to a 24-bit cycle (16M LSBs) by Ixx71. Your encoder has 25 bits per mechanical revolution (32M LSBs). However, if you have a 4-pole motor, which is likely, your commutation cycle is still within the 24-bit range. You will be able to set Ixx71 to the maximum value of 16,777,215, and Ixx70 to 1, to specify your cycle size. (Note: Technically, the commutation cycle would be 16,777,216 LSBs in this case. If your motor could travel hundreds of thousands of revolutions, this might be a problem, as it would get 2 LSBs off per mechanical revolution. But I doubt this will be a problem in a Stewart platform. Even after 1024 mechanical revolutions, the torque reduction from the accumulated error is one part in a million.) From a theoretical viewpoint, the ideal thing would be to set Ixx83 to read the "SerialDataA" register on the ACC-84E directly every phase cycle (after setting up the 84E to read the encoder every phase cycle, not just every servo cycle). Set Ixx01 to 3 to specify a Y-register read. This minimizes the delay in getting the encoder position. If you process the data value in the conversion table "unshifted" (recommended for this high resolution), you could also read the 24-bit result in the conversion table. It is slightly delayed for use in the next phase cycle(s), but in actual use, we have not seen this be a problem. If your commutation cycle is really bigger than 16M LSBs of your encoder, then you must use an encoder conversion table entry to "strip off" one or more of the low bits (by telling it to start at bit 1 or higher of the source register). If you want to keep full resolution in the servo loop, this will have to be a separate entry from what you use for servo feedback. Link to comment Share on other sites More sharing options...
piefum Posted July 8, 2010 Author Share Posted July 8, 2010 first of all, thanks to all for your kind help! [quote='curtwilson' pid='493' dateline='1278528262'] The commutation source in Turbo PMAC is limited to a 24-bit cycle (16M LSBs) by Ixx71. Your encoder has 25 bits per mechanical revolution (32M LSBs). However, if you have a 4-pole motor, which is likely, your commutation cycle is still within the 24-bit range. You will be able to set Ixx71 to the maximum value of 16,777,215, and Ixx70 to 1, to specify your cycle size. [/quote] my first application with the 25bit_per_rev/endat22 encoder is with a stepper motor in a high reduction gearbox. So, i'm not going to use any commutation. We build two kind of actuators for out stewart platform: - direct drive, with huge torque motor and, at least, 10 pair of poles - gearhead drive, with small 4- or 5- pole motor I use the heidenhain encoder for commutation only for the direct drive solution, so I think I will be fine for future applications [quote='curtwilson' pid='493' dateline='1278528262'] (Note: Technically, the commutation cycle would be 16,777,216 LSBs in this case. If your motor could travel hundreds of thousands of revolutions, this might be a problem, as it would get 2 LSBs off per mechanical revolution. But I doubt this will be a problem in a Stewart platform. Even after 1024 mechanical revolutions, the torque reduction from the accumulated error is one part in a million.) [/quote] yes, exactly. [quote='curtwilson' pid='493' dateline='1278528262'] If you want to keep full resolution in the servo loop, this will have to be a separate entry from what you use for servo feedback. [/quote] this is exactly what I want: use the full 25 bit information for the repositioning. How can I implement this? thanks a lot gigi Link to comment Share on other sites More sharing options...
curtwilson Posted July 8, 2010 Share Posted July 8, 2010 You do not need to read the full 25 bits of single-turn information (which itself is only a fraction of the full position information) every servo cycle. You only need to read enough bits, starting from the LSB, that you know which way you have traveled since the last servo cycle. This means you cannot go "halfway around" the range of positions you do read in a single servo cycle, because we assume you traveled the shorter distance between the two values. (If you formally studied digital sampling theory in school, you will recognize this as the same phenomenon as in the Nyquist Sampling Theorem.) With the low 24 bits covering half a motor revolution, you could go up to 1/4 of a revolution in a servo cycle. With a 2 kHz servo, you could go up to 30,000rpm. With a 5 kHz servo, you could go up to 75,000rpm. Link to comment Share on other sites More sharing options...
Recommended Posts