DeviceNet woes

[bboytaktix 0]

Let me just begin by saying I am not the biggest fan of devicenet. I am fairly new to the field of Automation engineering, I have been working full time for about a year and a half alongside of some very good senior programmers/engineers and I am not the only one to have trouble configuring the devicenet system! We use RSLogix5000 for programming. My issue is that, I have a 1794-ADN DeviceNet flex I/O adapter with 7 cards in it (4 inputs, 3 output cards) and today we wanted to add another card (an 8th card, in slot 7). The electrician powered down the devicenet adapter, added the card as slot 7, rebooted everything and I was able to see the added 1794-OW8/A output card in slot 7 when I went to the devicenet adapter's 'parameters'. Problem is, the outputs are not getting to the card. When I toggle the bits associated to this output card, the output lights on the actual card aren't even turning on. More info: In the slot 7 1794-ADN devicenet adapter properties, when I upload and go to 'Module Configurations', I see that the 8th card is there and is the 1794-Ow8/A, but when I go to I/O summary, under outputs, that card is not listed. If I go back to module configuration and click properties for that output card, and go to flex configuration settings, the 'output words' are 00, unlike the other output cards that have 'output words' as 01-IO only. I try to change the 00 to 01-IO only and then download to the devicenet adapter with no luck (the added output card retains its precious settings when I upload again) Am I missing anything? Thanks in advance for any insight on this issue

[Ken Roach 194]

The 1794-ADN isn't the easiest DeviceNet I/O platform to use; it's a fifteen-year-old design, there are a couple of bugs, and because it's modular it's also a little complicated. Adding another FLEX module will require you to change the configuration of the 1794-ADN as well as change the size of the I/O connection in the DeviceNet scanner. Generally you also have to re-map the I/O connection in the Scanner's memory, so take careful notes about exactly how it is mapped into memory. The 1794-ADN poses a little bit of a special challenge because it will not accept a change to the configuration while the I/O connection is still active. You probably saw a "object state conflict" error message when you attempted to change the output size for the adapter. My general steps would be: 0. Put the controller into Idle or Program mode, depending on the model of controller. 1. De-activate the 1794-ADN in the Scanlist by de-selecting the Active checkbox for its Scanlist entry. You do not have to un-map it, but take careful notes about the size of the I/O connection and exactly how it is mapped to memory. 2. Cycle power to both the scanner and the 1794-ADN. This fully resets the I/O connection, rather than leaving it in a timed-out or idle state. This is the step I see people omit the most often. 3. Change the configuration of the 1794-ADN to accommodate the new Output module. This should add 1 or 2 bytes to the Output size of the Connection. 4. Change the I/O connection size in the Scanlist and re-map the output connection. 5. Check the 'Active' box in the scanlist configuration. 6. Make sure the 1794-ADN isnt' set up for Auto-Device Replacement. If it is, update the ADR configuration for that adapter. 7. Save the changes to the scanner, and put the controller back into RUN mode. Edited 29 Jul 2013 by Ken Roach

[bboytaktix 0]

thank you for your help! I already tried putting the Devicenet card (I assume this is what you mean by controller) into Idle but did not try also de-selecting the 1794-ADN from the scanlist. I will give these steps a try and get back to you to let you know if it works.

[bboytaktix 0]

One question: by auto-device replacement, are you referring to the 'Automap on Add' function when you are activating a card into the scanlist?

[Ken Roach 194]

Auto-Device Replacement is a different function; it saves configuration parameter information for slave devices in the DeviceNet Scanner memory itself. Only newer (well, in the past 7 or 8 years) DeviceNet scanners have that feature. When the scanner connects to a slave device that has ADR configured, it checks to see if the parameters in the device are the same as the parameters stored in ADR memory. If they are not, it re-configures the device. This is handy when you have things like motor overloads or limit switches which need to be replaced in a hurry. But it can also be a drawback, like having an EEPROM in the PLC that you didn't know about, because it can over-write changes that users make to device parameters using RSNetworx. I usually do not see it used with the 1794-ADN. Auto-Map On Add is just a convenience feature in the DeviceNet Scanner configuration, that will automatically add devices to the I/O memory map when they are added to the scanlist. I generally don't see it used with the 1794-ADN, because that device usually has a complicated I/O map because of its modular and configurable nature.

[bboytaktix 0]

Hi Ken, I followed your directions and it made a difference, the new output card settings seemed to stick when I added the devicenet adaptor back to the scanlist; the card was listed in the 'I/O summary' tab under 'outputs' as it should be. At first it was not working, I toggled the output bits and none of the output lights at the card turned on, none of our contactors flipped on. We then tried switching the card with an identical one thinking it was a card issue, still no luck. Finally, the electrician suggested also switching the backplane since we had seen backplanes being a problem before. We did this, and everything worked. thanks again for your help Ken, this DeviceNet can be a real pain, but I'm real glad there was someone to troubleshoot me through!!

[bboytaktix 0]

Here is another question for you. Do I follow similar steps as you suggested for an SVX9000? We replaced an older model drive with this newer model and it doesn't seem to be communicating properly. It is showing that specific node to have an E77 error (device size mismatch)

[Ken Roach 194]

I would use a similar set of steps, including the power cycle. Error #77 almost always comes from selecting the incorrect Assembly number in the SVX9000, and my recollection is that the drive didn't gracefully support simultaneous messaging and I/O connections. Disabling the I/O connection and cycling power to the drive gives you the best chance to get online through the drive's DeviceNet connection and make the necessary parameter settings to select the proper sized Assemblies.

[bboytaktix 0]

great, thanks for the information. I was observing this DeviceNet configuration and it seems like the old drive was only mapped for 4 input/4 output bytes, and the current one is an SVX-9000. I looked at the other SVX9000 drives we have configured on this DeviceNet cards and they are all 8 input/8 output bytes, and so I believe this is where the problem lies.