Im having an issue that i think may be related to tag polling but im not sure. I am trying to offload data from a plc to a sql database, we are generating roughly 40 rows per second. I have the logic setup on the plc side to set a trigger bit to tell ignition to create a new row based on particular tag data. Ignition writes a handshake integer to tell me its done, then i repeat the process with the next dataset in the buffer.
The problem is that i cant get it to run at a reasonable speed. If i wait 1s or more between setting the trigger bit it works no problem, but when i try to make the transactions faster it freezes. The plc will have the trigger bit high but ignition never runs the transaction. I have tried this using transaction groups and just doing it all in scripting and im having the same issue.
I have my tags set to poll every 50ms
Look at your device status screen on the gateway. What is the overload factor on the 50ms poll group? I would bet money its more than 0%. Normally Ignition's drivers don't do well beyond 250ms, if you have pturmel's ethernet/IP driver, you can get to 100ms with work done on the PLC side for optimization.
Consider the approach outlined in this post:
It basically boils down to having a ring buffer in your PLC that stores enough data for x seconds of runtime and offloads in smaller chunks of y seconds at slower poll rate in Ignition. This does mean scripting the transaction instead of using the SQL bridge module.
If you are using transaction groups, make sure you changed the timer in the action tag from the default of 1 second. From what I can tell, with it set to trigger on a tag, the transaction group will only check the trigger tag value at the rate of that timer. And if you have "Only execute once while trigger is active" checked then it will only trigger on a rising edge.
If you are having the issue in scripting, how are you monitoring the trigger? If you are using a tag value change script setup in the tag configuration, you should try moving it to gateway events.
I do agree with Ryan that this may be better to design in a buffer.
40 rows per second is impractical in the SQL Bridge module. Not sure if you can even set its check interval below 100ms.
40 rows per second is very difficult for OPC connections to support in subscription mode, unless you only care about single values. (If you need to capture multiple values together, subscriptions cannot do it.)
I would not attempt an application like this without a ring buffer in the PLC.
overload was at 3000% lol, i changed it to a ring buffer type architecture bulk copying everything in the buffer every 5 seconds. changed my subscription rate to 2.5s, now it runs no problem and no overload.
I had to write it all in script however because i couldn't figure out how to dynamically change the block size in a block transaction group.
thank you
That means your actual poll rate was closer to 1500ms
You cannot do this, so scripting is the only option. Transaction groups are for fast drag and drop configuration with minimal(limited) handshaking. Anything with varying number of items or proper handshaking has to be done via script.