Panelview 550 - Devicenet Vs. Dh485?

[jfwoodland 0]

Can anybody give me some input regarding their experiences with PV550s on a DeviceNet network with a Micrologix 1500/1769-SDN scanner (or similar)? I'm working on a multi-machine system with lots of digital I/O and three panelviews. The screens will mainly be used for machine fault display, single bit pushbutton operator inputs, multistate indicators, and some integer transfers for timer values, servo speeds and travels, and machine setup. I have been told by a colleague that the memory map can get very cryptic with this type of system and I might be better off considering a separate DH485 network for the PVs. I have lots of experience with DH485, and I agree that it might be easier for me in the short term. My AB rep, on the other hand, seems to be leaning toward recommending the DeviceNet option. My main concern is that I need to keep machine interconnections to a minimum, and would very much prefer to keep everything on one common network. I'm willing to deal with the learning curve that may be associated with using DeviceNet in this instance if the end result will be more desirable. so: Are the DeviceNet Panelviews a good choice for this system? What if I get hit by a truck? Will somebody else be able to figure out the "cryptic" communications? Are there any advantages to either choice other than "tag" nomenclature commonality (in DH485)? How do the DeviceNet Panelviews affect the speed/reliability of the network? Any other "gotchas" I should know about? Any input would be much appreciated.

[Chris Elston 78]

Based on what you have described, it seems to me it would complicate matters devicenet v.s. DH-485. With device net, this is what you will have: A Scanner card that you will have to "map" some I/O from the M files (m files...those "hidden" back plane bits) to some N or B files in your program that you can use. Then you can use the N or B files in your program to and from the panel view. You'll have to purchase Device Net Manager software (RS Networks) to even configure your panel views. With DH-485, you don't need any other software except Panel Builder, RS Logix, and RS Linx. Sounds like your AB guy is getting fat in the wallet. Doing DH-485 for a small network such as yours should be no problem, personally, if you have not spec'd the PLC's yet, I would lean toward SLC 5/04 and DH+ panel views, but there is nothing wrong with DH-485. Once you create a tag with panel builder, it's mapped DIRECT to the bit or integer in your program using DH-485, of course you have to have your node mappings correct in panel builder from panel view to SLC or Micro. So in general, your extra cost would be for device net: 1. Scanner card for each PLC system. 2. Extra cost for a device net panel view, cause they cost more money than DH_485 ones. 3. RS Network software to "map" your device net bits. 4. Device net programmer interface, unless you already have one...RS-232 to Device Net... 5. Extra code (your engineering time) in your logic to convert device net stuff to N or B files and make a spread sheet so you can keep track of all those bits too. Going with DH-485 you'll need 1. an AIC module for SLC or AIC+ for Micros Nothing else is required to communicate SLC/Micro to panel view. Just create a tag, type your bit or integer when you create your tag, select the correct "Target" node (since you have multi PLC's in the network)...done... Speed wise? Sure device net might be faster, but for what you are doing, I can't see that much screen lag caused by DH-485. That's why I recommended DH+ if you could, just for more speed. You won't need any AIC modules if you have DH+, but then again you can't use micrologix on DH+ either....

[jfwoodland 0]

Thanks for the in-depth reply, Chris. You have pretty much reinforced what I have heard from other people who have used the PVs on DeviceNet. I figured that since I would already be using DeviceNet for all my I/O and drives, and controlling the whole line with a central PLC, I would just add the touchscreens as nodes on the existing network (eliminating the need for two networks, allowing remote programming through my DeviceNet interface card, less cabling in between all these machines, etc.). Nothing is ever that easy I guess. Thanks for sparing me from some headaches and long evenings in the office.

[Chris Elston 78]

Wait a second...you didn't say you ALREADY had a devicenet network working in your first post. So you already have all the tools to configure devicenet then? I thought you would incure extra un-needed cost by using devicenet.

[jfwoodland 0]

Well, the system is still in development, but I will be using DeviceNet I/O. I have all the tools needed for configuring a system of this nature, and have worked with DeviceNet I/O in the past. My question was more specific to the functionality of the Panelview 550 as a DeviceNet node vs. a DH485 node. I figured you must have misunderstood what I was really getting at, but I think you presented some valuable information anyway. I'm not concerned as much with cost as I am with reliablility and ease of troubleshooting. Like I said, I'm willing to work a little harder in the design phase if the end result will be BETTER. I really don't want to drive myself crazy keeping track of all the mapping and getting the DeviceNet option working, just to find out that the end result is WORSE (less reliable, less functional, or more difficult for field technicians to troubleshoot). The cost factor is almost equal when I crunch the numbers for both options, and valid arguments can be made for either side. It really comes down to pure functionality and ease of use, I think. Having heard all this, do you still hold the same opinion?

[Ken Roach 194]

When I looked back and saw that you are going to use the MicroLogix 1500 and 1769-SDN, I had a thought that I'd best test out before I go recommending it. The 1761-NET-DNI is a little auxilary box that can encapsulate RS-232 DF1 Full Duplex packets into DeviceNet explicit messages. Putting Net-DNI modules onto the DF1 Full Duplex serial ports of MicroLogix and other DF1 Full Duplex devices can create a "Super DH-485" over DeviceNet in which multipoint communications can be established between DF1 devices, but using the higher bandwidth of more efficient network access method of DeviceNet. One unique thing about the 1764-LRP controller (the two-serial-port MicroLogix 1500) is that it can also perform that "DF1 <-> DeviceNet" encapsulation trick across it's backplane with the 1769-SDN. This begs the question.... can I hook up a DF1 PanelView to a 1761-NET-DNI and have it communicate directly to the data files inside the MicroLogix 1500, without using DeviceNet slave data mapping ? I dunno. It's also 4 PM Saturday and raining hard so I'm leaving the office. I'll let you know when I get a chance to test this !

[Ken Roach 194]

It's still raining, but I've got my shopping done for the might and this application intrigued me. I have on my desk a PanelView 550 Touch-Only (Series B with the Blue-Mode screen) with RS-232 DF1 communications connected via a MicroLogix-type programming cable and a null-modem adapter to a 1761-NET-DNI module, assigned Node 12 on the DeviceNet. The controller is a 1764-LRP MicroLogix 1500 with two serial ports, equipped with a 1769-SDN Series B DeviceNet scanner module assigned Node 0 on the DeviceNet. The DeviceNet scanner module is not yet scanning any I/O. The PanelView test application is written to read five ordinary integers on one page, using the conventional "N10:x" addresses. It's working correctly, passing DF1 packets through the Net-DNI and the 1769-SDN to the MicroLogix 1500. I was also able to simultaneously get online with the MicroLogix both via a 1770-KFD (slow) and a 1784-PCD (much faster) once I realized the "who active go online" wasn't going to work and put in the target node of zero by hand. Nifty ! The small PV application I am using now takes up about 5% of the DNet bandwidth right now, but I expect it might be slowed down a little. The one thing I couldn't do was download to the DF1 PanelView over DeviceNet; I know I could if I had another Net-DNI but for now I just unplugged and used the DF1 port.

[jfwoodland 0]

Thanks for the innovative idea, Ken. I have created similar "serial tunnels" over ethernet using the 1761-NET-ENI modules, but I was not aware that the LRP could send DF1 packets through the backplane to the SDN. Very nifty......and much easier to troubleshoot, I'm sure. I wonder if you can change the I/O parameters of the NET-DNI (I/O size, Poll Rate, COS-Polled-Strobed, etc.)? If so, I suppose the effect on the network could be minimized significantly. I'll have to do a little research.

[Ken Roach 194]

Actually, that bandwidth measurement was taken with no I/O connection to the Net-DNI, just with DF1 encapsulated traffic. I expect a reduction in traffic could be achieved by lowering the Scan Class of the tags on the PanelViews. Probably some evaluation should be done before endorsing this as a way to put three PanelViews onto DeviceNet. I have a PV550T and a PV300Micro with DF1 protocol, and two 1761-NET-DNI at the office, so I might be able to test more on this after the holiday rush (yes, there's a holiday rush in tech support). You could also add a 1761-NET-DNI to one of the serial ports of the MicroLogix 1500 controller, and not use the backplane DF1 tunnel. I really like DeviceNet PanelView terminals for their ability to listen in on I/O connections and send explicit messages directly to devices like drives. If you were to choose DeviceNet PanelViews, I would recommend configuring just a small amount of I/O memory as a COS connection for pushbuttons and indicators, and do the rest of the "analog" data elements as periodic Explicit Messages sent from ladder logic every 250 ms or so.

[Guest Thomas]

RANT ALERTI'm just an advanced maintenance sparky, but my experience with devicenet i/o has been very bitter. First the physical environment we installed the d/n stuff in was rather hostile. Heat, vibration, crazed forktruck drivers (you ever see someone bend the forks on accident?). For most folks having to configure a photosensor is absurd especially in a quick repair setting. A single fault on the backbone took out the whole machine for hours. All the savings of not having discrete wiring were eaten up in the first six months of operation. After one year we switched to discretely wired i/o and kept d/n for things in well protected locations. I realize this is not quite on topic but when I saw that the machine was still in development it set me off. Think long and hard before deploying this stuff in anything but a very soft, non-time-critical environment. Truamatized still....

[jfwoodland 0]

Thanks for the reply Thomas. Actually, I think that input from maintenance personnel is extremely valuable to us engineering people, since you guys are the ones dealing with the equipment on a daily basis. Sometimes it's difficult for us to anticipate problems like the ones you have described. As I type this note, my system is being moved to our testing facility for a runoff. I ended up using DNet panelviews after all, and they seem to work quite well. All of our manufacturing plants seem to be less hostile than yours (luckily), and I hope that I don't experience the same difficulties. On the other hand, one can never predict the competency of forktruck drivers. I did consider the easy replacement of sensors and other field components to be an important feature in a large system like this. For this reason, I chose to use standard device level components wired or cabled into DNet I/O interface blocks. For the most part, maintenance personnel should see no major differences at first glance. On the other hand (like you said), if the backbone goes down, the whole system becomes dysfunctional. Not good. Next month we will ship the system to one of our plants for a real-world test run before we build a bunch more of them. As always, that's when the real problems crop up. For my future reference, what happened to the backbone that caused your extended downtime?

[Guest i_canoe]

Just a short note on DN and panelviews. DeviceNet = 31 nodes, any interger will consume one node. 16 bits or one analog value equal one node. You will have to purchase multiple DeviceNet cards when you get passed 31. I know this is common knowledge, but I know displays start eating nodes quick.