Yaskawa’s User Alarms (DX100,DX200,YRC1000):

Overview:

Have you ever wanted to generate your own alarm on a Yaskawa robot controller, studied the Concurrent IO manual, and become intimidated by what appears to be semi-complex system of having set various bit sequences and worry about the timing of the various signals? Maybe you’re lacking confidence in your Concurrent IO abilities. The following is intended to demystify alarm generation on various generations of robot controllers.

Since the DX100 controller, Yaskawa has implemented a seldom advertised feature to easily generate user alarms. By simply setting a single IO bit, the existing logic in your robot controller will generate a corresponding alarm and in doing so, manage the complex binary sequences and timing of various signals.

Traditional way of setting “User Alarms”:

Normally, a user would be required to set a binary bit-sequence to bits 40140-40145 to identify which of the 64 possible user alarms are desired. Once the bit-sequence was set, relay 40012 would have to be set in order to trigger the reading of the 40140-40145 bits to determine which alarm to display.

While this approach would work for the most basic cases, if two or more alarms would occur at once, it becomes far more difficult to mange the logic associated with the 40140-40145 bits to always ensure the proper alarm was displayed no matter what combination of alarms might arise at the same time and determining a prioritization of the various alarm.

Yaskawa’s “User Alarm” feature implementation:

The lighten the burden of the challenges outlined above, Yaskawa has implemented a scheme where set a single bit will not only ensure the proper display of the desired alarm (handling the complex setting of bits 40140-40145). This Yaskawa logic also allows you to determine what alarms are more important than others and always display the highest priority alarm in the event multiple alarm triggers occurring at once.

How it works:

1. User specifies a bit from 79700-79776 (octal numbering remember in CIO!) via concurrent IO logic which will display the alarm while the bit is active. This 79700-79776 IO-range accounts for 64 “User Alarms” which are zero-based so essentially Alarms 0-63.
   •  79700 is defined as the HIGHEST priority alarm so this alarm will always display no matter what other bits are enabled.
   •  79776 is defined as the LOWEST priority alarm and all other alarms will be displayed before it.
   • See example below for a basic implementation!
2. User sets the text for a desired alarm in the “User Alarm” table found under “IN/OUT” à “I/O Alarm”
   • See example below for a basic implementation!           
3. The value of the currently active highest priority user alarm is placed in a M-Register for user or PLC access (value of zero = no alarm, value of 1-64 =  active user alarm#).

Example of Triggering User Alarm#43: Trigger low pressure alarm when external input 20027 is active in Play:

                              STR #20027       (External input where low pressure sensor is connected)

                              AND #50054     (PLAY mode selected)

OUT #79753      (Aux Output# Triggering Alarm #43)

Alarm 9107 Text: “Air Pressure Sensor Reading Low”

Resulting M240 = 44

Implementing Ladder :

Setting Alarm Text:

Resulting Alarm:

Detailed Break-down of the various 797** bits setting and triggering various alarm logic:

Full List of Alarm#, Alarm Text Value, and Triggering Signal: