Devicenet fault 91

regentb

Member
Join Date
May 2008
Location
Cambridge
Posts
4
I have a 1769SDN where every morning I have a 91 error on it. The machine run fine all day long with out any faults. It's only over night that I get the error 91. For the last week now every morning except for one I had a 91 error on the scanner. I cycle the 24VDC and it resets.

Has anyone else had this issue?
 
I've seen this error many times! Error 91 pretty much means you have a wiring or earthing/noise problem.

I've had this error due to electrical noise from a VSD drive starting up i.e. anytime the drive started up the whole network was taken out. On one occasion the DeviceNet network wasn't earthed correctly and on another separate occasion the Motor itself wasn't earthed properly.

I've also had this issue that was was eventually traced down to a single stray strand of wire occasionally causing a short between the DeviceNet network data lines (blue and white wires). Very frustrating!

My first port of call would be check the earthing and termination resistors:
- DeviceNet power supply -ve must be connected to an earth point.
- DeviceNet shield/drain wire must be earthed at one point only. Normally at the DeviceNet power supply.
- Network is correctly terminated at both ends with a 121ohm resistor. Resistance at any point on the network (between blue and white wires) should be about 60ohms when the scanner is disconnected from the network.

The above info is taken from my own personal notes but should match the DeviceNet wiring spec which is easily found with a quick google search.
 
Thanks for the reply. The only thing that has me puzzled is it only happens at night when the machine is not running. I'm in an E-stop with all my drives powered down. i wired an input from my DeviceNet 24VDC power supply and set a latch to see if I was losing power over night and thats not the case.

I will check all wiring again and the resistors. I'll let you know how it goes.

Again thanks for your reply.
 
Are the drives the only devices other than the Scanner on the network ? What type of drives are they ?

I'd be curious to see if the Bus-Off occurs immediately after the system is e-stopped, or if it happens sometime during the night. You should be able to write a simple logic trap using the fault bits or status words for your Scanner to find out.

It's not normal behavior; DeviceNet Scanners should be able to transmit into a terminated but un-populated network.t.
 
Almost all of our Buss Off conditions are due to the connections in the cable building up resistance (mostly in Control Boss, rarely in DeviceNet Thick).

The way that I check for this is to disconnect the power to the network and remove one terminating resistor. I then put an ohmmeter on my CAN-HI and CAN-LOW wires and see what the resistance is.

A "Good" network will read around 124 ohms for a short-ish network, while a longer one will read around 128 ohms. If you see around 140 ohms (on a Fluke meter anyway), and the resistance keeps going up rather than down, you probably don't have all of the power off on the network.

Go through the entire network and open and close each connection (and clean with contact cleaner if you so desire). When you get to a Hi-Z one you will see it (when the resistance goes away). Hi-Z being in the order of anywhere between 1 ohms on up (but usually 4 ohms on up will cause a problem).

An additional problem that appears to be Control Boss specific is what I call the "Wandering resistance" problem. After removing the power and one of the terminating resistors and then connecting the meter, you will see it inch up in resistance from the 120's, to the 130's, to the 140's, on up.

This is due to a bad Tee and you will see the network resistance jump up when you tap on the bad tee (in the case of our ovens, when you walk nearby). This seems to be a heat-related issue, and replacing the tees is your only recourse.

This is our "temporary" fix (temporary being anywhere from 6 weeks to better than a year) and fixes 95% of our Buss Off problems (the other 5% being a mix of power supplies and the tees).

In one instance the problem was installation related. The DeviceNet thick was terminated using field connectors and the contractors who did the job did very poorly. We have had a few power supply issues as well.

I don't even bother hooking up a scope anymore since I know that "cycling the Tees" (as we refer to it here) is usually going to do the trick.

Good luck!
 
I know I had this error last year, and a few others...
I know one problem we had, was that a second Power-supply got specified for a new JB, and it got wired on to the DeviceNet power in error. I can't remember if it was this error you are reporting, but once we removed the second power supply, everything was fine.
 
I went through and re terminated all the devicenet wiring and checked all my resistors and so far I have not seen the issue come back. So it must have been a wiring issue.

Thanks for all the replies.
 
I went through and re terminated all the devicenet wiring and checked all my resistors and so far I have not seen the issue come back. So it must have been a wiring issue.

Thanks for all the replies.

Good to hear it!
 

Similar Topics

Hi there, I have a Beckhoff PLC rack with the BK5220 bus coupler, communicating over DeviceNet with Allen Bradley scanner card. I am receiving a...
Replies
0
Views
437
Good morning, I would like to know what triggers the Local:3:I.StatusRegister.Fault bit. (on 1756-DNB) Client has deconnected a devicenet...
Replies
4
Views
2,030
Random DeviceNet "Port 5 Adaptor " Fault on various PowerFlex 70 Drives in Panel Good Evening , We have a machine with about 17 -...
Replies
12
Views
14,492
Hey Guys, I am in the middle of commissioning a safety installation and I am having some rudimentary problems with the safety IO modules and...
Replies
4
Views
2,809
We have a Festo pneumatic valve bank on a Devicenet network on a Thimmonier pouch filler. The bank controls, among other things, two valves that...
Replies
0
Views
1,383
Back
Top Bottom