DeviceNet dropout issues

[1stevek]

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

[TongY]

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.

[1stevek]

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?

[TongY]

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=

[biker2000]

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

[1stevek]

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

[biker2000]

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

[1stevek]

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.

[frankwu]

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

[1stevek]

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