A CompactLogix L35E can use an Ignition SQL Bridge transaction group to exchange heartbeat or handshake values, but the machine-start decision must distinguish a live PLC connection from successful completion of the required data collection.
Choose the machine-start condition
Before configuring tags, define what “ready” means for the machine. A heartbeat can show that a value is still changing between the PLC and the PC-side system; it does not, by itself, prove that a process record was saved or that a particular part’s data is complete.
- Decide whether loss of the PC-side system must block a new machine cycle, stop an active cycle, or only raise an alarm. The source configuration uses a start inhibit; another implementation allows operation and requires operator intervention before restart.
- Define the recovery action. For a start inhibit, specify how the PLC releases the inhibit after communications or data collection recover. For an operator-mediated restart, define the required HMI selection or acknowledgement.
- Keep the interlock decision in PLC logic. Use an explicit PLC status or permissive that the sequence checks before starting; do not treat a PC display alone as the interlock.
Check: With the PC-side process unavailable, test that the PLC produces the intended behavior—start inhibited, alarmed, or restart-held—before connecting a heartbeat or handshake.
Configure the scheduled heartbeat write
A direct toggle is suitable when the requirement is to see a changing PLC tag while the Gateway service and transaction group are operating. The demonstrated arrangement uses a transaction group with update mode DB to OPC, no table name, and a run-always expression item. Its expression reads the target heartbeat tag and writes the result back to that OPC tag.
- Create the transaction group and set its update mode to
DB to OPC. Leave the table name unset for this tag-only arrangement. - Add a run-always expression item with the expression
{[.]Heartbeat}=0. - Set the expression item’s target OPC tag to
Heartbeat, the same tag referenced in the expression. - Set the group update rate to the interval required by the design. The tag changes on group updates; the group rate is therefore the heartbeat write cadence.
The equality expression returns the opposite Boolean state for a tag that alternates between zero and one: when the tag is zero, the expression evaluates true; when it is true, the comparison evaluates false. The next successful group update writes the new state. Confirm the tag’s OPC data type and PLC representation accept these values before relying on the toggle.
Check: Monitor the PLC tag and the transaction group’s execution/status diagnostics. Confirm that the tag alternates at the configured cadence without write errors before using it as a permissive input.
Prove a heartbeat with PLC echo tags
A PC-side toggle only proves that writes are being attempted and accepted at the OPC boundary. To verify a round trip through PLC logic, use separate input and output integer tags: the PC writes the input, and the PLC copies it to the output when the input changes. The PC can then watch for the echoed output.
- Assign one PLC integer tag as the heartbeat input and another as the echoed output.
- In PLC logic, copy the input value to the output when the input changes.
- In the transaction group, write the input from an expression based on the echoed output. The demonstrated expression is
if(({[.]Out}&255)>99,0,({[.]Out}&255)+1). - Monitor the output tag and declare the heartbeat stale if it does not change within the selected timeout. The example implementation used a three-second no-change timeout.
The expression masks the echoed value to its low eight bits and cycles the resulting counter through the demonstrated range. Match the timeout to the actual update cadence and expected communication delays; a timeout shorter than ordinary group execution gaps can create false faults. The three-second value belongs to that implementation, not a universal setting.
Check: Confirm the PLC output follows input changes and that interrupting the exchange causes the PLC-side stale indication within the configured timeout.
Select the heartbeat fault response
Choose whether the heartbeat means “Gateway service is running” or “the complete data path is healthy.” A changing tag written by a run-always group indicates activity in that configured path; it does not prove that the database accepted a process record. An echoed counter adds evidence that the PLC logic returned a changed value, but still does not prove a specific record was committed.
| Observed condition | Likely interpretation | PLC response to define |
|---|---|---|
| Heartbeat tag stops changing | Group execution, OPC write, communications, or Gateway activity may have stopped. | Apply the chosen stale-heartbeat response after the timeout. |
| PC input changes but PLC echo does not | Investigate PLC copy logic, tag addressing, data type, and read/write quality. | Do not treat the round trip as healthy. |
| Heartbeat continues but record is missing | The heartbeat path is active while logging or database processing has failed or not completed. | Use a record-specific handshake if collection completion gates the machine. |
Check: Test a stopped group, a broken tag exchange, and a database/logging failure separately. Verify that each condition produces the intended PLC indication rather than relying on one heartbeat to diagnose every failure.
Return a record-specific handshake
When the PLC needs confirmation that data for a particular part has been processed, return a key associated with that part’s record. A fixed value such as 1 acknowledges an event but cannot identify which part or record the acknowledgement refers to. A serial-number string can provide that association if the returned value comes from the successfully processed record.
- Identify the part key captured with the PLC data, such as the serial number string.
- Configure the transaction or database procedure to return that key only after the required data-processing step has succeeded.
- Write the returned value to a PLC OPC tag used by the machine sequence.
- Have the PLC compare the acknowledgement with the key for the part awaiting confirmation. Release the sequence only on a match; define timeout, retry, and duplicate handling separately.
A demonstrated alternative uses a run-always expression item with a SQL query that returns the newest record number: SELECT group_table_ndx FROM group_table ORDER BY group_table_ndx DESC LIMIT 1;. The item targets an OPC tag holding that number. Replace the example table and field with the installation’s actual schema, and verify that the database supports the query syntax. A newest-record number is not automatically proof that the matching part’s record completed: use a part-key predicate or a completion status when records can be concurrent, delayed, or written by other groups.
Check: Process two distinct part keys and confirm that each PLC acknowledgement matches the correct completed record, not merely the most recently visible row.
Keep heartbeat and handshake behavior distinct
The two signals answer different questions. A heartbeat checks ongoing activity; a handshake acknowledges a specific data event. They can share a transaction group, as in the echoed-counter implementation, but their PLC acceptance conditions should remain distinct.
| Signal | Payload behavior | Acceptance condition |
|---|---|---|
| Direct heartbeat | Tag alternates on group updates. | Tag changes within the selected heartbeat interval. |
| Echo heartbeat | PC counter is returned through PLC input and output tags. | PLC echo changes before the stale timeout. |
| Handshake | PC returns a fixed value or a key associated with processed data. | PLC sees the expected acknowledgement for the pending part/event. |
One implementation couples the PC response to successful processing of changed PLC data; another uses a query to return a database record number. Select the behavior that matches the machine sequence. A heartbeat that continues during a failed logging transaction must not satisfy a data-complete permissive.
Check: Demonstrate that a live heartbeat without a valid part acknowledgement leaves the data-complete condition false.
Verify the complete collection sequence
Run the end-to-end test with the machine sequence, transaction group, PLC tags, and database behavior active. Capture the relevant tag values and record key for each test so the PLC decision can be compared with the actual collection result.
- Confirm the group runs at the selected update rate and the configured heartbeat tag changes, or that the PLC echo counter advances.
- Remove or interrupt the heartbeat exchange. Confirm the stale indication occurs at the configured timeout and the PLC applies the chosen inhibit or recovery policy.
- Restore communications and confirm the heartbeat recovers without falsely acknowledging a pending data record.
- Complete a part cycle. Confirm the database contains the expected data and key, then verify that the PLC receives the matching handshake value.
- Repeat with a second part and with a failed or delayed record-processing case. Confirm that the PLC does not accept a stale key or heartbeat as proof that the new record completed.
Check: Release the machine sequence only when the heartbeat state satisfies the communications policy and, where required, the handshake matches the successfully processed record for the part awaiting confirmation.
Frequently asked questions
Can I use an Ignition transaction group as a PLC heartbeat?
Yes. The demonstrated setup uses a run-always expression in a DB to OPC group with no table name and writes {[.]Heartbeat}=0 back to the Heartbeat OPC tag at the group update rate.
Does a changing heartbeat prove the part data was saved?
No. It indicates activity in the heartbeat path, not successful storage of a specific part record. Return and compare a record-associated key, such as the part serial number, when the PLC must confirm data completion.
Can the PLC echo a heartbeat counter?
Yes. Use separate integer input and output tags, copy input to output in PLC logic when it changes, and have the PC expression advance from the echoed value. The described implementation treated no output change for three seconds as loss of heartbeat.