Is it possible for Ignition to talk directly to a device that talks EtherNet/IP without a PLC in between? Kepware or some other software/hardware?
I looked at the module you posted and it still looks like it would require a PLC between Ignition and my end devices. Is that the case? We want to avoid putting a PLC on the floor that is just there for communication purposes. Thanks!
Regarding the …“It still looks like it would require a PLC”… See Documentation:
https://www.automation-pros.com/enip1/UserManual.pdf which was part of what Mr. Turmel was trying to tell you. There are devices other than Rockwell Automation ( eg. ProSoft makes modules compatible with RA PLCs that do not need to be mechanically connected to the PLC ), but without knowing what you want to connect- the question is probably one that you can not get an easy answer for. There are all sorts of modules available for different types of communication that may be installed on an Ignition server. When you specify EtherNet/IP rather than Ethernet over a particular type of path such as IEEE 802.3i or 802.3j it might be better if you could spell out TCP (Y/N) UDP or IP or other tunnel protocol eg. TN3270 session over 10BASE-F. As Mr. Turmel would remind me, there is a support portion to be considered, the link similar to https://support.inductiveautomation.com yet you may want to look at the policy section there before calling the voice number. Please post your results here, there are always folks who want to know how you succeed or not.
Without the scanner option, it is an I/O slave and a target for other PLCs' message instructions.
With the scanner option, it is also an I/O master -- no PLC required.
In case it isn't clear from my profile, I'm the author of this module.
2 Likes
Hi @pturmel,
I see that under your module on the IA website the 8.1 platform isn't listed.
Does it, by any chance, support 8.1?
It has a different name now
Thank you!
It is listed in IA's Module Showcase. The main link to that has moved around on IA's website at various times--it is now in the lower right corner of the "Product" menu of the main site.
Has this ever been proven to work with Universal Robots?
I have not used those myself. If you get me the EDS file, I'll evaluate it for you.
I am not able to upload the eds file. A download link can be found at the bottom of the page.
Has this ever worked with Kaeser Compressor's SAM controller Ethernet/IP comms module?
What would be the best way to get an EDS file to you?
Screenshots of links are unusable. Is this the link you're referring to:
https://www.universal-robots.com/articles/ur/interface-communication/ethernet-ip-guide/
If so, this is the EDS file link for @pturmel: https://s3-eu-west-1.amazonaws.com/ur-support-site/18712/UniversalRobot.eds
Send an email to my Support Email address. With resources attached.
I would expect the Universal Robot to work just fine with my Scanner option. I've put together a sample XML config here:
https://www.automation-pros.com/enip1/UniversalRobot%20AS%20Sample.xml
Deployment notes:
-
This robot uses multicast packets. Ignition must have a network interface in the same subnet as the robot. No routing or NATing at all.
-
The IP address on Ignition's network interface in that subnet must be configured as the "Local Address" of the EtherNet/IP Host device.
-
The IP address in the XML, "10.20.30.40", needs to be replaced with the real IP address of the robot.
-
This configuration assumes you will command the robot from Ignition. If you wish to simply monitor the robot, the scanner module config in the XML must be changed to the "Listen Only" connection type.
-
The XML has the RPI set to 100ms. If you need to go faster you must carefully adjust the Garbage Collector settings in
ignition.conf, and carefully test for GC stalls.
1 Like
Thanks for getting the links, I had forgotten to include that as well. These are the ones I was looking at though.
Is this true of any device that uses multicast packets? Is it a network rule, and Ignition thing, or somehow specific to your module and this application? Just curious.
It is common for multicast packets, in general, to be sent with hop limit aka "Time To Live"== 1, limiting to one subnet. The EtherNet/IP Specification Volume 2 §3-5.2 requires TTL=1 by default, and when non-configurable. So, same subnet only.
Rockwell devices do not permit TTL configuration, that I've seen. Nor have I seen it on any other brands with EtherNet/IP capability. And I don't support configuring it in my module, either.
For all practical purposes in the EtherNet/IP world, multicast == same subnet.
I imagine that global media content distribution systems are the only significant users of multi-hop multicast.
2 Likes