DeviceNet Problem

Heres a teaser, maybe. I am just relocating to a new plant that has many new installs using AB DeviceNet. Today we had a conveyor, controlled by a AB 160 series VFD, just stop running, dont have the model of the DeviceNet interface, but I'm certain its probably the only one for this drive. After looking at this online, the enable bit was not present, which is supplied by the drive via the DeviceNet communications. Not being up to speed on DeviceNet myself, our electricain quickly diagnosed the issue as one that has occured before, that being that the message length instruction in the DeviceNet program in the interface, had apparently changed to a value that was to short to contain all the bits used in the message to the PLC. After changing the message length to what we believe are the max. values, life was good. My questions is has anyone experienced this issue. Again this is the second time this has occured according to our electrician, the last time the speed reference was effected, causing a conveyor to run at extremely high speed, a somewhat dangerous situation. One thing I did notice on the particular drive today was it was at the end of the DevideNet chain & had the terminating resistor on the cable, I will check with him tomorrow to see if that was the case on the last one that did the same thing, I was thinking perhaps the wrong resistor was used, but thats just speculation. Tomorrow I will also look into more detail the exact part of the program he changed, but I'm certain it was an output message length. Just curious if anyone has experienced anything like this. Thanks in advance for any responses.

Hi Dave,

I've seen some unusual things with the 160 drive on DeviceNet, but not what you're describing.

The 160 does have two interfaces, the 160-DN1 and the 160-DN2. It would be beneficial to know about what the scanner device is, too.

What I think you're describing is an I/O Size Mismatch. On A-B scanners, this always causes an Error Code 77 to be displayed on the scanner (alternating with the offending node number).

Different I/O "Assemblies" are the bane of the 160 drive (and indeed, most drives on DeviceNet). They're powerful and flexible, but because of their flexibility they're a ***** to figure out if somebody didn't document how they set it up and you only get to check it out after it's broken.

For example, if you were running the 160 so that one 16-bit Word of output data commanded it's start/stop/job functions and the next 16-bit Word of data commanded the speed reference. If somebody "fixed" the DeviceNet configuration by re-mapping the SLC and they got the map offset by one word.... your discrete I/O Word might be accepted by the drive word-wise as a reference.

I've had complaints before about DeviceNet products "mysteriously" changing configuration "all by themselves". Bull.

It's always been inadvertent application of two things:

1. Auto-Device Replacement. You can set up some A-B scanners to automatically load parameters into a device when the device powers up and joins the network. I've seen folks carefully tune a device... AFTER they set up ADR. Next time the device power cycles (days or weeks later) the old parameters go right in.

2. The Default Parameter Setting in RSNetworx. This got guys in a big 1336+II drive startup all the time. They'd go into RSNetworx parameter editor and hit the "set to EDS defaults" instead of the "parameter help" button. When nothing visible happened, they'd shrug, get the correct help window, make their intended changes, and save the changes to the device (not realizing they'd set all the parameters, such as Node Address, to the default). Whoops.... some of those changes don't take effect until power is cycled. Again, weeks later. The net effect is "gremlins !".


See if you can get somebody to recall if a number was flashing on the DeviceNet scanner and you'll be one step closer to solving this mystery. Upload the I/O Assembly configuration and the scanlist and you'll be even closer.

Ken, First thanks for your initial input. One thing I can add at this point, the scanner had no faults displayed, only 00, saw that myself. One of the guys working on this tried cycling the power to no avail, that seems to be the answer to alot of problems around here. I will get the exact model numbers of the devices used tomorrow & more details of how it was resolved. Also for you, if memory serves me, you are an AB tech, we had a tech at AB tell us that the 160 drive will default to enabled when powered up regardless of the jumper selection, I dont buy that. My experience is you must have 7 & 8 connected either by jumper or through a relay, any input from you on that, he was referring to when they are on DeviceNet. Also, I aggree that this is an application issue, I dont believe in gremlins. Thanks again for your post & I'll be more specific tomorrow.

Ken, & anyone else who can offer input to this situation, here is an update. The interface is a DN2, according to my electricain, this must be used on Rev.C drives & higher, which these drives are. The scanner is 1747-SDN. The parameters that changed are #107, Output Assembly, which changed from a value of 103 to 20 & #108, Input Assembly, which changed from 104 to 70. I am assuming that perhaps the values of 20 & 70 are factory defaults & somehow the drive is reverting back, but thats just a guess. One other note, there was nothing going on such as cycling power or anything like that when the problem occurs, VFD simply quit running & after going online the parameters have changed. Change them back & all is well. Again, any input is appreciated.

OK, I understand why you didn't get an error code.

The default values for Input and Output assemblies are in fact Assembly 20 and Assembly 70.

Both of these are 8 bytes in length. The assemblies you're operating with, Assembly 103 and 104, are also 8 bytes in length. Therefore if the assemblies got changed, the 1747-SDN would not declare a size mismatch fault.

It also explains why your speed reference went haywire. You're using "Allen-Bradley Compatibility Assemblies" that make the 160 work in a similar way as the 1336 drive family. Older "SCANport" based drives use a speed reference where the value 0-32767 scales to Min Hz-Max Hz.

When the drive is set for the default Input Assembly 20 the frequency reference is in unscaled RPM. A value of 16380 would be 30 Hz (nominally) in the scaled reference mode, but 16380 RPM in the RPM reference mode.

What it doesn't explain is why those parameters changed. Both of the things I mentioned in a previous post can do that.... I wonder if there's something else like a power spike that can default the drive too.

Update

Ken, or anyone else that might have some input, heres the latest. The OEM has advised that AB support has instructed us to install "snubbers", dont have any part number, on brake contactors for all motors that have brakes. Almost makes sense being this is almost sure to be some sort of line noise issue. They are going to supply us with enough to cover all effected motors. Still makes me wonder why only 2 parameters changed, the tech will still be in tomorrow, I think I'll ask him how many parameters he programmed different than default, if its only those 2, then that makes sense, but I'm certain he did more than just those 2. Also, Ken, you never answered the question I posed earlier in the thread regarding the auto enable on powerup of the 160 drive, goes against all my experience, not a major thing for me, just curious. Thanks

If you're working on the premise that line noise or spikes are causing the 160 drives to totally reload from EEPROM (hey, it happens to SLCs in lightning storms all the time), it does make good sense to put RC-type snubbers on the brake coils.

That won't eliminate noise coming from the drive output, but it'll get rid of the big spikes if they're present. Changing the carrier frequency (parameter 49) from 4 KHz to 2 KHz decreases RF noise but tends to increase audible noise somewhat.

You're also following the right path in questioning whether or not just those two parameters changed. Get the tech to upload the parameter set and compare it against a dummy 160 in RSNetworx after you press the Default EDS Parameter Values button in RSNetworx.

Oh, one more way to accidentally put the default parameters into a drive: Connect to the network with a PC that doesn't have the offline DeviceNet file in it. Browse the network, then when you bring up the Parameters pane to edit the drive, select "Download Parameters". This will make the default parameters load into the drive; after all, unless you upload them, the offline file just knows the parameter values it gets from the EDS.

There's a slightly messy way to monitor a memory probe location in the 160 to see how long it's been since it had it's EEPROM totally reset. E-mail me at [email protected] if you're interested in delving into that.

I'm not a technician, but I play one on the Internet

In answer to your other question about Enabling, I've always had to jumper between terminals 7 and 8 when I used a 160 that was run exclusively over DeviceNet. As far as I know, a high signal Terminal 8 is an absolute requirement for the 160 drive to run.

I'm actually a Sales Division technical specialist; I don't work in Support except when Support punts. Your tech was maybe talking about Bit 5 in Ouput Assembly 21 ("Control From Net") which toggles start/stop control from local to network. Wasn't there, couldn't say.

There's an A-B Drives specific forum hidden away under AB.COM if youre interested:

http://www.ab.com/support/abdrives/registered.html

Thanks for the response Ken. You obviously sleep at Holiday Inn Express. I'll tell you, from the responses I've seen you post, you are more knowledgable than most AB tech's I've spoken to in the past, but not all, the problem with them is, always getting in touch with the ones that really know the stuff. Thanks again for the info.