Communicating to AB Point I/O direct

Can OPC UA communicate directly to a Allen Bradley Point I/O Ethernet module (1734-AENT)?

If so, what device from the list will work best?

Thanks.

I am interested in this also. RSView32 used to allow communication directly to point I/O.

No, I don’t think so. I’ve been working as time permits on an Ethernet/IP scanner module, but it’s only about half-done. :frowning:

This could be risky if controlling equipment. Would definitely not be a good practice.

The PLC should be the owner of this IO.

I think as controls professionals we should understand the risks and eliminate them.
Talking to Point I/O directly is a great way to have SCADA interface with facilities stack lights, collect analog data and general status that doesnt need logic executed.

[quote=“DSI600”]This could be risky if controlling equipment. Would definitely not be a good practice. The PLC should be the owner of this IO.[/quote]I strongly disagree. With Ethernet/IP Class 1 connections, it’s no more risky than if the I/O lost comms with its PLC. Circuitry for output devices must be designed with comm loss in mind, regardless of the technology owning the connection.
Java’s use of garbage collection makes for highly variable latency, which may preclude some applications, but there’s no protocol reason Ignition shouldn’t connect to I/O.

My point was that Point I/O is designed to use the Producer / Consumer model directly with a Logix Controller. Which is somewhat “deterministic” with an RPI. Which would be the good practice when controlling this I/O with direct machinery.

I could see the need to control Stack Lights etc…directly, but I personally would not control real I/O with a PC utilizing a 3rd party DA server. As I think ( I could be wrong) but using the Ignition DA server that would fall under the Class 3 messaging (Explicit) which may not receive a response to the modules every I/O scan time.

I do agree that the loss of comms would have to be properly thought out if going the direct route to this I/O.