Currently Citect has two drivers that
communicate with RSLinx directly, via it's API. The first is an OPC
client driver that talks to RSLinx's OPC Server. The second is the
ABRSLINX driver which connects to RSLinx's API. Both drivers
require a full version of RSLinx. I.e. RSLinx OEM or Gateway, with
software activation.
Both drivers can be used to connect to basically any device that
RSLinx can communicate with but here some thoughts to consider.
- OPC is a string addressed based protocol and thus there is no
advantage in using this protocol to connect to PLCs that do not
support string based addressing. At present the Allen-Bradley's
Controllogix type processors are the only ones that support
this.
- You can connect to the Controllogix processor with the
ABRSLIINX driver but you will have to set up the Controllogix in
PLC5 emulation mode. This is achieved by mapping registers of the
PLC into arrays, then giving these arrays PLC5 type data file
names. E.g. An array of integers, Array_Int[1000] can be mapped to
the N7 data table. Citect then reads the array from N7:0 to N7:999
as per a PLC5. (NB. I have not checked the maximum size). As a down
side though you lose the added functionality of the PLC's complex
data structures, so I do not really see an advantage in this
method.
- The OPC driver can still be used to connect to PLC5s etc, but
as they do not support string based addressing there does not seem
to be an advantage here. Also, status tags are not supported which
means there may be problems with redundancy.
My preference would be to use the OPC driver for the
Controllogix processor and the ABRSLINX driver for the other
processors.
|