Optimizing Switch Nodes / OPCUA

General
1

I have a general question about the capabilities of the switch node. For example, in the screenshot attached, I am sending just about all of my OPC info through one READ node that then goes to a switch node, and using browseName I separate them and send them where they need to go. Is this too many for the switch node to handle? Would it be better to split it up into 2 equally sized ones? Every once in a while it seems like there is a delay (which is why I split some off into the top READ node) Just wasn't sure if it was approaching the limits of its capability

Screen Shot 2021-05-31 at 4.30.20 PM

Thanks

2

You forgot the screenshot :slight_smile:

3

Haha thank you for pointing that out!! :rofl:

4

There's something different about your image - it doesn't expand when you click it - can you try just pasting the image in please

(Did you shrink it before posting or something - if you did - paste the original full image instead)

5

Screen Shot 2021-05-31 at 4.30.20 PM
Screen Shot 2021-05-31 at 4.30.20 PM536Ă—1098 131 KB

1 Like
6

When using a switch or this approach, the results depend on the iteration when it got to the result that then broke out to the output. The LAST iteration takes the longest to find, thus delay. The first, the less time, the fastest. You will need to find a method to eliminate the time taken to search through the "switch". Or, you will need to find a means to eliminate the variance in the time it takes to find the first vs. the last possible choice.

1 Like
7

Do you have any suggestions on a more efficient way to do this?

8

Can you export just the switch node and share it here, so we can see what you are doing there? In case you don't know how to do that see this post for more details - How to share code or flow json

9 
[{"id":"33f668dd.52c13","type":"switch","z":"d86d2f0f.3aa6e","g":"9563f4d9.722bf","name":"","property":"browseName","propertyType":"msg","rules":[{"t":"cont","v":"DIG LOAD CELL NORMALIZED","vt":"str"},{"t":"cont","v":"DIG WEIGHT NET","vt":"str"},{"t":"cont","v":"DIG WEIGHT FINAL","vt":"str"},{"t":"cont","v":"DIG WEIGHT TARE OFFSET","vt":"str"},{"t":"cont","v":"DIG TANK PERCENT FULL","vt":"str"},{"t":"cont","v":"UNLOCK DIG DOOR REQ","vt":"str"},{"t":"cont","v":"DIG TEMP FINAL","vt":"str"},{"t":"cont","v":"DIG WEIGHT AVERAGE","vt":"str"},{"t":"cont","v":"AUTO MODE","vt":"str"},{"t":"cont","v":"HEARTBEAT TO HMI","vt":"str"},{"t":"cont","v":"BOIL LOAD CELL NORMALIZED","vt":"str"},{"t":"cont","v":"BOIL WEIGHT NET","vt":"str"},{"t":"cont","v":"BOIL WEIGHT FINAL","vt":"str"},{"t":"cont","v":"BOIL WEIGHT TARE OFFSET","vt":"str"},{"t":"cont","v":"BOIL WEIGHT AVERAGE","vt":"str"},{"t":"cont","v":"POWER ON COMPLETE","vt":"str"},{"t":"cont","v":"DIG MOTOR SPEED","vt":"str"},{"t":"cont","v":"ECO MODE","vt":"str"},{"t":"cont","v":"MANUAL MODE","vt":"str"},{"t":"cont","v":"CLEANOUT MODE","vt":"str"},{"t":"cont","v":"STANDBY MODE","vt":"str"},{"t":"cont","v":"JAM COUNT","vt":"str"},{"t":"cont","v":"DIG MIXER RECIPE","vt":"str"},{"t":"cont","v":"BIO DOSE COMPLETE","vt":"str"},{"t":"cont","v":"FAULTED CODE","vt":"str"},{"t":"cont","v":"DIG FAULTED","vt":"str"},{"t":"cont","v":"BOIL FAULTED","vt":"str"},{"t":"cont","v":"MAIN FAULTED","vt":"str"},{"t":"cont","v":"BOIL WT MIN SETPOINT","vt":"str"},{"t":"cont","v":"BOIL WT MAX SETPOINT","vt":"str"},{"t":"cont","v":"BOIL WT FULL SETPOINT","vt":"str"},{"t":"cont","v":"BOIL WT EMPTY SETPOINT","vt":"str"},{"t":"cont","v":"DIG WT MIN SETPOINT","vt":"str"},{"t":"cont","v":"DIG WT MAX SETPOINT","vt":"str"},{"t":"cont","v":"DIG WT FULL SETPOINT","vt":"str"},{"t":"cont","v":"DIG WT EMPTY SETPOINT","vt":"str"},{"t":"cont","v":"DIG PUMP","vt":"str"},{"t":"cont","v":"TOTAL KW","vt":"str"},{"t":"cont","v":"BOIL PROGRAM STATUS","vt":"str"},{"t":"cont","v":"DIG PROGRAM STATUS","vt":"str"},{"t":"cont","v":"DIG TEMP MAX SP","vt":"str"},{"t":"cont","v":"DIG TEMP MIN SP","vt":"str"},{"t":"cont","v":"BAND MAX TEMP SP","vt":"str"},{"t":"cont","v":"BOIL TEMP STANDBY SP","vt":"str"},{"t":"cont","v":"BOIL TEMP MAX SP","vt":"str"},{"t":"cont","v":"BOIL TEMP MIN SP","vt":"str"},{"t":"cont","v":"DIG TEMP SCALED","vt":"str"},{"t":"cont","v":"DIG TEMP SETPOINT","vt":"str"},{"t":"cont","v":"DIG TEMP FINAL","vt":"str"},{"t":"cont","v":"DIG TEMP OFFSET","vt":"str"},{"t":"cont","v":"BAND TEMP FINAL","vt":"str"},{"t":"cont","v":"TANK TEMP OFFSET","vt":"str"},{"t":"cont","v":"TANK TEMP SCALED","vt":"str"},{"t":"cont","v":"BOIL TANK TEMP FINAL","vt":"str"},{"t":"cont","v":"CHANGE RESIDUAL WARNING","vt":"str"},{"t":"cont","v":"DOSE BIO WARNING","vt":"str"},{"t":"cont","v":"RESIDUAL BIN CONNECTED","vt":"str"},{"t":"cont","v":"CURING OFF","vt":"str"},{"t":"cont","v":"DIG OFF","vt":"str"},{"t":"cont","v":"RESIDUAL WEIGHT","vt":"str"},{"t":"cont","v":"DIG TANK FULL","vt":"str"},{"t":"cont","v":"CURE COOK REQ","vt":"str"}],"checkall":"true","repair":false,"outputs":62,"x":3415,"y":1520,"wires":[["fcadbd07.4a7c98"],["6a14566b.3cf9f8"],["1f972176.cb3d7f"],["691acb9e.34cff4"],["1616ff07.dd5a51","2f9d9560.505282"],["90659be8.65c4d8"],["a416ec9a.7d3068","56b8b88d.e90e08"],["8e42680d.b74348","f70dfc98.f7e5e8","b0adc049.ae98a"],["b81d2b67.510d","f79d2711.2163f"],["e3db4d.3fe80cb","37a4d4ee.4f412c"],["b3d997e2.756d98"],["11eb2292.43a5fd"],["6e18bcd9.4e836c"],["84075c1d.7255c8"],["44938c37.d73fac","c242e9f3.0613f8"],[],["420098ab.eafdc8"],["1fb2c4e6.058b7b","d279a90f.92f08"],["2154cb45.f310ec","a6b518b3.90ba48"],["31946a17.eb4726","5d2a9543.c21efc"],["cc2de4ea.14a23","1571c334.8fdcb5"],["f42a0c90.4d597"],["1fd4eb83.94d2e4","fe2fb154.8257b","1f6ae296.b544dd"],["c0d174c.19a2088"],["754f1058.4c2ea8"],["dccf489d.ada498"],["7d1d848f.9cdcec"],["2598ffed.b39d7"],["8de99747.f968d"],["ad9b8039.acc968"],["28c60f8d.eba1a8"],["38171ebb.9e0c7a"],["aa4c0bfe.b131a"],["a7ea4aaa.d5c9b8"],["fd875b0c.c8b108"],["afc80a0b.d03e5"],["795631f3.1f3918"],[],["470b648c.7657fc","5fbddd05.892fc4","a64dbee6.580e5"],["bb9f3294.756fd8","a52fe14.828d6a","fdef4eae.46535"],["e8da7963.786ee8"],["1fef1277.b2c316"],["685fc766.75e3b"],["9889a203.069d98"],["7957cbb3.3190f4"],["e02c85a2.0f75c8"],[],[],[],[],["4cba71fe.8a4948","2382c5ed.fe20ca","da61b1d0.24e31"],[],[],["a7c8574c.d4f46","4286cdd6.e533c4","591a45d7.abd9a4"],["79f05da8.0855a4"],["2cff5198.d9f816"],["35de24c6.66fb94","26120c1f.396354"],["a2a38139.70327"],["e7e4cb9c.ae084"],["f2ee87e8.bed4a8","857f8307.86355"],["ae8fc088.b4629"],["b71bcaa3.dd7a7"]],"outputLabels":["DIG LOAD CELL NORMALIZED","DIG WEIGHT NET","DIG WEIGHT FINAL","DIG WEIGHT TARE OFFSET","DIG TANK PERCENT FULL","UNLOCK DIG DOOR REQ","DIG TANK TEMP FINAL","DIG WEIGHT AVERAGE","AUTO MODE","HEARTBEAT TO HMI","BOIL LOAD CELL NORMALIZED","BOIL WEIGHT NET","BOIL WEIGHT FINAL","BOIL WEIGHT TARE OFFSET","BOIL WEIGHT AVERAGE","POWER ON COMPLETE","DIG MOTOR SPEED","ECO MODE","MANUAL MODE","CLEANOUT MODE","STANDBY MODE","JAM COUNT","DIG MIXER RECIPE","BIO DOSE COMPLETE","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",null],"l":false}]
10

It would probably be a little more efficient to check for equals rather than contains as If you use contains and the search string is short then it has to look for it anywhere in the string, not just at the start.

However, if you are seeing a delay that is noticeable to the human brain then I don't believe it is in that node. Even on a Pi Zero that is only going to take a fraction of a second (probably very small fraction).

11

So in that case do you think the delay is on the OPCUA side? We use node-red-contrib-opcua READ/WRITE nodes to write data to the OPC and read data coming from it...In this case, the switch node is only used for the READ

12

I have no idea. How long a delay are you seeing?

13

Sometimes nothing at all, sometimes up to about 8-10 seconds... Have yet to find a pattern

14

If it is that long then add some debug nodes and you should be able to work out where the delay is from the timestamps on the debug. If necessary configure them to output to the console so you can go back and analyse then later.

1 Like
15

This flow-timer subflow node might help - place as many pairs as you need then check in context for timings.

2 Likes
16

You should check the source of your OPC-UA Server. If it is remote, then you may have latency on your network or a system that is just slow.
Can you describe your system such that we can determine where to look for latency issues.

For instance:

  • PLC,
  • What software is your OPC Server?
  • OPC Server side OS,
  • Kind of resources the Sever side OS has,
  • OPC Server configuration, scan rates etc...
  • How many clients are connected at any point in time? Number of Served tags?
  • OPC Client Side OS, Kind of resources the Client side OS has...
  • Any correlation to the delays and any particular data with the delay. (are some value always late, others always early?)

With OPC it is not uncommon to have up to 3 seconds delay, depending on conditions. OPC-UA may be the same depending on your server. In your case this seems to be exacerbated by other factors.

17

Thanks for the responses...I just did a little test with the debug node and it writes "true" on the time that it should (When i hit the button) but I just sometimes get no response for some time..

PLC is a Siemens S7-1200. It uses an OPC UA server. I am not entirely sure about the Server side OS or the resources... I believe we are using Basic256Sha256 and I believe our scan rate is 100ms. In Node-Red I have two Read Client nodes and one Write Client node, and there are about 235 tags but not all writing/reading at the same time... We are using node-red-contrib-opcua nodes for this but am running on a Raspberry Pi (ComfilePi 10.2")

No patterns in particular, but as I said above i did a little test and it writes "true" to the tag at least in the debug panel on time. It does seem like there is a more likely chance of a delay if nothing has been hit in a while. I wonder if it could be slow uptake on the PLC side? Only other thing to report is that we are sending data not only to the dashboard but to a Ubidots cloud service, and sometimes, despite being connected to the internet, some values don't get sent at the rate they should. This is why I asked about the switch node but its sounding more and more like its the PLC/OPC.

18

I am interested in how the OPC server is configured and installed. Also, how you are getting the data. You are doing subscriptions vs. Asynchronous Reads?

Do you have a subscription Node? to the tags you want to monitor or force Reads by message or inject?

That OPC Server is that on the PLC? or is it installed on a PC in the network loop somewhere?

19

The OPC Server I believe is just on the PLC by default. Siemens S7-1200 comes with the OPC UA server. We are doing subscriptions, yes. There is a client node that either reads or writes that is configured with opc.tcp://ipaddress:4840. Then there are item nodes of the same package (node-red-contrib-opcua) that enter the ns and i numbers for the specific tag. Some are being read periodically with injects and others that get written get written on an event like a button push for example.

20

It can be that server will publish new value every 1000ms even sampling rate is 100ms.
Then if you read something what is inject interval?
Case can be that server will have reads on queue... do you use registerNode?
It will help server to keep variable ready for cyclic reading.