Hello all,
CPU 1516-3 PN/DP, TIA V17, OPC UA server running on the CPU. I've got a Node-RED flow on an edge box subscribed to about 120 nodes, pushing them at our broker, four months without a complaint.
Yesterday the controls guy added a DB for a weigher and downloaded. Since then about half my nodes come back BadNodeIdUnknown and the rest carry on updating. Nothing's changed my side, the flow's the same file.
I restarted the Node-RED container, no change, then the OPC UA server on the CPU from the Online view. Same split, same nodes bad.
The bad ones are all in DB3 and DB7, the good ones in DB1 and the memory area, and the new block is DB5. Could someone explain what adding DB5 does to DB7?
How did you address the nodes in the flow, by string like ns=3;s="DB7".Weight or by numeric i= ids picked up from a browse? Post one bad one and one good one exactly as they are in the node config.
Numeric. I browsed with UaExpert when I built it and dragged the ids across. Bad one: ns=3;i=1327. Good one: ns=3;s="DB1".Speed. Hmm. I didn't notice they were different kinds until you asked. DB1 I did by hand later, the rest came out of the browse.
There is your split. The nodes the CPU exposes from the standard SIMATIC interface carry string identifiers built from the symbolic name, "DB7".Weight and so on, and those survive a download because the name is the identifier. The numeric ones came from a server interface someone generated in TIA, and when that interface was regenerated for the new DB the numbers were handed out again. Whether it is the identifier or the namespace index that moved I could not tell you without the project. The fix is the same either way.
Re-address the flow by string id, ns=3;s="DB7".Weight, or read the namespace array at session start and resolve by URI. Then the next download does nothing to you.
There's a writeup on the OPC UA side here: https://plctr.com/introduction-to-opc-open-platform-communications-for-plc-integration/
Changed the DB7 nodes to string ids and they came back straight away. DB3 is still bad in the string form though, ns=3;s="DB3".Level gives BadNodeIdUnknown as well. So half of the half, and I'm stuck again.
Is DB3 still exposed to OPC UA at all? Open the block and look at the accessible from HMI/OPC UA tick, on V17 it's on the block properties. If that came off in the download the string form fails too, the block isn't in the address space at all. Spelling's case sensitive as well.
Both, as it turns out. DB3 had the OPC UA tick off. The controls guy had copied DB3's attributes off the new weigher DB while he was tidying up the V17 project, so it dropped out of the address space completely. Ticked it, downloaded, all 120 nodes good.
Two faults at once, which is why none of it made sense. The flow was built on numeric NodeIds out of a browse and the download handed those numbers out again, and DB3 lost its tick in the same download, so even the string form had nothing to find. Every node is a string id now and the V17 tick is on the checklist for new blocks.
Why DB1 escaped I'm not sure. Built those by hand months ago and had forgotten. Thanks pnina and eddieb.