DeviceNet network performance

Hi,

I'm currently commissioning a production line using controlnet and devicenet. We seem to be experiencing some noticable delays using DN for Robot handshaking and other device triggering.
I've got a total of 11 nodes using a 1756 DNB scanner.
The network baud rate is 250 kbps with a RPI of 20 ms. All nodes are using the polled method with poll rate at every scan. The interscan delay is 10 ms.
Here is a breakdown of the nodes:

4 x PF40 4 IN / 4 OUT
4 X HMS Slave comm DN to serial 32 IN / 8 OUT (Weigh scales)
1 x HMS Comm adapter 14 IN / 14 OUT (Motoman UP20 robot)
1 x Woodhead SST-DN3 8 IN / 8 OUT (ABB IRC5 robot)

I'm thinking of tinkering with the RPI and interscan delay or going from polled to change of state. I'm not sure what the Heartbeat param. is though in COS??
I've only ever config. DN using the Polled method so any help would be great.

Thanks in advance Dave.

what about EDS files for your robots ?? are they current, have you downloaded them from robot´s web page ??, same for woodhead SST, etc. What version of rsnetworx for dnet are you using ??
edit: have you read the devicenet bible ???

Hi Bill,

ABB robot has the lastest EDS, this was done ABB UK as the robot is using the latest woodhead adapter. I'm using rsnetworx v 9.00.

Thanks Dave.

What's a "noticeable delay" ?

At 250 kb/s each of those nodes should poll in 1 or 2 milliseconds, so you should be getting input data every 20 milliseconds (the RPI between the Logix and the DNB).

Since at least two of your devices provide an interface between DeviceNet and a much slower serial interface, I wouldn't expect fast reactions from the end device on the far end of the serial link.

But again, "noticeable" and "fast" are not objective measurements until they have units and values.

I'm thinking of tinkering with the RPI and interscan delay or going from polled to change of state. I'm not sure what the Heartbeat param. is though in COS??

Click to expand...

I'm not a Devicenet expert by any means, but my last project was a fairly large Dnet implementation, about 40 nodes at 250kbps with safety modules, servo drives, and remote I/O. I tinkered around with polled and COS at the beginning and found that I got WAY better performance from change-of-state. The drawback is that not all devices support it. The heartbeat parameter specifies how often the scanner will force a comms update even if a "change of state" hasn't occurred.

Thanks for the informative replies.
I should have added that I'd set up some cycle timers for different process elements.
One of which led me to the original post.
Timer start = Output to robot "Pick part"
Timer stop = Input from robot to PLC "Robot in Pick zone" (Output sent before first move)

The average timer value was 0.5 sec, at worse 0.9 sec. I understand this contains plc scan and robot process time but I was expecting better.
I understand the nodes with serial devices will perform slower, but the line is outside of cycle time and I'm looking for small gains.

Thanks Dave.

DeviceNet multivendor performance and compliance analysis is one of my specialties, so I have a lot of tools (FrontLine NetDecoder, A-B DNet Traffic Analyzer, etc) and tricks up my sleeve. If you happen to have a 1784-PCD card, we can pursue direct analysis using the A-B DNet TA Lite.

The controller can help us do some timing analysis.

A quick way to determine how the network performance affects the responsiveness of your robot interface is to use the Scan Counter from the Status tags for the 1756-DNB.

When the "Pick Part" output turns on, copy the ScanCounter value into a DINT tag. Also use a GSV to get the current value of the CST (Coordinated system time) and store that in a DINT[2] array.

When the "Robot in Pick Zone" input turns on, subtract the stored value from the current ScanCounter value. Use another GSV to get the current value of the CST, and subtract the stored DINT[1] value from the current DINT[1] value.

That will give you the number of DeviceNet poll cycles that have been completed, and the number of microseconds that have elapsed between those events.

Ken,

I've added the code and the DN poll cycles, that have been completed between PLC "pick" output and Robot "In pick zone" Input is on average 30.
The ms value that I'm getting from the CST DINT[1] seems to be the same (480) I seem to get meaningful values from CST DINT[0]. When the two values are subtracted it is around 814451.

Regards Dave.

Good catch on the CST; the first DINT is of course the least-significant and the second is the most-significant.

What those values tell us is that the 1756-DNB is polling all the devices in its scanlist 30 times in 0.814 seconds. That means a calculated scantime for all the polled devices is 0.814/30 = 27.1 milliseconds.

If 10 ms of that is the Interscan Delay, your total time for all those DeviceNet devices to respond to poll is just 17 milliseconds. Even if you were able to pare part of that down, the DeviceNet communications delay is a tiny part of the 500 to 900 milliseconds it takes for the robot to react to the command.

Changing to another communications method (COS versus Polled) or a faster data rate is going to yield maybe 5 milliseconds of extra speed. You might be able to decrease the Interscan delay another 2 to 5 milliseconds.

What you've proved is the network's contribution to the time elapsed between an action command and the action response.

Sort of off topic, but I have noticed differences in response of FANUC robots on DeviceNet Vs. ABB Robots on DeviceNet. The two companies approach DeviceNet communication differently. FANUC does most of the communication through an ASIC before mapping the data into the robot memory and ABB accomplishes the communication mostly through a software driver on the robot controller. I have done similar applications with both robots and you can perceive the response difference between the two.

Also, on the older controller I thought there was a setting that affected the update rate between the ABB DeviceNet communication board and updating the robot memory (kind of like the RPI setting on the ControlLogix). Of course if I remember right if you get this too high it will affect the robot program processing time. I do not know if that is still there on the newer PC based controllers, but I have not been that tight on cycle time in quite awhile.

Doesn't really help with your issue, but it is interesting how different companies approach problems.

Darren

Thanks for the assistance Ken, a good fault finding tool. I will contact ABB UK to see if they can improve response. It may be the latest woodhead dn adapter that the robot is using.
Good point Darren, It looks like all roads point to ABB.

Thanks Dave.

Austin79 said:

Hi,

I'm currently commissioning a production line using controlnet and devicenet. We seem to be experiencing some noticable delays using DN for Robot handshaking and other device triggering.
I've got a total of 11 nodes using a 1756 DNB scanner.
The network baud rate is 250 kbps with a RPI of 20 ms. All nodes are using the polled method with poll rate at every scan. The interscan delay is 10 ms.
Here is a breakdown of the nodes:

4 x PF40 4 IN / 4 OUT
4 X HMS Slave comm DN to serial 32 IN / 8 OUT (Weigh scales)
1 x HMS Comm adapter 14 IN / 14 OUT (Motoman UP20 robot)
1 x Woodhead SST-DN3 8 IN / 8 OUT (ABB IRC5 robot)

I'm thinking of tinkering with the RPI and interscan delay or going from polled to change of state. I'm not sure what the Heartbeat param. is though in COS??
I've only ever config. DN using the Polled method so any help would be great.

Thanks in advance Dave.

Click to expand...

I just had a 9 node network with goofy data-disappearing issues on high-numbered nodes, and the solution was to increase the interscan delay from 10mS to 20mS. Response speed is not an issue with these devices, so I'm not worried. But, it was a real chore to drill down to find that the interscan might be the problem. All my slaves were POL data, with no COS stuff mapped, so that might have been the critical point.
Either way, its fixed, and I'm on to the next thing!

COS helps a lot. worked at a site with over 50 dnet networks all typically over 30 nodes. it was setup to really only transfer the needed data.