erikj Posted February 18, 2011 Share Posted February 18, 2011 Hi DT Support, I noticed some interesting behavior with soft limits. If I set up soft limits and then initiate a move that will violate one of the limits, the Motor[x].SoftLimit flag is set almost immediately, long before the move is complete. This disagrees with the description in the manual, which says the motor has stopped on a limit. The SoftPlusLimit and SoftMunusLimit forms of the flag do not activate until the limit violation actually occurs. Is this the normal behavior? Also, when the plus or minus soft limit flag is set, the motor stops and the servo loop remains closed. In my particular case, the servo is now closed on the soft limit position and the position value oscillates by +/- 0.5 encoder counts about the limit as the servo works to maintian its position. This causes the limit flag to oscillate as it clears when the position is off the limit and then resets when it moves past the limit. The flag changes at approximately 1 Hz, but appears to be dependent on the hunting of the servo. Is there a way to set bands on the limit violation to avoid the flag oscillating? Thanks, Erik Link to comment Share on other sites More sharing options...
curtwilson Posted February 19, 2011 Share Posted February 19, 2011 Erik: Thanks for reporting the discrepancy in the manual. We will have to revise the description of the SoftLimit status bit to indicate that it gets set when it decides it will have to stop on a software limit, as in your case. It will stay set as long as it is in the "mode" of being stopped on the limit (e.g. until you start to jog out). This is the bit you should be looking at for the operational state of the system. The SoftPlusLimit and SoftMinusLimit bits are transparent, telling you whether the motor position presently exceeds that software limit. This is intentional. Curt Link to comment Share on other sites More sharing options...
Omron Forums Support Posted February 19, 2011 Share Posted February 19, 2011 Regarding the SoftLimit, what you describe occurs by design. To adjust the band in which the PMAC will fluctuate around a set point, use Motor[x].InPosBand. Link to comment Share on other sites More sharing options...
erikj Posted February 21, 2011 Author Share Posted February 21, 2011 Hi Curt and Charles, Thanks for yout replies. I am still seeing this interesting behavior where the motor is stopped on a soft limit but the servo position is oscillating by 1 count (this is 1 count out of 8192 for a full revolution, so it is a very small amount). Motor[x].inPos is 1 the entire time so the motor is in position. However, because the servo is oscillating slightly, moving above and below the limit by 0.5 counts, the SoftPlusLimit flag oscillates as well (see geterrors output below). Is it possible to supress this somehow so that there is only a single notification and the flag reads one constantly to show that the motor is sitting on the limit? Otherwise I will end up sending multiple error notifications in my software for a single limit violation, which is not desired. Also, when the flag temporarily goes to zero, it gives the misleading impression that the motor is no longer on the limit. Thanks, Erik Motor[1].SoftLimit=1 // Initial limit notification because move will cause a limit violationCoord[1].SoftPlusLimit=1 // actual limit violationMotor[1].SoftPlusLimit=1Motor[1].SoftPlusLimit=0 // Subsequent flag oscillations due to servo moving above and below the limit positionCoord[1].SoftPlusLimit=0Coord[1].SoftPlusLimit=1Motor[1].SoftPlusLimit=1Coord[1].SoftPlusLimit=0Motor[1].SoftPlusLimit=0Coord[1].SoftPlusLimit=1Motor[1].SoftPlusLimit=1Coord[1].SoftPlusLimit=0Motor[1].SoftPlusLimit=0Coord[1].SoftPlusLimit=1Motor[1].SoftPlusLimit=1Coord[1].SoftPlusLimit=0Motor[1].SoftPlusLimit=0Coord[1].SoftPlusLimit=1Motor[1].SoftPlusLimit=1Coord[1].SoftPlusLimit=0Motor[1].SoftPlusLimit=0Coord[1].SoftPlusLimit=1Motor[1].SoftPlusLimit=1Coord[1].SoftPlusLimit=0Motor[1].SoftPlusLimit=0 Link to comment Share on other sites More sharing options...
curtwilson Posted February 23, 2011 Share Posted February 23, 2011 Erik: It is on our development list to provide the capability to specify a mask as to which bits are reported by the geterrors routine. After discussion here, we will probably remove SoftPlusLimit and SoftMinusLimit (as well as the corresponding PlusLimit and MinusLimit bits for the hardware limits) from the default mask, as these are not really reporting error events (but they still convey useful information). SoftLimit (and corresponding LimitStop for the HW limits) will remain in the default mask. Curt Link to comment Share on other sites More sharing options...
erikj Posted February 23, 2011 Author Share Posted February 23, 2011 Erik: It is on our development list to provide the capability to specify a mask as to which bits are reported by the geterrors routine. After discussion here, we will probably remove SoftPlusLimit and SoftMinusLimit (as well as the corresponding PlusLimit and MinusLimit bits for the hardware limits) from the default mask, as these are not really reporting error events (but they still convey useful information). SoftLimit (and corresponding LimitStop for the HW limits) will remain in the default mask. Curt Hi Curt, Thanks very much for the reply. One interesting problem is that for a long move the SoftwareLimit flag can go active long before the plus or minus limit flag is set. The motor will keep moving until the plus or minus limit is encountered. If you poll either of these flags while the motor is still moving but before a limit is hit, both flags will read zero, which can be confusing. On another note: do you have any documentation for the output of geterrors? So far I have had to look at what comes out to try and infer possible outputs. I need to parse the strings that come out in order to notify the higher level control system of any problems. Most are pretty straightforward ([x].=), but others are less regularly oriented (CoordExecStatus, ErrorStatus, etc.). Also, there are some status variables printed out at the beginning of a geterrors session (see below). Can you tell me what these mean? Thanks, Erik root@192.168.0.200:/opt/ppmac# geterrors -g0xffffffff -c0x201ffc -m0xc01ffd -r0x1e -t1.000000 Link to comment Share on other sites More sharing options...
erikj Posted February 23, 2011 Author Share Posted February 23, 2011 Erik: It is on our development list to provide the capability to specify a mask as to which bits are reported by the geterrors routine. After discussion here, we will probably remove SoftPlusLimit and SoftMinusLimit (as well as the corresponding PlusLimit and MinusLimit bits for the hardware limits) from the default mask, as these are not really reporting error events (but they still convey useful information). SoftLimit (and corresponding LimitStop for the HW limits) will remain in the default mask. Curt Hi Curt, Thanks very much for the reply. One interesting problem is that for a long move the SoftwareLimit flag can go active long before the plus or minus limit flag is set. The motor will keep moving until the plus or minus limit is encountered. If you poll either of these flags while the motor is still moving but before a limit is hit, both flags will read zero, which can be confusing. On another note: do you have any documentation for the output of geterrors? So far I have had to look at what comes out to try and infer possible outputs. I need to parse the strings that come out in order to notify the higher level control system of any problems. Most are pretty straightforward ([x].=), but others are less regularly oriented (CoordExecStatus, ErrorStatus, etc.). Also, there are some status variables printed out at the beginning of a geterrors session (see below). Can you tell me what these mean? Thanks, Erik root@192.168.0.200:/opt/ppmac# geterrors -g0xffffffff -c0x201ffc -m0xc01ffd -r0x1e -t1.000000 Addendum: Interestingly, the scenario I describe above regarding the SoftLimit flag occurring before the PlusSoftLimit or MinusSoftLimit flags going active will only occur for an indefinite jog (J+ or j-). A programmed move or jog to a specified position will fail with a SoftLimit error and will not be executed in the first place. Link to comment Share on other sites More sharing options...
curtwilson Posted February 25, 2011 Share Posted February 25, 2011 Erik: Atul is putting together information on the "geterrors" functionality. On the soft limit behavior, people want these limits to do a bunch of different things. If a "definite" move, programmed or jog, has a destination past the soft limit, we assume that it was a mistaken command and refuse to do it. In the case of an indefinite jog, it only has the potential for going past the soft limit, and usually will be stopped before this. In our older controllers, we would start to decelerate these moves as they passed the soft limits. In Power PMAC, if the soft limits are enabled, we automatically convert these to definite jog to the limit so we do not go past the limit even if the move is not stopped with another jog command before that. This calculation is done at the beginning of the jog move. Link to comment Share on other sites More sharing options...
Recommended Posts