Talking to AB ControlLogix using LV 8.2.1 w/DSC

[SixtyPlus]

I need to program an application in LVDSC 8.2.1 will communicate with an AB ControlLogix processor.  The installation will be an executable, hundreds of miles away.  How can I program the Shared Variables without being connected to the processor (assume it will use RSLinx OEM)?  I have been provided Tag names such as "Tool_2_1_Temp", as opposed to register addresses.  Should I use DataSockets and Shared Variable Constants instead of Shared Variables?  What would the address be?

[Doug M]

Hi SixtyPlus,

Let me see if I understand your scenario -- you want to program your application without access to your hardware? Is that correct?

If so, my next question is whether you have access to the RSLinx software itself on the machine you will be doing development?  This is really the most important question -- typically an OPC server will allow you to save a configuration file with all the alias names of registers that you have set up.  If this configuration file is loaded into the OPC Server, then any OPC client that browses to that OPC server should be able to see all the names of the configured OPC items, such as "Tool_2_1_Temp", even if the hardware isn't actually connected to the system.

If this is the case, you should be able to develop your DSC application just fine, because you can create and bind shared variables to the OPC items with the correct names already loaded.  If you create OPC client I/O servers in your LabVIEW project and then create shared variables bound to the items published by these LabVIEW I/O servers, if you take this project to another machine, it should behave okay as long as on the machine where you install the application you have the same installation of OPC server software (in your case RSLinx) with the same configuration file loaded used in development.

Now, if you don't have access to the OPC Server on your development machine it becomes more difficult.  You can manually enter the paths to bind to for shared variables as long as you get the path right (for example would be something like "My Computer\My Library.lvlib\OPC1\Channel_1\Device_2\Bool_8" where OPC1 is the name of the LabVIEW OPC client I/O server in the LabVIEW library and Channel_1\Device_2\Bool_8 is the name/path of the specific I/O item as published by the OPC server).  What you can't do is configure the OPC client I/O servers in the shared variable library that contain the specific information on how to connect to the OPC server.  So without the OPC server installed, it is pretty difficult to get a shared variable library fully functional because you can't configure the OPC client I/O server.

Moving to the DataSocket API.  The DataSocket API is polymorphic in the sense that you can use it with various protocols.  You can use it to programmatically read and write to shared variables using a URL such as "psp://computer/library/shared_variable".  The advantage of using the DataSocket API for reading/writing shared variables rather than using shared variable reference nodes is that you can programmatically feed a different URL to the DataSocket functions, whereas shared variable reference nodes are hardcoded to a specific shared variable.  However, using the DataSocket API to read/write shared variables still requires that the shared variable library be properly configured with OPC client I/O servers that have been pointed to the correct OPC server.

You can also use the DataSocket API to read/write OPC items directly using a URL such as "opc://localhost/KEPware.KEPServerEx.V4/Channel_1.Device_1.Tag_2".  In this case you could enter OPC URLs without having the OPC server installed during development as long as you knew how it will appear when registered on the machine, in this case "KEPware.KEPserverEx.V4", as well as the names of the data items as they will appear.  The disadvantage of using this method is that you have no other DSC features available for the data, such as datalogging, alarming, security, etc, since all of these features come via shared variables.

Hopefully this answers your questions!

[SixtyPlus]

Doug, you understand my problem precisely.  And I do not have access to the target computer / RSLinx.  Thank you very much for the information, as intimidating as it is.

[Doug M]

Yeah that definitely makes it more difficult.  I would do anything I could to get the OPC server intstalled locally during development.  You could do some or most of the development without acces to the OPC server, then take a development machine to the end location with access to the OPC server to finish development up, point the LabVIEW client OPC I/O servers to the correct OPC server, save, build and deploy the application, but if even that isn't an option and you have to develop and deploy the application never having access to the OPC server, it would be very difficult to do, at least if using shared variables, in fact I don't know how you would do it.  You could do it if you are only using the DataSocket API using direct connections to OPC items as I mentioned, but you still need to know the exact URL of what the OPC items will be on the end machine.

Message Edited by Doug M on 06-05-2007 02:43 PM