# Help with Fast PLC Array Row Erase with Handshake **URL:** \ **Category:** Ignition\ **Tags:** ignition81, scripting\ **Created:** [July 24, 2025, 6:21pm UTC](https://forum.inductiveautomation.com/t/help-with-fast-plc-array-row-erase-with-handshake/108917 "2025-07-24T18:21:28Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Ahiero](https://avatars.discourse-cdn.com/v4/letter/a/a698b9/32.png) [@Ahiero](https://forum.inductiveautomation.com/u/Ahiero)\ **Post date:** [July 24, 2025, 6:21pm UTC](https://forum.inductiveautomation.com/t/help-with-fast-plc-array-row-erase-with-handshake/108917/1 "2025-07-24T18:21:28Z")
We have a situation where periodically a few rows of information requires removal from a large array of UDTs on PLCs. The PLC has tags that Ignition populates that are used to identify the row to be removed. Ignition then increments the _Trigger_ [DINT] PLC tag to start the PLC process. There are two scenarios from here: 1. The PLC executes the task and updates the PLC _Echo_ [DINT] tag to equal _Tigger_ indicating successful completion; or 2. The process will time out due to a connection, power-down, or other unknown failure resulting in _Echo_ not being updated. The source data for the PLC data updates comes from a database table. I would like this to run as a sequence, processing one record at a time from (1) to (6) below. The desired process is as follows: 1. Ignition to execute a gateway timed script to look for required updates. 2. Ignition will place the list of required updates in a module-level list. 3. For each item in the list, Ignition will send a request to the PLC 3a) Write row parameters to the PLC tags via `system.opc.writeValues()` 3b) Write _Trigger_ = _Trigger_ + 1 via `system.opc.writeValue()` 3c) Record _startTime_ as `system.date.now()` or alternatively use Java Instant 4. Ignition will read _Trigger_ and _Echo_ value from the OPC server item at a high frequency (~2x the timed task frequency on the PLC so about 50 ms?). 5. When either (_Echo_ == _Trigger_) or (`system.date.now()` - _startTime_) \> _timeoutPeriod_ then take the next action: 5a) If _Echo_ == _Trigger_ update the database row "Plc Confirm" field with a timestamp and the list item as completed, then move to the next item in the module-level list. 5b) If elapsed time is greater than the timeout limit then update the database row "Last Attempt" field with a timestamp and the list item as failed then move to the next item in the module-level list. 6. Write to logs with process result The "Last Attempt" field is used in the SQL query to allow the timed script to wait for a defined period before trying that PLC again. I am unsure how to implement: a) the tasks of reading the PLC tag values at high frequency looking for _Trigger_ == _Echo_ wrapped in a timeout without using sleep() or other methods that tie up the thread unnecessarily; and b) waiting for the whole sequence to complete before advancing to the next list item without "pausing" the thread. Any ansyc or later methods would need to carry enough information to update the correct database and list row. Maybe @pturmel has some ideas on how to get this done safely? Are there any examples of a responsive/fast process using the _Trigger_-_Echo_ handshake where the PLC is the side updating the _Echo_ part of the handshake? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [July 24, 2025, 6:57pm UTC](https://forum.inductiveautomation.com/t/help-with-fast-plc-array-row-erase-with-handshake/108917/2 "2025-07-24T18:57:08Z")
1. At paces below ~250ms I only recommend using I/O protocols, like the Adapter Option of my EtherNet/IP driver. 2. Don't write this sequence as straight-through jython code. Write it as a state machine that you can call rapidly from a timer event. Within the restructured code, there should not be any indeterminate loops (that continue until a condition). Condition checking should update state, not hold up the logic.