Thank you for all your help on both my threads.
I ended up going back to multi injects that looks kind of like ladder logic. I hope that will help co-workers when they are troubleshooting. With the addition of the RBE “rung” and moving all scratchpad reads to a single read, it seems to operate acceptably. Total CPU usage is normally around 60-80%, with regular spikes up to 95+%.
I look forward to continuing to use Opto products on future projects.
-Caleb
If you are going to set it up like that, could you consider something like this:
This way, rather than slamming all the groov nodes at once a second on the second, you spread the love by 0.5 of a second and at least give things a beat to breath?
You might even be able to go down to 0.2 seconds and get to the bottom of the chain around the same time, but at least not everything is getting hit at the exact same time.
@cbohon Did you get a chance to test the delay nodes idea?
I wonder what the CPU went down to using this staggered method?
As an FYI…
I have found in the past that if you fetch ‘all at once’ (triggering several PAC Read nodes at once), especially when reading tables, you can get connection errors. Daisy chaining from a single Inject node, as Beno shows in his example flow, overcame this problem.
This is on a PAC R1 and iirc the error was something like ECONN RESET
The delay works very well. I have 9 “rungs” in the flow, and I put in 0.1 second delay for each rung. I also slowed it down to run only every two seconds, so that gives it about 1 second to run the flow, and 1 second of buffer before the next start. I hope that helps writes all finish before the next start of the flow.
CPU usage is 20% to 60% with occasional spikes higher than that.
Thanks for all the help,
-Caleb
Thanks so much for running the test and reporting back.
Glad to see that it really did help your CPU use drop a good amount.
Time slicing is so important for most ‘code’. Good to see it put in practice in your flows.
