The Omron driver provides support for Omron unsolicited messages, allowing a trigger's execution to be initiated from the ladder logic in an Omron PLC. A trigger can be defined with an event type of Omron or Omron (CIP), where CIP indicates messages that utilize the Common Industrial Protocol. This means that the trigger will execute when an unsolicited message is received from the ladder logic in an Omron PLC. The use of unsolicited messages can take the place of having a trigger constantly polling a PLC variable to see if a data condition has been met.
The Omron driver supports the SEND(090) and RECV(098) FINS protocol based messages. These messages would be sent from either an Omron CS or an Omron CJ PLC. The driver also supports two CIP messages types, the CIPUCCMSEND and the CIPUCMMWRITE. These messages would be sent from an Omron NJ PLC.
Some unsolicited messages will send additional data to the node. This can be any data buffer available within a CS or CJ PLC for the SEND(090) message or any data buffer available within an NJ PLC for the CIP messages. The trigger associated with the specific unsolicited message will have access to this data and will be able to utilize it as an input to any action defined within the trigger. For example, a trigger could use the data sent by the unsolicited message to write to a variable on a PLC or other device. The trigger could also use the unsolicited message data as input to a transaction that will update a table in an enterprise database. For more information on triggers event types and actions, see Trigger event type reference and Trigger actions reference.
The RECV(098) unsolicited message will expect the trigger to supply it with data. The Omron PLC will use the data supplied as values to be written to its controller tags. The data sent back to the Omron PLC can come from an enterprise application, other devices defined within the node, or any other data generated by the trigger.
The use of unsolicited messages is an excellent strategy to reduce the processing load on both the node and the PLC. Rather than constantly polling a PLC, reading a data point to determine if a condition has been met to execute a trigger, the PLC can indicate when the condition has been met and send the unsolicited message. Likewise, the PLC no longer has to constantly field read requests from the node, more often than not on data values that are not changing. The PLC ladder logic can be modified to initiate the execution of a trigger based on criteria defined in the ladder, by sending the unsolicited message to the node. If the criteria needs to be modified, the changes are isolated to the PLC and the trigger logic is not impacted.