Jump to content
OMRON Forums

Recommended Posts

Posted

I have a motion program with a indefinite while loop moving a motor back and forth...

 

inc

linear

 

while(1) {

x1000 tm233

delay 133

x-1000 tm233

delay 133

}

 

The motor moves fine for about 6 minutes and then the program aborts with the I2TFault==1 and AmpFault==1. Because the abort seems to occur repeatedly at about 6 minutes, I an wondering if there is something in the motion program that may be causing this. Any ideas?

  • Replies 13
  • Created
  • Last Reply

Top Posters In This Topic

Posted
OK perhaps this is just an I2t trip that occurs after some time. I am just surprised it never occurs right away, but always after about 6 minutes. I will try increasing the I2T limits.
Posted
You can monitor the status element Motor[x].I2tSum, which contains the instantaneous value of the time-integrated value above the continuous limit. When this exceeds I2tTrip, you get the fault. I suspect you will find that it is slowly increasing over the minutes. This limit may well be doing exactly what it is supposed to do -- it is common for these faults to appear after significant time.
Posted
You can monitor the status element Motor[x].I2tSum, which contains the instantaneous value of the time-integrated value above the continuous limit. When this exceeds I2tTrip, you get the fault. I suspect you will find that it is slowly increasing over the minutes. This limit may well be doing exactly what it is supposed to do -- it is common for these faults to appear after significant time.
Posted

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?

Posted

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?

Posted

The intent of the I2T feature is to guard against overheating your hardware by generating heat faster than it can be dissipated. PMAC's I2T feature is mainly intended to protect the motor, as most drives have their own internal protection of this type.

 

Implicitly, it uses a simple and generic thermal model. The I2tSet parameter represents a current level that you can run at continuously without overheating. That is, running at this current level continuously, the motor should reach a reasonable steady-state temperature.

 

If you have a "bad" (overly conservative) setting, it is more likely to be this I2tSet parameter than the I2tTrip limit you are considering. If you just increase I2tTrip, repeating your sequence indefinitely will eventually cause the running I2tSum value to increase enough that you get a trip.

 

To nail this down properly, you will need to see how the motor temperature changes under different conditions. Ideally, this would be with thermocouple measurement, but possible an IR thermometer could be used as well.

Posted

The intent of the I2T feature is to guard against overheating your hardware by generating heat faster than it can be dissipated. PMAC's I2T feature is mainly intended to protect the motor, as most drives have their own internal protection of this type.

 

Implicitly, it uses a simple and generic thermal model. The I2tSet parameter represents a current level that you can run at continuously without overheating. That is, running at this current level continuously, the motor should reach a reasonable steady-state temperature.

 

If you have a "bad" (overly conservative) setting, it is more likely to be this I2tSet parameter than the I2tTrip limit you are considering. If you just increase I2tTrip, repeating your sequence indefinitely will eventually cause the running I2tSum value to increase enough that you get a trip.

 

To nail this down properly, you will need to see how the motor temperature changes under different conditions. Ideally, this would be with thermocouple measurement, but possible an IR thermometer could be used as well.

Posted
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!
Posted
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!
Posted

Looking at your test program, the key variable for determining the power dissipated is not in the program -- the acceleration parameter(s).

 

To test what level of continuous current your motor can tolerate, I would do repeated moves that are always accelerating and decelerating at a constant rate: TA=TM, TS=0, and only a momentary stop between moves (DWELL 0).

Posted

Looking at your test program, the key variable for determining the power dissipated is not in the program -- the acceleration parameter(s).

 

To test what level of continuous current your motor can tolerate, I would do repeated moves that are always accelerating and decelerating at a constant rate: TA=TM, TS=0, and only a momentary stop between moves (DWELL 0).

Guest
This topic is now closed to further replies.

×
×
  • Create New...