Rainy Saturday experimenting with DeviceNet & CANBUS

I've wanted to experiment with this for a while, and this morning was the perfect time with the cold, heavy rain.

I have a 1756-DNB in my test rack, and a 1734-ADN adapter with several PointIO modules for testing. I configured the DeviceNet as normal and confirmed that the PLC was reading & writing the 1734-IE4C and 1734-OE2C modules correctly. I then used my CANUSB adapter to "plug into" the DeviceNet network, which I was operating at 125kbit. I like to use CANHacker (Windows software) to sniff the CANBUS as it does a pretty good job of organizing the IDs and also allows a trace with timestamps that you can export, if you so desire.

After opening the connection with CANHacker, I immediately started seeing the messages, although it wasn't as many as I would have expected (which made things easier). I went into my Controller Tags for the DeviceNet output so I could vary the 4-20mA output and see which CAN message(s) would change.

The message ID for the output data being sent to the PointIO module was "45D" with the data to follow. (circled in red below)
Channel 0 was bytes 2 & 3, although they were swapped (016F instead of 6F01).


You can then use CANHacker to inject messages onto the bus, so I took that same format, but altered the data. The OE2C is a 13-bit module, so 20mA would be 8192 in decimal format, or 2000 in hex format. Knowing that the bytes are swapped, I had to send 0020 instead of 2000. I set it to transmit at a periodic rate of 250ms and instantly noticed my multimeter showing 19.99mA but would fluctuate because the PointIO adapter was now receiving messages with the same ID from both the DNB module as well as my CANHacker software.


What was interesting was as long as I was sending repeated CAN frames, I could disconnect the 5-pin plug off the DNB module and the PointIO adapter did not fault. In fact, it continued to control the 4-20mA output strictly based on my CANHacker's output with absolutely no other handshaking. I would have guessed there would at least be a separate heartbeat bit between the DNB and I/O adapters, and that if it were lost, it would fault. Nope! It wasn't until I slowed the period to 1000ms that the adapter finally stopped accepting the CAN frames I was sending, and the meter dropped to 0mA.

There is an initial handshake that occurs (I'll attempt to sniff this next) when connecting the adapter to the DNB, and then it strictly becomes data transfer. What this means is that you can simulate that handshake through a custom application, or something like an Arduino, and control I/O directly without the PLC.

For me, this has no practical purpose...more like a proof of concept. I much prefer Ethernet connectivity to my components.

Anyone else have some cool hacks?

That's some good hacking !

Because your CAN tool was using the same message ID as the DNB to send these output data packets, the POINT module had no way to tell the difference between them, so it makes sense that it was following both commands.

The fact that this is so easy to do is one reason that safety protocols that run on CAN need more layers of signatures and checksums.

You'll find that during the connection establishment, the DNB and the 1734-OE2C negotiated an RPI value, probably of 250 milliseconds.

DeviceNet uses a default timeout of 4x the RPI, so that's why the 1734-OE2C didn't declare a timeout and break the connection until you dropped your cyclic transmissions to more than 1000 ms interval.

Ken Roach said:

That's some good hacking !

Because your CAN tool was using the same message ID as the DNB to send these output data packets, the POINT module had no way to tell the difference between them, so it makes sense that it was following both commands.

The fact that this is so easy to do is one reason that safety protocols that run on CAN need more layers of signatures and checksums.

You'll find that during the connection establishment, the DNB and the 1734-OE2C negotiated an RPI value, probably of 250 milliseconds.

DeviceNet uses a default timeout of 4x the RPI, so that's why the 1734-OE2C didn't declare a timeout and break the connection until you dropped your cyclic transmissions to more than 1000 ms interval.

Click to expand...

Thanks for clarifying Ken. I was curious where the 1000ms came from. No kidding about the safety aspect!!

I managed to capture the handshake and replicate it successfully. I was able to "initialize" the connection to the PointIO ADN and start controlling it without ever having it connected to the DNB module.

Years ago I was learning DeviceNet and developed an Excel spreadsheet that helps to easily decode the CAN ID for DeviceNet traffic.


I would be glad to know that this old document of mine can be useful to PLC.net members. The screen grab below explains how to use the MS Excel, file which is in the ZIP file that I will post next.

Here is the MX Excel file

Alfredo, very interesting. I'm going to look at this closer, but from what I've looked at in the few minutes I've had, it appears the node number (MAC ID) is being extracted from the CAN message ID. Very interesting and I'm looking forward to examining this closer.

Yes, that's exactly right I. Not only that, the CAN ID's 11 bit, which define the priority through NBA (non-destructive bit-wise arbitration) in DeviveNet define also the nature of the message. So higher priority messages, the group have CAN ID starting from cero binary are for slave responses. Master IO commands, explicit messaging have CAN ID starting with 01 binary, which is group 2, and so on. It is really cool
.