DeviceNet Need ideas

LStewart

Member
Join Date
Apr 2005
Location
Mississippi
Posts
95
The following is the pass down from 3rd shift, I have never dealt with DeviceNet, but maybe by the night shift tech's description maybe you can give me an idea.
Oh, BTW, this line is in the process of have stations added to it, I don't know if they have hooked up yet or not or if that would have any bearing on it. I know that the new stations are not being used yet.
The DeviceNet continues to fault out. It is giving an error 91. This is a communication error. It will run for about 3-5 minutes between faults. Wayne and I checked all connections and voltage hookups but did not find a problem with them. AK told the setup this evening how to reset the fault so he is aware of the problem. The problem continued to get worse throughout the night. We called everyone, but none of them are familiar DeviceNet. The line is running, but the setup has to continually reset the DeviceNet.
Any pointers in the right direction will be appreciated.
This is connected to a SLC5/04 with only a DeviceNet module. The only thing this controller does is control pallet trafficking. The solenoids banks are connected by a Festo "Smart" module and they also fault out.
Lori
 
Last edited:
Error code 91hex is DeviceNet Bus Off condition. I have encountered this condition in the past in our application. For us the condition was occuring whenever we were simultaneously switching on multiple medium voltage contactors (400-575Vac) feeding our vfds.

I think it resulted in a lot of noise on the DeviceNet Can lines. I was able to resolve the issue by ensuring that the DeviceNet media was properly installed (ie. termination resistors and bonding to earth ground).

Here is a link to rockwell devicenet media installation guide, check out chapters 1 and 5, they may help.

http://literature.rockwellautomation.com/idc/groups/literature/documents/um/dnet-um072_-en-p.pdf
 
which devicenet module are you using also a generalized layout and configuration would probably help. I am assuming that the communications being sent are small status bits to and from each device? Has the program been in operation for a long period of time if so I would look for an intermittant short on your communication cables or a cold solder joint. We ran into similar problems on one of our devicenet networks and found that some of the terminal blocks were not seating properly in colder temperatures regardless of how tight they were. So I would try to isolate where the problem is originating by following the series and disconnecting all downstream devices assumming that your program does not require to see all devices. With an intermittant of 3 to 5 minutes this may help narrow down which device is the culprit.
 
Last edited:
Don't rule out the possibility of a bad module, either. I spent several weeks shielding, guarding, adding noise suppressors, only to find one of my wago nodes was taking a dump from time to time. Now, those are the first things I check.

True or not, I heard a funny comment the other day:

"When an electrician says your problem is noise, it's like when a doctor tells you your problem is heredity, diet and lifestyle - it means he doesn't know."

TM
 
I cheat, I went to http://www.odva.org training and support then looked in Dr Devicenet troubleshooting.
Q1) Troubleshooting. see also Physical Layer (PL)
and Hardware (HW)
I was recently doing a field analysis on a large DeviceNet installation where the customer described that the network
would intermittently fault. When an error occurred, the fault code displayed by scanner module was, (91) "Bus-off condition detected on comm port, module is detecting communication errors". To reset the fault, the PLC DeviceNet scanner card was cycled.
How is intermittently failing analyzed?


Answered by Ray Romito, DeviceNet Trainer,
e-mail: <
[email protected]>
arrow-over-right.jpg
A1) Let's start with definitions:

1. Transceiver - An 80C250, 80C251, UC5350, or other compatible bus driver/receiver. This is the last active component in the path from the CAN controller to the DeviceNet connector.

2. CAN controller - The device that is either part of the microprocessor or a peripheral to it, that handles incoming and outgoing CAN messages. It is responsible for all the error detection, message retransmission, and fault confinement I'm about to discuss.

3. Physical layer interface components - the opto couplers, transceiver chip, and any diodes or other protection devices tied directly to the network side of the transceiver.

4. Physical media components - cable, connectors, taps, terminating resistors.

There's a lot to explain to tell you how a node goes bus off. Check the Bosch CAN specification (download from ODVA web page) for the details.

In a nutshell, when a node sends a message, everyone listens to it. If someone finds a problem with it, they immediately flag it with an error frame. This serves two purposes:
1) It causes everyone to throw away the packet in question, and
2) It causes the sender to retransmit the message. The sender accumulates counts of bad transmissions (count = count + 8 with each occurrence). When it sees enough of them - 256 counts - it goes bus off. Good transmissions decrement the count by 1, so it will take at least 32 bad messages to go bus off, but maybe many more.


The kinds of errors detected:

1. CRC sequence error - Receiver calculated a CRC that was different from the one in the message.

2. Form error - Receiver found a spec-defined bit field at an invalid value for the given message.

3. Stuff bit error - Receiver detected 6 consecutive bits in the same state.

4. Bit state error - Transmitter detected that the value of the bit sent didn't agree with the resulting signal level on the wire (for example, I sent a 1 and heard a 0, or vice versa).

5. Acknowledge error - Nobody acknowledged the message.
This won't cause bus off though, so we'll forget this one.


CAN controllers all handle these events in the same manner (that's the part they license from Bosch). The indication to the host microprocessor varies from CAN controller to CAN controller. Generally, there's some type of status interrupt indicating one or more of the following:

1. CAN fault confinement state machine is about to
change from Error Active to Error Passive (75% there)


2. CAN fault confinement state machine is now Error Passive

3. CAN fault confinement state machine is about
to change from Error Passive to Bus Off (75% there)


4. CAN fault confinement state machine is now Bus Off

Some CAN controllers also generate a status interrupt, when an error is detected, and contain a register that holds the last error detected. If one were to build a diagnostic node using a CAN controller such as this, one could log these errors, but the offending frame is discarded before the interrupt, so one cannot examine it. That's why a CANAlyzer uses special ASICs. They allow you to capture these "disturbances" so you can see them.

We've seen bus off conditions caused by:

1.) Floating unused CAN controller input line (RX1 not tied to Vcc/2)

The symptom is that an installation with such a device may work for long periods of time before nodes start going bus off. Often (usually) the nodes going bus off are NOT the node with the problem. If looking with a logic analyzer or scope, the symptom will be error frames in-between messages that otherwise appear good. (Don't confuse with overload frames. Overload frames are sent in between messages too, but they are sent very soon after the end of frame. The error frames are sent long after the limits of when an overload frame is sent. Further, it seems that overload frames are not sent at baud rates <1M, so one should not see them on a DeviceNet network)

2) Anomalies in CAN controllers that momentarily
drive the CAN CTX0/CTX1 lines dominant


The symptom is, that for some relatively short period of time, a node will drive the bus dominant after a power up. Typically, the node that goes bus off is NOT the node that is disturbing the bus.

3) Inappropriately designed interfaces between CTX0/CTX1 and the CAN H & CAN L lines that allow the lines to float to dominant during reset.

The symptom is that for some period of time longer than #2, perhaps as long as 10 - 20 ms, a node will drive the bus dominant after a power up. Typically, the node that goes bus off is NOT the node that is disturbing the bus.

We've also seen bus off conditions caused by media problems such as:

1) Shorts in the cable system (either CAN H to
CAN L or CAN signal to ground, etc)


The symptoms are that it either doesn't do anything at powerup, except go bus off, or it will run for varying periods of time and fault for no apparent reason. There may be any number of devices going bus off. As with almost all cases, the node that is doing the most talking (the scanner) is the most likely one to go bus off.

2) Intermittent connections in taps or molded cables that cause all kinds of funny things

Usually this requires shaking, pulling, wiggling, or some other such forces exerted on the wiring, connectors, etc. Machine vibrations can cause this too. There may be any number of devices going bus off with this one as well.

We've seen transceivers blow their little lids and stop working completely, but that didn't cause a bus off. We've also seen them lose the CAN H or the CAN L output such that the signal is no longer bipolar. This latter case may, over time, and in a noisy environment, cause bus off, but we haven't really observed that either.

Check to make sure that the CAN controller registers are set up properly. If not, bit-timing problems could arise that may be aggravated by distance between nodes. Look at Vol 1, Chapter 2-7.5 and make sure that the register setups in your CAN controller agree with what's in the Spec. Particularly that you synch on one edge, one sample per bit, and the settings of the TSEG1 and 2. The output control polarity will depend on the inversions present between the CTX0/1 and the CAN H/L lines in your particular design.
 
More on the subject:
My DeviceNet system will shut down and have to be rebooted to get it back up and running. I think I saw error code of "91" but I am not sure. Since this happens infrequently, it is hard to get a handle on this. Is there a DeviceNet Diagnostic Package that I can hook up to the system to try and capture this problem. Also, are there any obvious things that we should be looking for that might cause this kind of problem. There are Servo Drive Cables near the DeviceNet Cables, but you would think that this would be a problem more often than not.

Answered by Ray Romito, DeviceNet Trainer,
e-mail: <
[email protected]>
A2) Well, this is not an easy one to track down. Error 91 is a bus off error code that means that someone has sent enough error indications to the scanner's transmissions that it decided to bail out. The infrequency of the situation makes this particularly difficult to troubleshoot.

Try to correlate the error with some event or state of the machine. Is something being turned on or off (like maybe one or more of the DeviceNet nodes) when the fault occurs? I found a system once where a vibration cause by the closing of gates on a palletizer set up just enough vibration that once every 500 or so closures a loose connection in the control cabinet would vibrate long enough to cause a bus off. Look for machine movement and see what affect it might have on the media in the area. Look the system over, checking for loose connections. Wiggle T's, check DC voltages, proper termination cable lengths and budgets within Specifications, approved media, etc.

A CANalyzer is a CAN level monitor that will detect the presence of error frames and other disturbances that would cause error frames and log their occurrence, including length, and timestamps the event relative to the other traffic. This tool is expensive and won't tell you who is doing it, but will tell if someone is. But before going to this extreme, work on trying to get the problem to happen more frequently. That effort may just lead you right to the problem without need for special equipment.
 
If you are adding nodes to the devicenet like AB 1799 cards, make sure your terminating resistors are in the right place.

 
Almost every "Bus off" condition I have ever encountered has been caused by some type of cable/installation fault. The most common are:-
1) Actual wiring faults.
2) Failure to link the 0v and screens to earth. This is common and is very important.
3) Bad plug and socket connectors. The "Mini" type are particularly notorious for creating problems which defy reason.
I would try disconnecting everything except the scanner and the terminating resistors and then add back nodes one at a time until the system begins to have problems. On a big system you could try shortening the network and then adding small segments back until you find the problem area.
 
Well thank you all for your input. Our machine is running right now. When our group went out to the line the DeviceNet module was faulting out about every 2 minutes or less. We checked cables for signals and power. We alternately disconnected and reconnected each (I don't know the term) thingy(smart module?) that plugs into another thingy(cable T?) that talks to the module! Nothing jumped out and "said here I am" We found some cables that had been pulled very tight, found some connectors that were very loose. It quit faulting out and has been running about 45 minutes now. We know this is going bite us about 2 am sometime, because there was nothing we could pinpoint as an assignable cause. This line has been here for about 5 years, none of us has ever had any dealings with DeviceNet, we have never had a problem before. Looks like that is about to change. When I do find the cause I will post it. Thank you very much for all of your answers, BTW Ron, I tried to register on your site last night and never recieved the activation email. What do I need to do?
 

Similar Topics

Good Morning , I'm finally getting through to upper management about the need to start eliminating our SLC 500 PLC's and Devicenet . I...
Replies
8
Views
2,041
Hi all, First time I work with Devicenet and i've got the network up and running but I do not fully understand how the configuration works for...
Replies
0
Views
2,202
A couple months ago we had a little siemens I/O module go out and in the process of replacing it with one with a different rev level it ended up...
Replies
16
Views
5,537
Hi Everybody, I need your advice regarding pros and cons of using DeviceNet. We have an application with 17 VFDs and 33 fixed speed devices and...
Replies
1
Views
5,099
Good day Forum Members I got a older Lincoln welder and hoping to make it work at our shop. Welder in question is the Lincoln Power Wave 455M...
Replies
4
Views
144
Back
Top Bottom