This is a simple question but haven’t found an answer yet. We have a S1 controller in our core and several EB1 brains connected remotely via VPN. We found that the scan time of the analog points are too fast for our needs and using unnecessary bandwidth of our data plan, we want to set the scan time from 1 to 2 seconds and study if there is a significant difference in data consumption as we think there is.
Is there any way to change this setting? Thank you.
How are you reading the points from your strategy? Every time you read a point in your strategy, the control engine does a network read which will include all the TCP/IP overhead. How you write your strategy determines the “scan rate” - how often the strategy requests the IO.
To reduce the amount of bandwidth, you need to read your IO less (increasing the loop delays, perhaps). Another way to reduce bandwidth, while also increasing performance, (at the cost of complexity) you can look into using the MoveIoUnitToNumTable or MoveIoUnitToNumTableEx commands. These commands will perform a block read from the brain, significantly decreasing the network overhead. Do this one time in your chart, like right after your charts delay. You also are in control of how often you read your variables through the loop delays in your chart (You do have delays, right?).
Are you running an HMI, PAC Display? If you are, you can set it to read the IO from a local variable in your strategy (like the table from the MoveIoUnitToNumTable command) so the HMI isn’t making any requests to the remote IO.
We have a delay of 2 seconds in the Powerup chart where all other charts are called and even with that, when I look at the points in the I/O Units the rate is way faster than 2 seconds. We have a Groov unit but is unplugged from the network and there is no HMI or PAC Display running.
Does you powerup chart loop? Is it possible to post some screenshots of your powerup chart and one of your other charts?
Philips advice is sound.
You will need to tweak your charts a bit, but the key is to stop reading the I/O by point name.
You can test this first (sounds like you have a way of checking traffic rate?).
So pull out all references of ALL I/O, ain, aout, din and dout. That will stop all traffic from the core S1 to the EB’s.
Once that has been proven, you can put in a new chart that uses the commands Philip suggests.
This way, you will bulk read the I/O only at the rate set by this new chart.
You then connect everything, even groov, to the table elements from those ‘I/O tables’… The end result is that you will only be reading the EB I/O at that chart rate and thus be limiting your data throughput.
Yes, my Powerup chart loops, but there’s a global delay on it, even when the charts are delayed the scanning time is still too fast.
Here is a screenshot of the Powerup chart but the other charts will be difficult to screenshot because of company policies.
If there’s a global delay everything will be delayed even point reads, is that right? But either way scanning time is not affected.
Are your other charts looping, or do they run once through and stop? Your reads and writes of your IO points is going to be the only thing sending traffic to the brains, There is no “scanning”. Remove all your “start chart” commands and run your strategy and there will be no traffic.
Be aware that debug mode/watch windows to the IO points will generate traffic.
I found a solution to lower the bandwidth and the problem had nothing to do with PAC devices. It was a bad implementation of the VPN service which caused 3G routers to ping outside the network causing unnecessary traffic. We set access lists to limit the clients to reach just to our network and block all attempts to reach the internet. Bandwidth is way lighter now.
By the way, how is the best way to deal with disconnected I/O Units? Sometimes signal is very poor and some devices disconnects, setting longer timeouts and retries slows down the strategy and we have a significant number of remote units which multiplies wait time. We haven’t found an optimal way to check if devices are available again in a way that the strategy does not remains idle.
I would for sure, take a look at the I/O enabler for Enet brains;
http://www.opto22.com/site/downloads/dl_drilldown.aspx?aid=3604
It has a nice backoff timer so it does not just hammer them, events are stored in the error log, that could be handy as well.
If nothing else, it should serve as a good starting point for any tweaking you want to do.
There is a doc file in the directory when you unzip it for how to use it.
Excellent! I will take a look.
