![]() ![]() |
Keyence, who I am using for fiber optic sensing of parts, has come out with a network module that communicates via Ethernet/IP. I would like to talk to this module straight from a mini PC using VB.net so I can analyze the fiber optic values.
I do know that the module outputs the information I'm looking for.
I do not know how to connect. Here are few options that I've come across.
1. OPC (requires me to setup an OPC server and client? sounds complicated just to pass a few a few bytes back and forth with a little module)
2. DDE (inefficient?)
3. Ethernet/IP (requires me to write my own class librarys? Available from OVDA.)
Are there any other options? I've run stepper motors off a serial port and setup IO via USB and by comparison this seems a pain in the a@@!
Also, the module can also be had in DeviceNet, CClink and EtherCat
I do know that the module outputs the information I'm looking for.
I do not know how to connect. Here are few options that I've come across.
1. OPC (requires me to setup an OPC server and client? sounds complicated just to pass a few a few bytes back and forth with a little module)
2. DDE (inefficient?)
3. Ethernet/IP (requires me to write my own class librarys? Available from OVDA.)
Are there any other options? I've run stepper motors off a serial port and setup IO via USB and by comparison this seems a pain in the a@@!
Also, the module can also be had in DeviceNet, CClink and EtherCat
![]() ![]() |
It's a shame that it can't be had in Modbus/TCP. That one you could write in a few hours. For EtherNet/IP, I would suggest buying a .Net component. Rolling your own is a pain.
OPC probably won't work. First, you'd have to buy an OPC server, and then either write an OPC client or buy a OPC client .Net component. More importantly, most OPC servers won't scan I/O, which is likely what this device is expecting.
There are some hardware options, like the AnyBus X, which can scan EtherNet/IP on one side and look like a Modbus/TCP server on the other. This is probably an expensive way to do it, plus the hassle of more hardware. Buying (or even building) an EtherNet/IP component is probably the better route.
EtherCAT has an open source stack available, although I'm not sure how nicely it plays with .Net. EtherCAT is a weird animal. I'd stick with EtherNet/IP for what you're doing. (Although, again, Modbus/TCP would be a lot easier.)
DeviceNet or CC-Link would require hardware.
-James Ingraham
Sage Automation, Inc.
OPC probably won't work. First, you'd have to buy an OPC server, and then either write an OPC client or buy a OPC client .Net component. More importantly, most OPC servers won't scan I/O, which is likely what this device is expecting.
There are some hardware options, like the AnyBus X, which can scan EtherNet/IP on one side and look like a Modbus/TCP server on the other. This is probably an expensive way to do it, plus the hassle of more hardware. Buying (or even building) an EtherNet/IP component is probably the better route.
EtherCAT has an open source stack available, although I'm not sure how nicely it plays with .Net. EtherCAT is a weird animal. I'd stick with EtherNet/IP for what you're doing. (Although, again, Modbus/TCP would be a lot easier.)
DeviceNet or CC-Link would require hardware.
-James Ingraham
Sage Automation, Inc.
![]() ![]() |
I would suggest some off the shelf .net drivers from a company such as Automated Solutions or Software Toolbox. If you write your own protocol driver for a one-off project, you may spend a disproportionate amount of time reinventing the wheel for the driver code. If it is a volume product, then writing your own protocol driver makes more sense.
Bill Sturm
Bill Sturm
![]() ![]() |
We've just completed a .NET library for Ethernet/IP and CIP messaging. As far as I know, we are the only company to offer the Ethernet/IP library stack for .NET, other companies like Automated Solutions have specific drivers based on EIP, but not the EIP library itself.
It does require a bit of knowledge about how to assemble packets to get data in/out of the device, but we built a ControlLogix driver off of our stack and we are very happy with the performance. Our development team can help with implementation issues.
Check out our web site, http://eshop.6dsystems.com/?product=eipnet and let us know if we can help. Also feel free to contact our development team (devteam (at) 6dsystems.com) if you want to discuss if our library is a good fit.
It does require a bit of knowledge about how to assemble packets to get data in/out of the device, but we built a ControlLogix driver off of our stack and we are very happy with the performance. Our development team can help with implementation issues.
Check out our web site, http://eshop.6dsystems.com/?product=eipnet and let us know if we can help. Also feel free to contact our development team (devteam (at) 6dsystems.com) if you want to discuss if our library is a good fit.
![]() ![]() |
Your use of this site is subject to the terms and conditions set forth under Legal Notices and the Privacy Policy. Please read those terms and conditions carefully. Subject to the rights expressly reserved to others under Legal Notices, the content of this site and the compilation thereof is © 1999-2013 Nerds in Control, LLC. All rights reserved.
Users of this site are benefiting from open source technologies, including PHP, MySQL and Apache. Be happy.
Fortune
Fourth Law of Thermodynamics: If the probability of success is not
almost one, it is damn near zero.
-- David Ellis







on 18 September, 2011 - 11:26 pm
