is it possible to connect an Ethernet to CAN adapter such as EtherCAN to develop a DeviceNet system?
what would be the advantages?
If anyone has information on the wiring details..like for this case from the ethernet port to the EtherCAN adapter and so on...
Thanks
what would be the advantages?
If anyone has information on the wiring details..like for this case from the ethernet port to the EtherCAN adapter and so on...
Thanks
You will require an Ethernet to Device Net adapter. Device Net is not standard CAN.
On August 27, 2003, BobB wrote:
> You will require an Ethernet to Device Net adapter.
> Device Net is not standard CAN.
================^^^=============
Huhh?, Can you please explain what you mean with this statement?
From <http://www.port.de/cgi-bin/CAN/DeviceNet>
: DeviceNet is a CAN based Higher Layer Protocol (HLP)
: managed by the Open DeviceNet Vendor Association http://www.odva.org
:
Regards
Heinz
> You will require an Ethernet to Device Net adapter.
> Device Net is not standard CAN.
================^^^=============
Huhh?, Can you please explain what you mean with this statement?
From <http://www.port.de/cgi-bin/CAN/DeviceNet>
: DeviceNet is a CAN based Higher Layer Protocol (HLP)
: managed by the Open DeviceNet Vendor Association http://www.odva.org
:
Regards
Heinz
One of the biggest advantages of an Ethernet to CAN gateway is to connect a control network (CAN) with an information network that can be distributed world wide if you like. The most obvious use is getting service data or production data from the control network or set parameters in the control network. You should be carful with trying to control devices via Ethernet to CAN - its not a realtime communication.
Regards Heinz
Regards Heinz
The PKV-50 from Hilscher is a Ethernet to CAN Open or a EtherNet to DeviceNet bridge.
http://www.hilscher.com
http://www.hilscher.com
It's possible.
First problem: CAN works like ENet/IP Class D "multicast" in that messages are sent out to anyone who wants to see. Because of the nifty arbitration scheme CAN uses, a CAN bus running at 1Mhz can nearly have 10,000 packets moving per second (CAN packets are 1-8 bytes only!). Ethenet isn't so "lite" - those 1-8 byte packets will fatten out to 64 bytes or more, plus you'll need a pretty hefty CPU to handle 10,000 Ethernet multicast packets a second (PowerPC or Pentium class really). Or YOU'LL need very smart software running in your "EtherCAN" device to understand which traffic to "forward" to Ethernet and which can be dropped as local only. CAN doesn't include any form of "routing", so you'll have to do this by table lookup and/or creating your OWN CAN application protocol that include routing bits in the 11 or 29-bit id.
Second problem: most CAN nodes expect near-instant response, or at least response much faster than Ethernet expects. So your EtherCAN node may need to "proxy" for remote CAN nodes. So when a local node talks to a remote CAN node, your local EtherCAN node fakes a response to satisfy the local node, then forwards the request to the remote CAN which we now hope accepts the info.
My goal has been to do some similir things, but the effort is great & so it waits firmly in the "someday" pile. Since I've done a lot of stuff with Ethernet/IP, I have some ideas about linking EIP and DeviceNet.
Best regards
- LynnL, www.digi.com
First problem: CAN works like ENet/IP Class D "multicast" in that messages are sent out to anyone who wants to see. Because of the nifty arbitration scheme CAN uses, a CAN bus running at 1Mhz can nearly have 10,000 packets moving per second (CAN packets are 1-8 bytes only!). Ethenet isn't so "lite" - those 1-8 byte packets will fatten out to 64 bytes or more, plus you'll need a pretty hefty CPU to handle 10,000 Ethernet multicast packets a second (PowerPC or Pentium class really). Or YOU'LL need very smart software running in your "EtherCAN" device to understand which traffic to "forward" to Ethernet and which can be dropped as local only. CAN doesn't include any form of "routing", so you'll have to do this by table lookup and/or creating your OWN CAN application protocol that include routing bits in the 11 or 29-bit id.
Second problem: most CAN nodes expect near-instant response, or at least response much faster than Ethernet expects. So your EtherCAN node may need to "proxy" for remote CAN nodes. So when a local node talks to a remote CAN node, your local EtherCAN node fakes a response to satisfy the local node, then forwards the request to the remote CAN which we now hope accepts the info.
My goal has been to do some similir things, but the effort is great & so it waits firmly in the "someday" pile. Since I've done a lot of stuff with Ethernet/IP, I have some ideas about linking EIP and DeviceNet.
Best regards
- LynnL, www.digi.com
Lynn, may be you see things to complicated. In most cases it's enough to have access to a CAN/CANopen/DeviceNet network on order to gather service information or provide the controlling entity in the CAN network with new parameters. Exactly for this purposes CiA is defining a Standard (DSP309) describing which service functions a Gateway (from TCP/IP Ethernet, RS232, ... ) to CANopen should provide. The second part of the standard describes a protocol on this side: - Modbus TCP - ASCII based command set
And yes, it is intended to hide to largest amount of CAN messages in the CAN network from the Gateway user, and not as a bridge between different CANopen networks.
Best regards Heinz-Jürgen Oertel
And yes, it is intended to hide to largest amount of CAN messages in the CAN network from the Gateway user, and not as a bridge between different CANopen networks.
Best regards Heinz-Jürgen Oertel
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-2010 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
"Yeah, but you're taking the universe out of context."







