EtherNet/IP Operation
This section describes the acquisition sequence and decode result sequences.
Acquisition Sequence
The DataMan reader can be triggered to acquire images by several methods. It can be done either implicitly through the Assembly object, or done explicitly through the ID Reader object. When using explicit messaging, you can either:
- access the Acquire Service in a single step, or
- directly manipulate the ID Reader object attributes (AcqTrigger and AcqStatusRegister), or
- use DMCC commands.
The ID Reader attributes are discussed in this section. These same values can also be accessed through the assembly objects. On startup, the AcqTriggerEnable attribute is False. Set the attribute to True to enable triggering. When the reader is ready to accept triggers, the Trigger Ready bit in the AcqStatusRegister is set to True.
While the AcqStatusRegister “Trigger Ready” bit is True, each time the ID Reader object sees the AcqTrigger attribute change from 0 to 1, it initiates an image acquisition. When setting the Trigger Ready bit to True through the assembly objects, make sure that the attribute is held in the new state until that same state value is seen in the Trigger Ack bit of the AcqStatusRegister. This is a necessary handshake to guarantee that the change is seen by the ID Reader object.
During an acquisition, the Trigger Ready bit in the AcqStatusRegister is cleared and the Acquiring bit is set to True. When the acquisition is completed, the Acquiring bit is cleared. The Trigger Ready bit is again set to True once the reader is ready to begin a new image acquisition.
The reader allows acquisitions to overlap with the decoding of previous acquisitions. The Trigger Ready bit is set high after the acquisition is complete, while decoding may still be in progress. The Decoding bit is deprecated and only mirrors the behavior of the Acquiring bit. If trigger queuing is active or other trigger sources can interfere, the Trigger Ready bit may not be reliable. As result, conflicting trigger overruns may occur, which are reported in Bit 3 of the ResultCode attribute of the ID Reader object.
In certain cases, you can cancel an acquisition by clearing the Trigger signal before the read operation is finished. This allows you to cancel reads in Presentation and Manual mode if no code is in the field of view. To ensure that a read is not unintentionally canceled, make sure that the PLC holds the Trigger signal True until both TriggerAck and ResultsAvailable are True (or DecodeComplete toggles state).
|
To force a reset of the trigger mechanism, set the AcqTriggerEnable attribute to False until the AcqStatusRegister is 0. Then the AcqTriggerEnable can be set to True to re-enable acquisition.
Decode / Result Sequence
After an image is acquired, it is decoded. When the decoding is complete and a result is ready to be delivered, the reader toggles the DecodeComplete bit of the DecodeStatusRegister.
Decode results are reported asynchronously to the ID Reader Object. If BufferResultsEnable is set to False, then the decode results are immediately placed into DecodeResults, and the Results Available bit is set to True.
If the BufferResultsEnable attribute is set to True, the new results are queued. The earlier decode results remain in the DecodeResults attribute until they are acknowledged by the client setting the ResultsAck attribute to True. After the Results Available bit is cleared, the client sets the ResultsAck attribute back to False to allow the next queued results to be placed in to the DecodeResults attribute. This is a necessary handshake to ensure that the PLC receives the results, even if short gaps occur between results.
Behavior of DecodeStatusRegister
| Bit | Bit Name | Results if Buffering Disabled | Results if Buffering Enabled |
|---|---|---|---|
| 1 | Decoding | Set when acquiring and decoding an image. The value of the Decoding bit is always the same as the Acquiring bit. | Set when acquiring and decoding an image. The value of the Decoding bit is always the same as the Acquiring bit. |
| 2 | Decode Complete | Toggled on completion of an image decode. | Toggled on completion of an image decode. |
| 3 | Results Buffer Overflow | Remains set to zero. | Set when decode results could not be queued because the client failed to acknowledge a previous result. Cleared when the decode result is successfully queued. |
| 4 | Results Available | Set when new results are placed in the DecodeResults attribute. Stays set until the results are acknowledged by setting ResultsAck to true. | Set when new results are placed in the DecodeResults attribute. Stays set until the results are acknowledged by setting ResultsAck to true. |
|
Results Buffering
The Results Buffering feature allows a queue for decode results. When enabled, the feature queues a finite number of result data sets until the PLC (client) has time to read them. This smooths out data flow if the PLC slows down for short periods or if there are surges in read activity.
If the feature is enabled, the reader overlaps acquisition and decode operations. This can lead to faster over all trigger rates. When reads occur faster than results can be sent out (the queue is full), the most recent results are discarded until space becomes available in the results queue.
If the feature is disabled, the more recent results overwrite the earlier results. The most recent results are kept. Earlier results are discarded if the PLC does not read them fast enough.
If the queue overflows while the feature is disabled:
-
The difference between the TriggerID and ResultID values becomes greater than 1. This difference represents the number of reads that occurred but could not be queued because the queue was full.
-
The number of lost reads equals TriggerID - ResultID - 1.
-
After the next read, the ResultID value returns to the typical operating value of TriggerID - 1.
Result Fragmentation
The Result Fragmentation feature splits decode result strings into fragments if the strings are too large for the Results Data field. The fragments are then pushed to the buffer like normal results. Then, the PLC reads the fragments one by one.
Result Fragmentation depends on Result Buffering. This means that results are only fragmented if Result Buffering is enabled.
Enabling Result Fragmentation
To enable or disable Result Fragmentation, you have the following options:
-
Use the FFP.RESULT-FRAG DMCC.
-
Use SoftEvent 6 to enable the Results Buffering and Result Fragmentation features from the PLC.
Operation of Result Fragmentation
The PLC does not automatically reassemble the result string. Once the PLC reads a result fragment, you have to copy the fragment to a new user-defined variable. After this, you have to set and clear the ResultAck bit, which updates the Decode Results with the next fragment. This process continues until all fragments have been sent to the PLC.
In contrast, if Results Buffering is disabled, large decode result strings are cut off to fit into the Results Data field, which means that the end of the string gets lost.
Identifying Decode Result Chunks
Decode result fragments look like normal results. To identify result fragments, look at the Result ID:
-
The Result ID of the result fragments are the same.
-
The Result ID of the last result fragment is different from the Result ID of the next result.
The Result Length of the result fragments represents the amount of data left to be sent.
-
The Result Length of the result fragment is lower or equal to the Result Buffer Size.
-
When the Result Length equals 0, there are no more fragments left for that decode result.
Maximum Result Data Length
Without results fragmentation, result data is truncated to fit into the results data buffer size. Depending on the protocol, the result buffer size can be fixed or configurable.
The Result Fragmentation feature allows processing of up to 50 times longer results, depending on the results buffering queue size, with an absolute limit of 65535 characters.
The maximum number of result characters for EtherNet/IP is 470 bytes (fixed).
DMCC Result Feedback from PLC
The DMCC Result Feedback feature allows the reader to send DMCC responses back to the PLC.
By default, this feature is off. If enabled, the reader sends DMCC responses to the PLC using the same mechanism as for read results. To distinguish DMCC results from read results, bit 6 is flagged in the ResultCode field.
To enable the feature, use the FFP.DMCC-RESULTS command. Changing this configuration does not require you to reboot or reconnect reader.
You can use DMCC Result Feedback in combination with Results Fragmentation.