UDT OPC and Configuration Questions

[Hooovahh]

So I've worked with PLC integration in LabVIEW a little, but it was generally at the point that something was already working, and I helped modify it, or I would use stuff already setup.  But I'm at the point now where I need to design a system to communicate with an Allen-Bradley PLC and I have a few questions.

Are UDT (User Defined Tags) supported in the NI OPC Server, and the client side (DSC I/O Server or Datasocket)?  In simulation it looks like this manifests itself as Groups in the OPC Server with tags under a group.  And then in the Bound Variable, you read and write to the scalar values, and not the whole group of tags is this right?

When adding tags to NI OPC Server is there a convienent way to import all them from a PLC?  By that I mean when you are developing code for a PLC is there a file that can be generated which defines all the tags, addresses, data types, scaling, etc.  And if so how can I import these settings into the NI OPC so I don't have to manually enter data and settings.

Can there be multiple OPC servers on a network?  So lets say I have 3 PLC and two computers on the same network.  Is there anything wrong with running the NI OPC Server on both computers, and have them configured to each talk to each of the 3 PLCs?  I realize you can run one instance of OPC Server, on one computer, and then have both computers be clients to that one Server, but in my design each computer can be shutdown independently, and so I don't want to create a dependency where one is the client, and the other is a client and server, I'd rather each was the server for itself.

Where does Ethernet/IP come in on all of this?  I get the impression that Ethernet/IP is a different prototocl all together, but share some common features.  Does devices that communicate over Ethernet/IP also need a server client setup similarly to OPC?

[BoKnows]

The first part sounds right.  It'd be a bit awkward to have to write to the entire list rather than pick out the values you're specifically wanting to reference in your code.

I've never seen a way to automate things like this.  Granted, that doesn't mean it doesn't exist.  It wouldn't be the first thing I was ignorant about.

I wouldn't say "wrong" as much as I'd be curious to know if that's the best architecture.  If all three are looking to read/write to the same PLC, we'd see situations similar to the race conditions we see in regular code where each server would be clobbering what the last wrote.  You'd want some way to manage this within your architecture.  If you have the resources, I'd likely have one PC meant to be on permanently whether it is one of these three or not.  That PC could handle the server duties and help mitigate the need to allow those 3 you're worried about having the ability to be shut down.  If this isn't an option, I'm pretty sure you're capable of finding a way to manage this risk in your application.

It's a different protocol and it depends on the PLCs you're working with.  They tend to have various protocols meant to talk to them.  Each supports a subset of the crazy number of protocols available.  Some devices support Ethernet/IP.  If they do, you need to use that bus to talk to them.  If you're looking to do this, you'd want to take a look at the Ethernet/IP driver.  They run something of their own producer/consumer style that's independent of the architecture of the same name in LabVIEW.  A pro-tip for you: we have Ethernet/IP developers that watch these forums specifically looking for these types of issues.  If the forum title calls out Ethernet/IP, they're more likely to catch the post and offer their input as well.