Jump to content
OMRON Forums

Fatal Following Error - different triggering philosophy


piefum
 Share

Recommended Posts

Hi All

I think I have a noise issue on a Hexapod system that has been just put on field. This problem was never detected at my laboratory.

 

The problem is that I have a bad encoder reading once in a while (every few min) and this is causing a triggering of fatal following error, stopping the machine in an error state.

 

I assume that the error comes from noise because if I read at high frequency the foll err (using pmacPlotPro with gather period = 1), I see that the following error is almost constant at few counts, and then immediately it jumps to 30000 counts (triggering the fatal foll err).

 

I had this kind of problem a few years ago and I solved this by disabling the following error in the UMAC (Ixx11 = 0) and writing my own PLC that controls for the following error, halting the system only if the following error is outside the permitted range for 2 consecutive readings.

 

Is there a way to have this kind of control directly on the umac, without passing my own PLC?

 

Do you have any other idea on how to filter this encoder reading?

 

thanks

gigi

Link to comment
Share on other sites

  • Replies 6
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Usually these types of errors occur when the position feedback data is transferred numerically to PMAC, as a parallel or serial word. If noise causes a bit to be read wrong, PMAC can think there is a huge position error. For example, if bit 15 is flipped, that causes a 32K count error.

 

To counter this, we have "filtered" reads for this kind of data in the encoder conversion table that allow you to specify a "maximum change" value (from one servo cycle to the next) that you will regard as "real". If the data read in a cycle creates a change from the previous cycle that is bigger than your threshold, PMAC will discard it and calculate a substitute position that uses the same change (velocity) as in the previous cycle. You should set your threshold slightly greater than the maximum true velocity you expect to see.

Link to comment
Share on other sites

Hi All

 

In reply to Brad, I am using a UMAC with 3 GeoMacros connected via RJ45.

The encoder is a Heidenhain EQN425, that has Endat 2.1 feedback (absolute serial plus sin/cos).

 

Usually these types of errors occur when the position feedback data is transferred numerically to PMAC, as a parallel or serial word. If noise causes a bit to be read wrong, PMAC can think there is a huge position error. For example, if bit 15 is flipped, that causes a 32K count error.

 

I thought the same, even if the difference in the following error was not exactly 32768. Moreover the "manual" following error trap was working, so I think this is the proof that the error is only a noise somewhere in the path (between encoder and geomacro or geomacro and UMAC).

 

To counter this, we have "filtered" reads for this kind of data in the encoder conversion table that allow you to specify a "maximum change" value (from one servo cycle to the next) that you will regard as "real". If the data read in a cycle creates a change from the previous cycle that is bigger than your threshold, PMAC will discard it and calculate a substitute position that uses the same change (velocity) as in the previous cycle. You should set your threshold slightly greater than the maximum true velocity you expect to see.

 

ok, thanks a lot!

I have never used this kind of filtering inside the ECT... I can test this tomorrow and see if this can help.

 

thanks a lot for your help!

Gigi

Link to comment
Share on other sites

Hi

 

To counter this, we have "filtered" reads for this kind of data in the encoder conversion table that allow you to specify a "maximum change" value (from one servo cycle to the next) that you will regard as "real".

 

it is not completely clear to me in what scale is the "Max Change (LSB)" parameter in the ECT setup: it is encoder counts? 1/16 encoder counts? anything else? I am looking at the TURBO PMAC USER MANUAL (Sept 12, 2008) but I cannot find the answer...

 

thanks

gigi

Link to comment
Share on other sites

We have accomplished solving this problem before using the "big step" filter, Ixx67. Result is similar to what Curt suggests. Our issue was a parallel word where one bit would flip incorrectly.

 

That said, this is a workaround, and you should attempt to solve your noise problem.

Link to comment
Share on other sites

The units of the MaxChange word are LSBs of the source data word per servo cycle. This is explained in the software reference manual for the variable (where detailed information usually resides).

 

Since you are getting your data over the MACRO ring, it probably already has been interpolated to 1/32 count, so 1 LSB of the source data equals 1/32 count.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share


×
×
  • Create New...