Local & Remote I/O

Local goes through the backplane, but with todays networks it is almost a moot point.
You need to know your application requirements before even asking this question.
 
Local is always faster ... except... with controllogix, it depends... Newer and faster I/O communications systems give you a lot of power to make the I/O as responsive as you want. The bottleneck can end up being in the I/O hardware itself. More details please.
 
Local is always faster ... except... with controllogix, it depends... Newer and faster I/O communications systems give you a lot of power to make the I/O as responsive as you want. The bottleneck can end up being in the I/O hardware itself. More details please.

No-one has qualified "faster"... Considering that ControlLogix I/O transactions are "produced/consumed", it is up to the consumer to receive the latest produced data from the producer, and that is scheduled.

Any data on the network will always be "faster" within the local chassis, that's a given, considering there are fewer "hops" involved. As already hinted, there are techniques that will enable the controller to "see", and act on, remote data faster than local chassis data.

In summary, it is possible for a controller to respond to remote data faster than local data, it just needs configuring to do so...
 
Local is always faster ... except... with controllogix, it depends... Newer and faster I/O communications systems give you a lot of power to make the I/O as responsive as you want. The bottleneck can end up being in the I/O hardware itself. More details please.

No-one has qualified "faster"... Considering that ControlLogix I/O transactions are "produced/consumed", it is up to the consumer to receive the latest produced data from the producer, and that is scheduled.

Any data on the network will always be "faster" within the local chassis, that's a given, considering there are fewer "hops" involved. As already hinted, there are techniques that will enable the controller to "see", and act on, remote data faster than local chassis data.

In summary, it is possible for a controller to respond to remote data faster than local data, it just needs configuring to do so...
 
Which is faster , and why is it faster , local or remote I/O ? This would be for Allen Bradley Control Logix .

Local is fastest.

Remote I/O must be transmitted on a serial data link and then transferred to the CPU via the backplane's parallel data bus. Local I/O connects directly through the parallel data bus.

As has been said, you may slow down updates of the local I/O to make the remote I/O faster, but local gives you the capability for the fastest possible I/O updates.
 
Depends, Ethernet I/O can be really slow if there is a lot and Ethernet IP between processors can be really slow if there is plenty of data being transmitted. A while back I did a job with 17 processors on Ethernet IP and about 1500 words floating around the network. When I was online with the programming tool looking at 3 programs online at the same time it was like a ruddy serial link! All un-managed switches - managed MAY have helped.
For remote I/O I normally use CompoNet - it is a CIP network but very few have taken it up. It is a serial network and very fast - twisted pair screened over 30 metres and the update time on the network is 1 ms for 1000 I/O! Faster than the processor scan time by miles and faster than the I/O themselves!
If I was going to use Ethernet for comms and I/O response was critical my choice would be EtherCat to be honest - not Ethernet IP.
Trouble with Ethernet IP is all the stuff on it - processors - screens - SCADA and the like - gets as slow as a wet week!
 
Remote I/O v Distributed I/O

I don't have time to get into great detail right now on the subject matter, but I'd just like to make a passing comment or two on what I've read so far.

Bit_Bucket_07 is quite correct, if the OP is asking what they appear to be asking.

The OP referred to Local v Remote I/O for a ControlLogix. So we would be talking 1756-RIO or 1756-DHRIO modules. Remote I/O is quite slow by today's standards. It is most definitely slower at communicating with the controller than Local I/O in the chassis. These modules are primarily used for applications where it is necessary to communicate with older equipment and so they are chosen more out of necessity than for their throughput.

The references to "todays" or "newer" communications networking transport methods, such as Ethernet, or the like, are not relevant here, if indeed the OP meant Remote I/O proper, and not the category which Ethernet, or the like, do fall under - namely Distributed I/O.

So either the OP and some of you guys are mixing these two terms up, or the OP knows what they are asking, and it's just some of you guys that are mixing them up?

If it's a case of the former, then proceed to discuss Distributed I/O as you were.
If the latter, then it's a much narrower discussion.

Either way, I thought it important to make that distinction.

Regards,
George
 

Similar Topics

Hello everybody, I have a vendor system that has some remote monitoring (read only) and remote control (read/write) data that is available via...
Replies
7
Views
2,804
Hello, I am looking for your suggestions for methodologies to sync process setpoints across a local HMI and remote SCADA system. Background...
Replies
18
Views
2,023
Hello, Late this year I'll be preparing the replacement of old Rockwell PLCs (SLC, Micrologix, one S5 and some compact logix) to Control...
Replies
4
Views
1,620
I have a panel in front of the equipment with a PanelViewPlus 7 standard with Factory Talk ME and a Factory Talk SE HMI up in the control room...
Replies
3
Views
2,104
Hello! Anyone worked Armstrong VFD.I am unable to find which connection can be used to local/remote or Hand/Auto? Reference Manual...
Replies
0
Views
1,380
Back
Top Bottom