Devicenet Question

written customer micro-controller software that initiates a Polled connection to a devicenet master. The Poll response is fragmented over 8 messages and the problem is that the each message is being transmitted approximately every 1.1 milliseconds, which is to fast for the micro I am using. Subsequently I miss, 2 out of 3 messages from the Poll response, but eventually all the data is finally received after a delay between 2 and 5 seconds.

Anyhow the question is can or how do you control the poll response message timing. I can not find anything in the Devicenet protocol or in the manual for the slave device that directly addresses this question. At this time my best guess is that it is related to the "expected packet rate", simply divide the packet rate by the number of messages in the poll response to get the maximum interval between messages. But I was hoping someone could confirm this is how devicenet works. Thanks

Scott Jones

While "Master / Slave" are common terms in digital communications, they aren't strictly applicable to DeviceNet.

In a typical Polled I/O system, the "Master" is the client, and is typically a PLC or PC controller.

The "Master" requests I/O connections from "Slaves", i.e. Servers. These are I/O blocks or motor controllers or sensors. The Client sends Poll commands, and the Server responds.

I'm a little confused by your post. Are you writing firmware for one of these devices, or are you troubleshooting a systems with components from established vendors ?

The fragmentation you describe is probably the standard DeviceNet fragmentation protocol. DeviceNet carries only between zero and eight data payload bytes per frame. To transmit a data object of between 9 and 255 bytes, DeviceNet nodes use a Fragmentation protocol where a fragment number is inserted as the first data byte, followed by seven data bytes. Fragments are transmitted in sequence, one after another. No acknowledgements or additional polls are used to request fragments.

I have never seen a device that allows a user to adjust the time between fragment transmissions. Generally the whole data object is considered one block, and the fragmentation protocol is transparent to the user.

Expected Packet Rate (EPR) is essentially a timeout value. If a Polled server node does not receive a Poll from the client for 4x the EPR, it will declare a timeout.

Thanks Ken,

Yes, I am writing custom firmware for a micro-controller to behave as a Devicenet Master/Client. I have only included the bare bones minimum in the software to allocate the Polled connection and set the packet rate, setting the packet rate is necessary to change the Slave/server from the configuration state to the established state.

The problem I am having is with the Poll response, which is fragmented according to the standard Devicenet fragmentation protocol. There are 8 CAN message frames in the response and they are coming to fast for me handle in the micro-controller. They are coming at a rate of 1 message every 1.0 to 1.1 milliseconds and I am looking for way to slow this down. I agree that it does not look like there is any direct way to control the poll response timing within the devicenet protocol, which is typical with other CAN protocols I work with including CANOpen and J1939. But it must be set some how, I find hard it believe that it would be set at 1.1 milliseconds, which I think you would agree is extremely fast.

So I came up with a theory that the rate of the poll response is related to the "expected packet rate", since it seems logical that the poll response must be faster then the anticipated (i.e. expected packet rate) of the Poll message being sent by the Master/Client. The expected packet rate is being set to 10 milliseconds (this is a mistake and should have been set to 100 milliseconds), so if you do the math the maximum interval in the poll response messages would be 1.2 milliseconds. In practice it would actually have to be slightly faster then that and I though it was to much of a coincidence that the actual rate was in the 1.0 to 1.1 millisecond range.

Unfortunately, I am in New Jersey and the system is in Utah so I can not play with the expected packet rate setting. Or I could just test it and confirm my thoughts. In addition it is a military project that has been in the field for nearly a year for testing and I am not allowed to make any changes to the software until I know with 100% certainty what the problem is and how to fix it. If I can confirm how the Devicenet fragmented protocol sets the message timing, I think I can say with certainty what the problem is and how to fix it. The problem involves data that is not critical to the operation of the control system and eventually, 5 to 6 seconds, the data does get refreshed so there is not a lot of urgency to fix it, but I need to fix it before the system is released to the military later this year. I expect to be making a trip to fix the problem next month. Any thoughts about my problem would be greatly appreciated.

Scott Jones

Re: DeviceNet fragment timing

DeviceNet logical I/O connection settings like EPR (timeout for Polled connections) or RPI (rate for Cyclic connections) are part of the connection establishment procedure because they're part of the Connection Object.

A client can decide on its own how often it polls the server, so you have the option for how often you request the whole connection worth of data. In Allen-Bradley scanner modules this is called the Inter-Scan Delay.

But the time between fragments isn't part of the Connection object. I think you'll agree that most of the time the goal is to get all the fragments from the server to the client as fast as possible.

Attached is a screenshot of the Frontline Test Equipment capture of a fragmented Client/Server Polled I/O connection. You'll see that the time between the fragments is about 1.1 milliseconds, even though the time between Polls from the Client is more like 90 milliseconds.

Thanks

Ken,

Thanks you for your help, though your answer was not what I was hoping to hear. The micro-controller is running a pretty large program and has a scan time of about 3 milliseconds. I have no way of buffering the data so I am missing 1 or 2 messages each scan. If the devicenet for the poll response is stuck at ~1 millisecond there is not much I can do with just software changes. Thanks again for your help.

Ken,

One quick question, what as the "expected packet rate" set in the polled connection that you setup and tested?

Scott

That capture was actually from a customer site where an AC drive sometimes fails to transmit all of its fragments (32 byte Polled I/O connection).

The Client in that case is a standard Allen-Bradley 1756-DNB scanner module, and the EPR is 75.

Note that the Group 3 Explicit Message service being used to configure the I/O connection includes an ACK in the fragmentation protocol, where ordinary Group 2 Client/Server poll exchanges do not.

While using the Explicit Message service might allow you to control the speed at which fragments come through by allowing you to acknowledge them individually, it would mean a more complex rewrite of your software. As you mentioned, creating and configuring a Group 2 Poll connection is much simpler than doing a UCMM or a Group 3 Explicit Message connection. It might also not be compatible with the I/O device you're using.

Ken, thanks you help has been invaluable. At least I know which way I have to go to fix the problem. To respond to your post and hopefully further everyone's knowledge of devicenet that is reading this thread. The device I am communicating with is a Eaton/Cutler-Hammer D77D-DNA devicenet gateway. It is used in Eaton motor control centers in order to network motor starters, circuit breakers and other devices. This gateway is a Group 2 only device that does not support the UCMM. It is my understanding that the "acknowledge" fragmentation protocol is only used for explicit messaging and I/O messaging uses the un-acknowledged fragmentation protocol. I re-read the fragmentation protocol (great read if you have insomnia! LOL) this morning and I am surprised that the protocol does not directly address the rate at which the un-acknowledge fragmented messages are to be sent. I found one statement that said the messages are sent out "back to back", but that was it.

I can't thank you enough for you help and I will be sure to let you what if any solution I come up with. I am working on a possible software solution now but don't have a lot of confidence that it will work, but it is worth a try.

Scott Jones

I am using a dcs japanese to communicate via devicenet it uses a software called sycom for configuration and in this software we need to manually configure the EPR values of PIT and FT but I did not find any literature that explained what values to put for each one in the rockwell networks I found Only the EPR of 75 but with this value the network is falling a lot and giving a lot of hartbeat, so I increased on my own account the values and improved but still falls sometimes, and before with plc rockwell this did not happen, could anyone help.