need help for wireless EtherNet/IP

genius_clark

Member
Join Date
May 2014
Location
Hebei
Posts
5
Hi,
There is a 1756-L61 connect the FLEX I/O 1794-ACN15 by Controlnet coaxial cable.
The question is could I just replace the 1794-ACN15 to 1794-AENT , and connect the PLC and I/O with RJ45?
Could I use some wireless AP to connect them by radio?
Is the radio as good as Controlnet coaxial cable?

THX!
 
Is the radio as good as Controlnet coaxial cable?

No.

ControlNet co-axial cable can run with zero lost packets and signal timing precision measured in microseconds. It is built for speed, reliability, and precision.

Radios will always drop packets and have delays that are greater than hardwired systems.

It is possible to design and install EtherNet/IP systems that work very well over radio, but only if you understand the limitations of IP radio and consider the features and drawbacks of your radio system carefully.
 
No.

ControlNet co-axial cable can run with zero lost packets and signal timing precision measured in microseconds. It is built for speed, reliability, and precision.

Radios will always drop packets and have delays that are greater than hardwired systems.

It is possible to design and install EtherNet/IP systems that work very well over radio, but only if you understand the limitations of IP radio and consider the features and drawbacks of your radio system carefully.

get it
and the 1st/2nd question are yes?
many THX
 
The question is could I just replace the 1794-ACN15 to 1794-AENT , and connect the PLC and I/O with RJ45?

You would have to replace the ControlNet modules in the controller chassis with EtherNet/IP modules as well, and reconfigure the control system to use EtherNet/IP.

You may be confused by the older 1756-CNB(R) and related ControlNet modules, which include a RJ45 connector on the front port.

This connector is a ControlNet Network Access Port, used mostly with the old 1784-PCC cards.

This port is similar in appearance to the most common type of Ethernet jack, but it is not Ethernet. It will not function if you plug it into an Ethernet switch.
 
Ethernet/IP works fine wirelessly and with the correct equipment, it can work over long distances within the same order of magnitude latency as a Cat5e. Ethernet/IP is actually a fairly slow, non-deterministic protocol and there is no reason to not use wireless. Even when running CIPSync for CIP motion you will get good results since CIP motion already takes the variable latency into account with the distributed clocks.

Other more advanced ethernet protocols that are deterministic, like Powerlink, ProfiNet, and EtherCAT require special planning and equipment to run wirelessly and it may actually be impossible to run EtherCAT wirelessly because of the way it changes packets on the fly. I know Powerlink has been used wirelessly with SafeIO and met safety requirements and that it required special wireless equipment, but I don't know the details.

I have even seen laser relay stations run Ethernet/IP many miles with better performance than a physical cable that would have to be routed over real terrain.
 
I don't have the time or inclination to debate the topic, especially in the context of the OP's inquiry, so I'll just say that my experience and opinion are dramatically different than yours, Cap'n.
 
Depending on your application, you might not want to use consumer grade products, but if you are using RPIs above 15ms on Ethernet/IP, then any modern consumer wifi device that can do bridging is fine. The fact is, an ENBT just isn't magical technology and it has jitter and latency itself that is on par with a good $50 wifi router.

If you need to be more around 5ms or using CIP Motion (using an EN2T or EN3T), then you'll want higher end, directional bridges (there are many brands than can keep jitter down to tens of microseconds in the $100 to $300 range).

For deterministic protocols that need to maintain jitter in the single digit microsecond range, you're looking at much higher end. To get under a microsecond, you're looking at stock exchange level quality, like LightPointe. LightPointe has the kind of products were it is actually faster/lower latency than a copper cable over any distance and faster than fiber over long distance because a cable can't be perfectly straight while a laser can be.

For instance, the Chicago and NY exchanges are connected via laser relay systems because it is faster than fiber that was run directly between the two cities; I believe they use LightPointe products.
 
Ethernet/IP works fine wirelessly and with the correct equipment, it can work over long distances within the same order of magnitude latency as a Cat5e.
Not quite but very close. In a lab setting yes but with real world industrial AP's no it does not measure up to the level of determinism you get with Controlnet.

Ethernet/IP is actually a fairly slow, non-deterministic protocol and there is no reason to not use wireless. Even when running CIPSync for CIP motion you will get good results since CIP motion already takes the variable latency into account with the distributed clocks..

This is true but you still don't have true determinism like you have with Controlnet but in 99.9% of applications it's good enough when done correctly. many people think they need true determinism but in reality very very few really do need full determinism.

Other more advanced ethernet protocols that are deterministic, like Powerlink, ProfiNet, and EtherCAT require special planning and equipment to run wirelessly and it may actually be impossible to run EtherCAT wirelessly because of the way it changes packets on the fly. I know Powerlink has been used wirelessly with SafeIO and met safety requirements and that it required special wireless equipment, but I don't know the details..

This is also true but even thought the protocol is deterministic it does not maintain it's level of determinism over wireless because the wireless hardware currently available to the market does not provide that level of determinism.

I have even seen laser relay stations run Ethernet/IP many miles with better performance than a physical cable that would have to be routed over real terrain.

This is also true but it's still not deterministic because the protocol itself is not deterministic. Relay stations would need to likely be running an additive-Gaussian channel Model for this to hold true.
 
I think the real world point Ken was pointing out was that one should not replace a Controlnet system with wired or wireless Ethernet and expect the same results from the application.

It may be ok if the Level of determinism ControlNet provides is really not needed but could be a huge issue if it is.
 
Then again I have some customer that just like to use ControlNet to keep IT Dept's hands off their gear. Seems like if it has an Ethernet cable IT thinks they own it and then you have that battle to contend with.
 
You would have to replace the ControlNet modules in the controller chassis with EtherNet/IP modules as well, and reconfigure the control system to use EtherNet/IP.

You may be confused by the older 1756-CNB(R) and related ControlNet modules, which include a RJ45 connector on the front port.

This connector is a ControlNet Network Access Port, used mostly with the old 1784-PCC cards.

This port is similar in appearance to the most common type of Ethernet jack, but it is not Ethernet. It will not function if you plug it into an Ethernet switch.

got this,i forget to tell you that there is a 1756-ENT.THX :cool:
 
THX for all if U !
The real problem is the PLC and the 1794-ACN15 are stay on the ground and the sensors are setup on a moving device.No long distance but stop rotating .And there is lot of dust and water. Now we are using flexible cable but there is not enough space so the cable are wearing and tearing.

My will is change the 1794-ACN15 to 1794-AENT and set the i/o on the rotating device. Connect the 1794-AENT and 1756-ENET with wireless device. or flexible RJ45 cable for backup,or both?

THX again!

a.png
 
What Ken said.
I’ve been in the industrial automation industry specializing in wireless data communications for 18 years (and I sell industrial hardened WiFi modems among other types) and I can’t recommend wireless of any kind for Produce/Consume unless you don’t need “real time” connectivity, you can adjust the RPI’s towards the higher end limits without causing problems in the application and you’re only producing a relatively small number of tags. Produce/Consume is far too sensitive to lost packets. The other thing worth noting is that expecting any “consumer WiFi” to “do bridging” with RPI settings of 15ms without any broken connections isn’t realistic in lab settings let alone the real world. For that matter, ANY WiFi will simply add to much latency for 15ms to be even close to working. It’s just not realistic. I wish Rockwell would update EtherNet/IP UDP (Produce/Consume) so that it could be adjusted to be more tolerant to lost packets but then again that would defeat the whole purpose of it which is to provide real time remote I/O.
With all of that said, if you’re using EtherNet/IP TCP (message instructions) then most wireless technologies including WiFi can easily be made to work. However you lose some of the flexibility you get with P/C and certainly don’t get real time data.
 

Similar Topics

Not sure how to word the title but here's my scenario. We have a carriage that moves at high speed with an energy chain and the cable bends in a...
Replies
11
Views
2,836
Hello nice to meet you, im new in here, I'm currently trying to convert code written in STL for a S7-400 to SCL for an S7-1500, because when i run...
Replies
5
Views
268
Hello, I am programming in S7-1500, V17. I have some blocks from a drive manufacturer that are not compiling and giving me an error "Invalid...
Replies
2
Views
273
Hi all, I’m new to programming and want to write a simple routine. Push start button, turns on sensor. 2 second delay before anymore logic read...
Replies
1
Views
289
Back
Top Bottom