Limitation in PAC Control to NR reads


#1

Ok, so I’m reading all of the analog inputs from a number of EB2s using NR, works most of the time. But I get periodic read errors. Some get read every 5 min, some every 15 min.

Are there limits or recommendations on the number of points that can be concurrently read? Currently only have 26, but looking to expand to about 80.

Btw, also reading digital in but at alternate times.


#2

Whats the error you see?

We have seen some issues with doing bulk batch reads, but they have been a bit tricky to track down.
Any information you can share about the error would be a great help.

In short, try and break the read period into prime numbers. By having your reads at 5 and 15 minutes, you can be sure that every 15 min, you are also doing the 5 min read at the same time, thus double loading up the controller.
By using prime numbers for your read times, you will never get two reads at the same time.
This may be all you need to do…


#3

Thanks Ben,

You were correct, two flows using different trigger times, that were occasionally stepping on each other. Changed to a single trigger, and function to splits the actual reads at specific times. It’s run for an hour without any read errors.

Marty


#4

I like that idea of using a single trigger. Ben’s idea was good but I think it is flawed somewhat. If I use a timer at 7 minutes and one at 11 minutes, at 77 minutes they would conflict.

I’ll have to add that single trigger idea to my flow and see if it decreases my read errors.


#5

Well, changing to a single trigger help a little. So, trying a different approach. it ‘seems’ like a load issue or conflict with the strategy running in the controller. One solution would be to allow wildcards to select one or more specific points.

Current solution:

  1. Originally running on a PAC-R1, executing the same strategy. as my production SoftPAC.
  2. Reading 26 analog inputs, and 19 digital inputs.
  3. Node-red is on a server on the same physical segment as the R1. No problems access the EB2s.
  4. Built a new strategy that only reads the points, no computations, alarms ,etc.
  5. This seems to have reduced the number of errors, 30 an hour to 5-8.
  6. May have to look at REST rather than using node-red.(There may be a memory leak in Node-red, noticed it but could not verify.)


#6

I need to think about what you are doing and seeing, but wanted to shoot off a quick reply and save you some time on point 6.
Node-RED uses the REST interface, so using REST or using Node-RED to do the reads are the exact same ‘impact’ on the controller.

BTW, are you using security on the PAC for the REST interface?


#7

Thank Ben,

Used it both ways, to try to determine where the issue could be, current using http, Currently getting mostly -5 errors, occasionally a -17.

Also, using direct REST could indicate that it’s a node-red issue. Haven’t had time to try that yet.


#8

Security takes a little longer per request because of the encryption/decryption that has to take place.
If you are in a situation of using your own network, then things will be faster without it.

Thanks for getting back to us with the error number(s). I have also seen the -5 error when doing a lot of requests.
Some thoughts.
Make a dummy table 80 to 100 elements long in the control strategy. Do a test read on that table.
In other words, it should be a lot faster and more efficient to do a single table read than to read 26 analog inputs and 19 digital inputs.
If this is the case, then you just need to tweak the strategy to build that table and then have Node-RED read it.

You are on the right track, it could be a load issue. groov also is using the REST interface, so if it is reading a lot of tags and Node-RED is also reading a lot of tags, then things get loaded for the controller.

We are working on the issue here with the software team and hope to get to the bottom of it, but we have nothing to share other than the tip that reading a block via a table is more efficient.


#9

Ben,

It’s really odd, some 24 hours periods I’ll get 40-50 errors(-5), others maybe 5-6.

Marty


#10

I have been having the same issues. -5 errors and slow downs at random times. I have heard grumblings about ports or sessions on PAC’s getting maxed out with too many connections. If the hardware turns out to be an underlying limitation do we know if the Epic hardware will be more robust in this regard?
We have been pumping data from Opto 22 systems to databases since the early 80’s (before Opto had controllers) and I am seeing this issue no matter how I try to do it. ODL, NR, REST. We need an option that is predictable, any ideas? When we used Factory Floor on Arcnet it was pretty stable, ahhh the good old days :wink:

Thanks,
Norm


#11

I’ve had better luck splitting my reads in NR of multiple tables from the running strategy. I built a ‘Scheduler’ to trigger multiple reads every five minutes at five second intervals.

image

Javascript:

var date = new Date();
var sec = date.getSeconds();
var min = date.getMinutes();
var m05 = date.getMinutes() % 5; //every 5 minutes

if (m05 === 0) {
switch(sec) {
case 0:
node.status({fill:“green”,shape:“dot”,text:“Output 1 - 00 Sec”});
return [msg,null,null,null,null,null,null,null,null,null,null];
case 5:
node.status({fill:“green”,shape:“dot”,text:“Output 2 - 05 Sec”});
return [null,msg,null,null,null,null,null,null,null,null,null];
case 10:
node.status({fill:“green”,shape:“dot”,text:“Output 3 - 10 Sec”});
return [null,null,msg,null,null,null,null,null,null,null,null];
case 15:
node.status({fill:“green”,shape:“dot”,text:“Output 4 - 15 Sec”});
return [null,null,null,msg,null,null,null,null,null,null,null];
case 20:
node.status({fill:“green”,shape:“dot”,text:“Output 5 - 20 Sec”});
return [null,null,null,null,msg,null,null,null,null,null,null];
case 25:
node.status({fill:“green”,shape:“dot”,text:“Output 6 - 25 Sec”});
return [null,null,null,null,null,msg,null,null,null,null,null];
case 30:
node.status({fill:“green”,shape:“dot”,text:“Output 7 - 30 Sec”});
return [null,null,null,null,null,null,msg,null,null,null,null];
case 35:
node.status({fill:“green”,shape:“dot”,text:“Output 8 - 35 Sec”});
return [null,null,null,null,null,null,null,msg,null,null,null];
case 40:
node.status({fill:“green”,shape:“dot”,text:“Output 9 - 40 Sec”});
return [null,null,null,null,null,null,null,null,msg,null,null];
case 45:
node.status({fill:“green”,shape:“dot”,text:“Output 10 - 45 Sec”});
return [null,null,null,null,null,null,null,null,null,msg,null];
case 45:
node.status({fill:“green”,shape:“dot”,text:“Output 11 - 50 Sec”});
return [null,null,null,null,null,null,null,null,null,null,msg];
}
} else {node.status({fill:“red”,shape:“ring”,text:“Idle (”+min+":"+sec+")"});}


#12

Just a heads up: You have two “case 45:” in your javascript.


#13

I love the scheduler, thanks!
I ran across an issue that maybe one of you can answer. To make this easier to replicate, I am trying to read all the analog points in from the convenience store demo on a LC. When I read all the analog points in with the PAC Read Node it places the Names and Values in an array (good). This works great as long as all the values are positive numbers. The problem arises if any of the values are negative. Any negative values that the node sticks in the array become Nan’s. Yet when I read the negative analog point directly by tag name the value comes through as a valid negative value. My goal is to read all the points in one operation and reduce the load on the controller. I noticed after groov came out that the controllers do tend to sometimes get “quiet” when too many connections are happening at once. Since we have dozens of analog inputs (use 2-3 SNAP AIMA32’s per controller) having individual nodes does not make sense. I must be missing something basic here.

Thanks,
Norm


#14

After playing with this more I feel it may be an issue with the node so I opened a ticket on it.