andyf

We are still having issues getting this module into OP mode. To answer your questions: (1) The default conversion time is 250ms. Is that longer than the Power Brick AC EtherCAT cycle time? Since we are only using I/O modules and need data once per second, can we slow down the Power Brick AC EhterCAT cycle time? (2) The EL3314-0010 does not support distributed clocks

It seems that the File Depot does not contain a complete set of User Manuals for the accessories. For example, I cannot find the user manuals for the ACC65E nor the ACC84E. Could you please post those there as well?

That seems to have fixed the problem! Thank you!

We have a motor using Renishaw Resolute 26 bit BissC absolute serial encoder that is being controlled from a PowerBrick AC with the BissC option (ACC84B card). When moving the motor and monitoring the PosErr using the IDE scope, we occasionally see spikes on the order of 200,000 motor units. This error is seen only on a single phase cycle, and then goes away. This does not seem to impact the motion performance, but we are curious why this is occurring. I thought maybe the encoder clock frequency was too fast for our cable lengths, but our cables are ~9m, and Renishaw recommends 1MHz clock frequency for cable lengths up to 20m without any line delay compensation. We are using the encoder for phase commutation and servo loop. Phase clock is 9.035KHz and encoder clock is 1MHz BissC (SerialEncCtrl=$63000B). Do you have any ideas why these spikes may be occurring? Config file and plot screen show attached.

Just to close this out, I did receive an answer directly via email from tech support as follows: "Not at 3.3V but it would depend on the device. Some TTL drivers will output 5V with a 5V pullup resistor."

Thanks Steve. Regarding the flag inputs, I see the manual calls for 5V-24V. Do you think these might work at TTL level, such as 3.3V?

Thanks Richard. After reading more yesterday about the Motor[x] setup elements, I convinced myself those are only for the PMAC software servo to know where to read from hardware registers. But what I need is to configure the encoder gate hardware to latch position on chan[0] when index goes high on chan[1], and put the latched value in the h/w register chan[0].HomeCapt.a. I don't see a way to do this with the Gate3[].Chan[] setup elements.

I would like to capture position of Motor[1] running on Gate3[0].Chan[0] in hardware upon the presence of an index pulse on Gate3[0].Chan[1]. It seems the position capture settings on the channel only support doing this with flags (CaptFlagChan and CaptFlagSel). Is it possible to do what I want by setting Motor[1].CaptureMode=0 and changing Motor[1].pCaptFlag to point to Gate3[0].Chan[1].Status.a ?

I have a Parker SM232A 3 phase brushless DC motor with: Instantaneous current: 8.3 A peak Continuous current: 2.8 A peak Direct PWM driven by Power PMAC and 3U042 amplifier 4/8 A rms If I follow the Power PMAC User's Guide for calculating maxdac and i2tset by hand I get the following: maxdac = (8.3/13.01) * (32768 * .866) = 18103 i2tset = (2.8/13.01) * (32768 * .866) = 6107 However when setting this up using IDE motor setup it calculates: maxdac = 20904 i2tset = 7052 It seems the values from motor setup seem to ignore the .866 required for 3-phase calculation. Please advise.

No resolution found at this time. I have been told older model 3U042 amps do not support this. Out amps were purchased between 2011 and 2014. We will send serial numbers to DT support to confirm feature set.

I am using a 3U042 on the second ACC24E3 card in our Power UMAC, first channel (acc24e3[1].chan[0]). I tried this with the jumper pulled out as you suggested. The amp display switches to 1E6, but I still do not see a 6 written to the 4th hex digit in the watch window. What I do see is an F written to the fifth hex digit, but then cleared to 0. Sys.Uhex[1]=acc24e3[1].chan[0].adcampa[0] Sys.Uhex[1] The values I am seeing are 0x00X000X0 where the X hex digits are rapidly changing. When the OT trips I am seeing: 0x00XF00X0 for a second, then back to 0x00X000X0 I even waited 60 seconds until the amp faulted but I still did not see to 6 written.

That's good to know. However I am only interested in how to detect the PTC input state. Is that also in these 8 bits of the B-phase?

We are using ACC24E3. I tried your suggestion out using the 3U042, and what I see is when the motor is running the value of those 8 bits toggles between $F0 and $FF, then when the over temp occurs it toggles between $00 and $0F. This is different than what I expected, since the 3U042 manual states it will write a "06" to the register. Am I missing something, or is the manual wrong and I should simply monitor for the top 4 bits to be $0? p1 = acc24e3[1].chan[0].adcamp[0].a - sys.piom p1 = 9453600 = $904020 ptr EnhancedModeBits->u.io:$904020.12.8 I also noticed in your post you first referenced using AdcAmp[1] but in the example used AdcAmp[0]. I tried both, and only saw non-zero values when using AdcAmp[0].

Update, with a larger potentiometer we were able to trigger the over temp at 1.2K.

We are using 3U081 and 3U042 amplifiers with motors that have integrated PTC. Two questions: 1) For the 3U042, we used a potentiometer and determined the amp detects over temp at about 300 Ohms, which is 90 degrees C on the motor PTC. The 3U042 manual states that a PLC should monitor the ADC A register bits 11:4 for the '06' status. What PMAC data element is the ADC A register, and is there a helper data element available for the specific bits? 2) For the 3U081, the connected motor is rated for 100 degrees C, which corresponds to 1K resistance. However testing at 1K resistance with a potentiometer we do not see the amp detect over temp. What is the threshold of the over temp circuit on the 3U081 amp?

Our servo motors run in an observatory environment that is sensitive to heat. As such we would like to turn the motors off once they have been moved into position. Our approach to this is to outfit each motor with a brake, and once a move is complete open the servo loop and engage the brake. The problem we are running into is that we run these motors through a series of moves for hours using a motion program, primarily for the coordinate system timing features (i.e. external time base). Since motion programs require the servo loop to be closed, it seems we cannot open the servo loop after each move. Do you have any suggestions for how to solve this problem?

Our servo motors run in an observatory environment that is sensitive to heat. As such we would like to turn the motors off once they have been moved into position. Our approach to this is to outfit each motor with a brake, and once a move is complete open the servo loop and engage the brake. The problem we are running into is that we run these motors through a series of moves for hours using a motion program, primarily for the coordinate system timing features (i.e. external time base). Since motion programs require the servo loop to be closed, it seems we cannot open the servo loop after each move. Do you have any suggestions for how to solve this problem?

Interestingly, this motor is water cooled and we were running thermal tests when this issue came up. Given that the motor is water cooled, we will use the thermal measurements to compute a more appropriate I2TSet. Thanks for your inputs!

Interestingly, this motor is water cooled and we were running thermal tests when this issue came up. Given that the motor is water cooled, we will use the thermal measurements to compute a more appropriate I2TSet. Thanks for your inputs!

Thanks Curt. I did monitor the I2TSum and noticed it is increasing until it eventually exceeds I2TTrip. I believe I can increase I2TTrip since I had used 1 sec for time allowed in the calculation, when it is likely 2 sec (need to check). Yes, we have use cases where the motor has to run like this for hours. Is the fact that I2T trips after some time mean there is a problem, or is this just a side effect of the I2T trip safety? If the latter, what workaround do you suggest?

Thanks Curt. I did monitor the I2TSum and noticed it is increasing until it eventually exceeds I2TTrip. I believe I can increase I2TTrip since I had used 1 sec for time allowed in the calculation, when it is likely 2 sec (need to check). Yes, we have use cases where the motor has to run like this for hours. Is the fact that I2T trips after some time mean there is a problem, or is this just a side effect of the I2T trip safety? If the latter, what workaround do you suggest?

It is a phasing search move. With the approach you describe, do I need to step it off the limit by enough that the phasing will not encounter the limit again, or just enough so that the limit is not active?

It is a phasing search move. With the approach you describe, do I need to step it off the limit by enough that the phasing will not encounter the limit again, or just enough so that the limit is not active?

If a motor is on a soft or hard limit, the motor will not phase. One way around this is to temporarily disable soft/hard limits when phasing. Are there any other ways around this?

If a motor is on a soft or hard limit, the motor will not phase. One way around this is to temporarily disable soft/hard limits when phasing. Are there any other ways around this?