topic Re: DeviceNet dropout issues in Automotive and Embedded Networks

DeviceNet dropout issues

1stevek — Fri, 11 Feb 2005 13:48:14 GMT

I am running a PXI-8461/D with 4 Danaher absolute encoders at 500kb. No matter what configuration settings I use, the encoders dropout after short period of time. Does anyone have a means to troubleshoot DNet on a PXI chassis? Does anyone use the 8461/D and have no problems with dropout?
Thanks

Re: DeviceNet dropout issues

TongY — Mon, 14 Feb 2005 19:27:45 GMT

Did your devices dropped out because the power was lost? For the current DNET driver, it cannot detect the power loss on the device, hence when the dropout happens, the driver would not know when the power is back--configuration might be changed during the power loss which causes error.

Re: DeviceNet dropout issues

1stevek — Tue, 15 Feb 2005 20:29:10 GMT

No, there is no power loss. It appears in most cases that one encoder loses the bus first (the bus indicator on the encoder flashes instead of being on solid) and the others continue working, but then they all follow in time. THe 8461 doesn't even realize they are missing, other than giving me a repeating error/warning that the current read data matches the previous data. I have been using this to determine that the bus is lost, but I need a way to figure out why they are losing the bus.
I have experienced the fact that the 8461 doesn't recognize the loss of power, as I was removing bus power (after closing the DNet connection) when the loss happened. Simply restarting the VI was insufficient, I needed to reboot the PXI chassis.
Is there a RT DeviceNet monitor available in the 8461? In the future? Suggestions?

Re: DeviceNet dropout issues

TongY — Wed, 16 Feb 2005 17:03:11 GMT

When am instrument dropped out, the DNET driver throws an error that the current data is repeating the old ones. It cannot tell how the instrument was dropped out and the only way to reset the network is to power cycle the PXI chassis. There is no Bus Monitor option for the DeviceNET cards.

The R&D team are currently working on improving these limitations in the future versions of DNET driver. Please feel free to submit a product suggestion at the following link if you think there are additional features that the DNET driver should include. Thank you.

http://digital.ni.com/applications/psc.nsf/default?OpenForm&temp1=&node=

Re: DeviceNet dropout issues

biker2000 — Thu, 17 Feb 2005 00:06:55 GMT

Hi 1stevek,

I'm not sure, if it helps with your particular encoder devices, but try this:
Right after the Open DeviceNet Interface VI, call the Set Driver Attribute VI with the following parameters:

<User Supplied AttrID> = 0x8000008F (or 2147483791 in decimal mode)

Attr = 0xA (or 10 in decimal mode)

AttrID = '<User Supplied AttrID>'

That sets the time between successive transmits of explicit message requests by the NI-DNET interface (for all objects of that interface) to 10 ms. The default is zero, which provides the fastest turnaround time for explicit messages.
However, the default turnaround time might be too fast for your devices, which could causes them to stop communication.

-B2k

Re: DeviceNet dropout issues

1stevek — Thu, 17 Feb 2005 13:10:31 GMT

I am not using explicit messaging at all (except in troubleshooting). Is this parameter (0x8000008F) valid for IO messages as well?

Re: DeviceNet dropout issues

biker2000 — Thu, 17 Feb 2005 13:37:14 GMT

Hi 1stevek,

no, it just affects the rate of explicit messages. If you run your encoders only with IO messages, it won't have an effect.

-B2k

Re: DeviceNet dropout issues

1stevek — Thu, 17 Feb 2005 13:40:24 GMT

Thanks, B2k! Are you running a DeviceNet bus with an 8461/D and having it run 24/7? Just wondering if you've had similar issues over time.

Re: DeviceNet dropout issues

frankwu — Tue, 22 Feb 2005 21:51:39 GMT

To 1stevek,

What happens when only 1 encoder on the networks?
Will the encoder drop out automatically?

The explicit message is needed for your applications:
(1) the IO communications need creating/deleting the IO connection by the explicit messages
(2) the master device tries to keep the explicit messaging when the IO communication is going on

You can try the explicit message timer tuning by
(1) set the driver attribute 0x8000008F to 10, or
(2) disable the driver attribute "Keep Explicit Messaging" (0x80000099) to 0 in order to disable the explicit message keeping

Re: DeviceNet dropout issues

1stevek — Mon, 28 Feb 2005 17:47:10 GMT

Thanks for the reply frankwu-

I have spoken with Danaher, and they said there are possible known issues with 4 or more devices at 500k if running both polled and strobed mode on one device. Is it possible the 8461 is setting up addition IO objects that I am not configuring? I only use one mode/object per device, and it is typically all polled or all strobed, depending which method I am trying.

Also, they said explicit messaging is not required. Is it required to turn off e.m. in the 8461 if you never open an object?

They also mentioned Allen-Bradley typically says to set the EPR to 75 (which seems high), and to set an inter-scan-delay of 10 or so. I am not aware of any i.s.d. parameters in the 8461. Are they both integrated into the EPR setting?

Thanks-
Steve

Re: DeviceNet dropout issues

frankwu — Thu, 17 Mar 2005 21:49:24 GMT

Hi Steve,

It is not required to turn off e.m but sometimes it may cause some problem on some devices.
I just want to isolate the problem.

I can set the mode to scan or individual instead of automatic and set the EPR value to 75.
But NI-DNET doesn't have inter-scan-delay, which may be the delay between different devices' scanning.

Good luck
frankwu

Re: DeviceNet dropout issues

1stevek — Fri, 18 Mar 2005 13:26:48 GMT

FYI-

The latest fix has been to reduce the baud rate to 250k, as Danaher/Dynapar has since informed me that they are aware of issues when running 4 or more devices at 500k when using both Poll and Strobe mode. I have not had dropouts since making this change, and the rate change does not appear to affect the functionality of the VI.

They have never tested the encoders with NI systems. They only use an Allen-Bradley DeviceNet card, which configures the bus with a very different, more detailed process (using EDS files). I am wondering if there is some discrepancy between the two systems' configuration operations, of which the NI card may not set the encoders properly. I informed Dynapar that the VI only opens one I/O object per encoder, and depending on which one I am trying (right now strobed is working - which I would prefer), they are all configured as either polled OR strobed, never both. Is it possible the 8461 is setting it to a common "polled AND strobed" even though I am selecting only one or the other?

I have also put each encoder into its own timed loop** and added a "wait for state" before the "read I/O" to reduce and/or eliminate errors and to allow each read to be a bit more independent.

Thank you all for all your help!
Steve

** The use of timed loops to set priorities seems to be causing issues with the RTOS, but that's for another discussion at some other time...

Re: DeviceNet dropout issues

frankwu — Thu, 18 Aug 2005 05:49:14 GMT

Hi Steve,

Congratulations.

For your question, I don't have a device supporting multiple I/O connections. But I write a VI. It creates 1 Poll and 1 Strobe with a device but only use Poll. You can try it on your device.

Regards,
Frank