LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

NI OPC Server Reinitialization and Troubleshooting Problems

Hello,

i have a problem concerning the connection between my LabVIEW application (which is using NI OPC Server) and my two Siemens PLC 1517er CPU's which are configured as OPC Server. On LabVIEW Side the "Channel" is configured as Client and it consists of two Devices (PLC1 and PLC2). The Channel uses the Siemens TCP/IP Ethernet Driver. Version of the NI OPC Server Software and the driver is 5.19.492.0.

To my actual problem:
I get significant problem to establish the connection between LabVIEW and the PLC's via OPC when i start/boot the systems in the wrong order...
So when i first start the PLC1 and PLC2, wait for them till they are running and then start the PC with my NI OPC Software (which is autobooting) then the connection establishes and my LabVIEW application works totally fine with my configured PLC Tags and so on. 

Anyway, I get a huge problem when i first start the PC with NI OPC Server and start the PLC's or basically plug-in the ethernet cable afterwards....
In that case connection doesn't establish.. it tells me in the NI OPC Quick Client that the "Quality" of the configured PLC Tags is bad.. (so basically it can't read them and in the System DB the error bit is true... so far so good. 

Bad Tags after wrong Boot OrderBad Tags after wrong Boot Order

The main problem from now on is, that it is extremely complicated to get out of this error state to get the connection established again. 
What i tried so far:

- Disconnect and Connect again in the NI OPC Server Software in the Runtime column ..no effect

- Reinitialize NI OPC Server Runtime in the Runtime columns ..no effect

These functions doesn't helpThese functions doesn't help

 

- Exit the NI OPC Server Program in the Windows Task Bar (down right corner) and restart ...no effect

Restarting here doesn't helpRestarting here doesn't help

 

- Restarting the PC.. no effect

- Restarting both PLC's.. no effect

The point is that i have to shut down both the PLC and the PC at the same time and then make sure that the PLC's are running before i start the PC again. Then it will somehow catch its "Tag-Table-List" or whatever.. and it will read it again and the connection is established. 
Since i'm Building an industry application where the PLC's are doing a lot of other stuff in the background, i don't really want to shut down any PLC except in grave situations. And concerning that you can't get out of this error state so easily is right now a death criteria for me using the NI OPC Server sadly. It will be no time till the customer is complaining why it is so difficult to establish this connection again. I really like to work with the NI OPC Server in my LabVIEW application so i'm urgently looking for an solution to this. 

Basically i'm thinking about:

- Maybe i missed a point in the configuration where the System can fetch it's "Tag-Tables" automatically every x Minutes or so ? 
- Is there something like an "OPC-Method" where i can trigger an reinitialization from PLC program or LabVIEW program point of view.
- Actually why isn't the Reinitialization of the NI OPC Server in the Runtime Column not working. I totally expected that it should do the job.
- Maybe someone had similarproblem and it disappeared with newer Version of NI OPC Server ?
- Maybe i could use another "Driver" which also works for the SIEMENS PLC but without the described problem ?
- Is it possible to program something in the PLC side (OPC Server) to reinitialize the Server from this side ? (sorry if this is not totally fitting in this forum, but maybe someone know)

Thanks for your Help!

DRobin

0 Kudos
Message 1 of 2
(568 Views)

I was able to narrow my problem down.
It just occurs when im using a VM and run the "NI OPC Servers 2016". 
On my usual Windows it works perfectly fine. (tested plug-off of cable and "wrong" boot order)
It always "finds" the Varaible Tags (Quality = Good) and the error bit always resets to 0.

I didnt examine the behaviour on the VM any further but it has somehow to do with the assignment of the IP adresses when the VM starts or when "Eternet Bridge" from my OS to the simulated VM OS is assigned.

Greetings,

DRobin

0 Kudos
Message 2 of 2
(515 Views)