Best Practice for Continuous Calculated Value Write-Back to PLC for Control/

Ignition
1

Hi everyone,

I'm using Ignition Edge and need some guidance on the best approach for a specific scenario.

The Scenario:

  • We have 3 proprietary field devices that our main PLC can't directly communicate with
  • Ignition Edge currently polls these devices for HMI display (Edge), but now 1 year later we have a new project requirement where we need to poll additional data from these 3 devices, perform calculations in Ignition Edge scripting using that data, then write two calculated values back to the PLC
  • These calculated values will then be used for: 1 PID control loop + safety shutdowns/alarms (if above setpoint) within the PLC

Questions:

  1. What's the recommended method for continuous write-back? (Ignition Edge)
  2. For PID control what update rate makes sense? Thinking 1-2 seconds.
  3. Any concerns with write conflicts when the PLC is actively reading these tags?
  4. Best practices for handling communication failures or indicating when calculated values are valid/stale?

The decision was also made that we dont wan't to spend any extra money on new PLC Modules for Modbus comms so we are limited to doing this through Edge scripting.

I want to implement this correctly from the start rather than troubleshoot issues later. I'd be incredibly grateful for any insights or recommendations you're willing to share. Your knowledge and time are truly appreciated!

Thanks so much in advance to anyone who takes the time to help!!

2

This bit here tells me you have chosen the wrong path for integration.
Never involve SCADA in safety.

8 Likes
3

What PLC are you using? and what calculations are you performing in Ignition?

4

In this application there's no risk to personnel, its just for some batch processing if we go over our shutdown alarm we want to shutdown the operation. I should not have appended safety to shutdowns there but regardless i agree with you.... i do not want to be doing this through SCADA either but i was told to work with it.

5

CompactLogix and we are doing some calculations using pH levels on soil

6

If you want to make Ignition behave a bit like a PLC, the most robust approach (IMNSHO) is to use a timer event script that runs like a PLC task. Use a single system.tag.readBlocking() to pull in a snapshot of all of the tag values that may be needed, run the logic to compute the values of all of the tags that would be written, and then assemble a single system.tag.writeBlocking() to efficiently update any of those that are not already at the desired value.

6 Likes
7

Thanks pturmel for sharing your input. Very appreciated!!

I will go this route and like i said i'm not happy at all about having to do this via Edge Scripting (will give one last push against it) but it is what it is.

Cheers

8

Assuming you could do the calculations in the PLC, have you considered the Modbus AOIs from Rockwell?

1 Like
9

The modbus AOIs from Rockwell are broken, and very limited on number of tags available.

10

Also, RTAutomation (https://www.rtautomation.com) has some nice gateways, and it will probably be less than the time it'll take you to program this in Ignition.

2 Likes
11

As I read this, you have a tag from one device that you're reading with Ignition. You now need to push this value into your process controls PLC?

Would an expression tag with a value change script to write to another tag that is bound to the PLC tag work for this?

12

Dangerous! Tag writes can stall, so are not safe to use in tag valueChange events. (Except writes to memory tags, which isn't the case here.)

13

Dangerous how? What do you mean by "stall"? Is there not a thread/queue that would handle this?

14

Oy! Easy to freeze all tag event scripting. Very small thread pool. Some reading for you:

https://forum.inductiveautomation.com/search?q=valueChange%20missed%20gateway%20tag%20change%20event%20order%3Alatest

15

I see. Good to know. Thank you.

Do we know if there will be any work to expand this functionality/capability in the future? I think modern hardware could handle more than the 3/5 limits that currently exist.

16

There is an option you can use in ignition.conf to increase the size of the thread pool, for very large applications where even disciplined single digit millisecond execution times may not be enough. But that is not a help for system.* calls that can block.

system.tag.writeBlocking() won't time out on comms hiccups for 60 seconds. Do very much of that in tag events and just a few hiccups will crush all tag events. Don't do it. Use system.tag.writeAsync() if you must use this pattern.

Same with DB operations and web API client operations. Use system.db.runSFPrepUpdate() for DB insert/updates if you must.

1 Like
17

Thanks Phil. Good to know that I was using the correct call (async) in these events, in any case.