Ken Roach

Man, did I take too long writing that or what?  You leapfrogged me twice.  :D As a rule, yes, PLC's and PanelViews will work across subnets that have a Gateway between them.  When you set up the automation device you tell it the IP address of the Gateway. I have had a user suggest that the 1761-NET-ENI has trouble sending e-mail to a non-local mail server, but I haven't verified that.   As far as I know it's regular EtherNet/IP traffic works fine across a Gateway.

What you've described, LT, is two logical subnets running on two linked physical subnets (two Switches, right, connected through their Uplink ports ?) For example (I'm guessing about the IP addresses you have) Network 1             Network 2 199.46.191.246      192.168.0.10 199.46.191.245      192.168.0.11 199.46.191.244      192.168.0.12 These are both called "Class C" IP networks, in which the first three octets identify the network, and the last octet describes the node itself.   Your IP networks, "199.46.191" and "192.168.0" are logically totally separate.  Although the switches are linked together, your PC is a member of Network A and simply cannot communicate to a node on Network B directly. In order to communicate between two networks, you need a Router or a Gateway. Here in my office, and I suspect also in yours, you have a server computer (An HP NetVista running Novell Netware) and some Ethernet hubs locked away in a closet with the Internet connection, the phone wiring, the on-hold music player (remind me to take out that Back in Black CD), all guarded by a mean IT person and a cheesy lock.   Also in that closet is the magical "Default Gateway", in my case a function of the Netware server computer. This Gateway lets my traffic from the local office (10.82.91.101 is me, .104 is my neighbor) get to other offices of the Company, as well as to the Internet through a proxy.   Therefore, my PC's TCP/IP setup is configured for that Gateway computer's IP address (in our case 10.82.91.1) to be my "default gateway". When I ping my neighbor (hi, Tim) the packet goes right to his PC and is recognized there because we're on the same subnet.   When I ping "18.187.0.208 ", which is not on my network, my computer knows that it needs to send that as a routed request to my Default Gateway machine, which will route it through the proxy and out to it's destination. But between your two networks is not a Gateway or Router, rather just an uplink port from Switch to Switch. So, how to get this working ?   The simplest thing to do is to assign addresses to your computer, the Net-ENI, and the PanelView which are in the 192.168.0.xxx subnet. The next simplest thing is what our friend kkarr suggests, installing an extra Ethernet adapter in your computer to talk to the other network. The more permanent thing is to install a Gateway or Router on this network.    For example, I brought my Linksys BEFSR41 (consumer-grade router for cablemodem use) to the office and set it up in my cubicle.   My computer, and all my harem of SLC, PLC, Logix (grunt, puff, grunt) controllers are 192.168.1.101, 102, 103, 104.... but all my system administrator sees is my Router, pretending to be 10.82.91.101, little old unobtrusive, non-bandwidth-thrashing personal computer.   Pretty handy that when I do Ethernet performance tests her intrusion monitors don't go wild, too. One thing that complicates stuff somewhat is that one of your subnets has chosen non-routeable addresses.   Addresses in the 192.168.x.x network range are not supposed to be able to communicate outside their subnet.   My little Linksys router manages it through a trick called Network Address Translation (NAT) but it might not be workable for you. As a practical matter, what I do when moving between Ethernet subnets is just change my computer's IP address when I move between those subnets.   In Win95 I have to reboot, in Windows NT I really, really have to reboot, but in Windows 2000 it's mostly painless.    If I had to move around a whole lot, I'd buy a USB/Ethernet interface and let it do that dirty work for me.

Change-Of-State can really open up your DeviceNet bandwidth, though on a 5-node system the variation might not be that noticeable.   I typically use it on 30 or 40 node MCCs. The #1 "gotcha" in a COS setup is the trigger mechanism used by the slave device, especially with analog values.   For example, you could have an analog value (like the frequency feedback from an AC drive, for example) that changes just by one or two of the least significant bits in a word, but does so often. If the COS trigger is "any change at all", such a node can fill up the network with a message every time the feedback changes by 1 part in 32767. Most well-designed devices give you one of three ways around this: 1.   Time filters.   The COS message production gets delayed by X milliseconds every time there is a change, to keep the node from filling up the network with messages.  This is also handy on discrete I/O where two inputs might come on very close to each other in time. 2.  Value filters on specific elements of the data.   This helps filter out the small changes in analog values.   A-B drives use this, for example, allowing you a "COS Fdbk Change" parameter so you can dampen the effect of the feedback changing by small amounts, as well as a "COS Status Mask" to change what discrete bits of the drive Status word cause a COS production. 3.   Non-IO triggers.   Some devices use events that aren't necessarily in the I/O data to trigger a COS data production.  Allen-Bradley E3 overload relays are like that;  you select Inputs, Outputs, or Warning, Trip, or Current Feedback bits to trigger a COS data production.  Usually these things are part of the I/O image, but not necessarily. Your application is entirely discrete I/O, so COS connections will probably give you what you expect;  a message produced by the valve manifold only when an input point changes state, and a message produced by the Scanner module only when an output bit changes state.   Unless you're running a pulse train into your inputs, this should result in better overall network throughput. One more thing;  it takes a scanner module longer to declare a node offline when you're using COS or Cyclic messaging.   The timeout is in fact 4x the heartbeat time.  By default, the COS heartbeat is 250 milliseconds, so if a slave device goes off the bus, it will be a full second before the scanner module knows about it.   Not a big deal in some instances, but important in others.

None of 'em.   The MicroLogix 1500, 1200, and 1000 all run the same execution engine as the SLC-5/02 and do not support online editing. The smallest online-editable controller today is the 1769-L20 CompactLogix.  I'd hoped that Rockwell would build a packaged controller with the Logix engine, but there's just too much horsepower in the Logix core to make it cost-effective in hardware like the MicroLogix 1000 has. I re-read my posting below;  I can see how it could be misleading.  By "ones" I meant PLC's in general, not members of the MicroLogix family.   All the fixed SLC-500's, 5/01 and 5/02 and MicroLogix use Intel 8051 variations, and the SLC-5/03 and higher use Motorola 68000 family microprocessors.

Creeeeeak... where's the hood prop, okay.   Hand me that light, Rufus... there.   (squeek, squeek).  Wow, that sucker just hums along, sounds like 12.5 MHz.  Would want to get my sleeve caught in it, though, here, hand me that screwdriver, no, the old yellow one, thanks. Lesse... this here's a PLC-5/20, so it's just got the one 68020 Motorola.  I always liked those, I had a PLC-5/40E when I was a teenager with three of 'em, plus the ASIC chips in the DH/RIO plug daughtercards. Oh, yeah, A-B's always used Motorola.  Those little MicroLogix the kids race today have Intel 8051 variants in 'em, like the 80C320 all kicked up to 22 MHz, but all the online-editable ones like to use the priority interrupt system used in the 68000 family Motorola processors. The new ControlLogix is all newfangled inside, ASIC cores with fancy names like Argus and Arcanum.   Can't even work on 'em without a computer, gotta take 'em to the dealer way down in the City. Nope, me, I'll take my heavy iron any day, even if the parts are gettin' expensive.  Maybe someday I'll buy another, if it comes up on the E-Bay.

Ain't cheap.   Here they sell for $995. The other handheld meter I've found for DeviceNet, the DeviceNet Detective, sells for $1695. A-B sells their ControlNet signal meter for $450, but it only gives you LED readouts. A similar LED-only DeviceNet meter is available from Dearborn Group for about $300. That's why I wouldn't expect somebody with a small DeviceNet network to need or want one.   I think that big factories full of DNet, or factory guys (hint, hint) from DeviceNet manufacturers ought to have one.

I use a program called ComLite32 to monitor the goings on of a serial port without trying to wire a splitter between the two devices. It was discontinued as a product but can still be found for free on the web; ftp://ftp.rtcomm.com/ pub/comlite32/cliteb5.exe

The way I understand it is for applications opposite of yours;  in which all the items in a group need to be moved around together so they don't lose their spatial relationship.   That's not as big a deal when you're snapping to a grid, but if you spent a long time painstakingly manouvering graphics and text together, you'll want to group them so you can position the whole agglomeration together. I know one reason I use Grouping is when I have several text or background objects I want to keep in the background together;  instead of trying to click each one in the right order to get them stacked in layers (kinda like Autocad, without the transparency) I make them a Group.  Every time I use the "send to background" button, PanelBuilder sequences through the items putting them in front of one another until I get the sequence I wanted. It's also easier to make grouped items Global so they retain their positions as you reproduce them between screens. That's my 2 cents, anyhow.   I've been using PanelBuilder for a long time now and I still don't know everything about it.

I came across an application and workaround today that merits mention here. A customer was using a PanelView 600 Touch-only terminal to control an industrial laundry machine (forget your Maytags;  this sucker has conveyors and and a 1.5" gas line).   His application was only 19 screens, yet he was running out of memory and was considering the much-more-expensive 6182 computers to meet his EOI needs. When I got my hands on his application, it became clear what he'd done;  there were five similar screens of one type (alarms) and five of another type (maintenance notices) which were full of text on a beveled 3-D rectangle background.   When I tried to edit the text, I couldn't.... the whole thing was a bitmap ! Well, ten full-screen bitmaps at 320x150 pixels x 16 colors.... they occupied about 32K each as Paint files.  HUGE memory hogs in the PanelView, which has only 240K for text and graphics. He just hadn't been satisfied with the PanelView text editing and positioning (please, no debate over those) and had decided to use a tool he knew he could trust;  MS Paint.

Netmeter scores again ! One of my field service guys calls up working on a DeviceNet installation for which he's a little overwhelmed;  it uses a PLC, I/O, and cable.... none of which are made by our Company.   But we're the "DeviceNet Experts" so we got called out to fix the problem. After doing all he could checking voltages, using a scope, and fiddling with configuration tools he was unfamiliar with, he gave me a call. As mentioned before, our distributor just bought three of these as demos.  So this fellow rented the NetMeter from the distributor and applied it to this network. Surprisingly, he didn't find anything wrong.   Voltage drop, CAN errors, traffic... all clean. That is, I think, what the Netmeter is best at;  telling you that the system isn't physically malfunctioning so you don't spend you time with a scope and wire strippers when you need to be looking at traffic analysis and firmware.    Vice versa, it can help you stop wasting your time banging on software and PLCs when your problem is a loose wire or noisy power supply. I eventually identified the anomalous traffic coming from the master PLC and confusing the slave I/O modules, and forwarded that to the firmware developers for the Scanner. Now I'm sure that the distributor will want to SELL some of these, instead of loaning them out !

The obvious thing to do was to manually retype all his text as native PanelView text objects, and to put it all on a similar-colored rectangle in the background to fill in the gaps between text objects. But he still wanted that graphical bezel (yes, one of the things the PV Standard lacks).   And a rectangular bezel with a big blank field in the middle takes just as much memory as one with text in the middle. Enter a very clever trick.... making a Graphic object into a Global object.   The trick is to Group the graphic object with some action type object like a pushbutton or an indicator.  Then, you can make the Grouped object Global.   Next, UnGroup the object. Now, when you right-click and select Global Objects, you'll find your graphical object with the name "No Text", or something to that effect.   You can now reference that on as many screens as you want, but it is only stored once in the PanelView. By the end of the day we had replaced his bezels with global objects and reduced the size of the PanelView application file by about 120K.

Then again, Apache is looking more and more attractive all the time.....

More to the point:  it's included on your Windows 2000 Professional CD.   From Microsoft's website: "Although Personal Web Server (PWS) can be installed separately from the Windows NT 4.0 Option Pack (NTOP) on computers running Windows NT Workstation 4.0, PWS does not run on Windows 2000. Instead, you need to install Microsoft Internet Information Services (IIS) 5.0, which is included in Windows 2000 Professional and IIS 5.1, which is included in Microsoft Windows XP."

Here I go, trying to sound knowledgeable, but myself fundamentally mis-led. "Windows 2000 Help refers to the Web services that run on Windows 2000 Professional as Peer Web Services (PWS). However, the name is actually Internet Information Services version 5.0. The incorrect references to Peer Web Services (PWS) occur in the following sections of Windows 2000 Help: TCP/IP utilities Internet printing Connect to a printer with a browser Manage printers from a browser"

Version 4.0 of either Internet Information Server (IIS) or Personal Web Server needs to be installed on Windows NT or 2000 for RSView32 Webserver to work.   RSView Active Display Server needs to have IIS, but Webserver will run with the lighter-duty Personal Web Server. Microsoft changed the name of the mini package from "Peer Web Services 3.0" to "Personal Web Server 4.0" at some point. Big ol' Internet Information Server is built into NT 4.0 Server and Windows 2000 Server, but I think it's an add-on to the Workstation / Professional versions of both operating systems.   I know that the Rockwell Automation sales division images come with Win2K Professional with IIS preinstalled, specifically to demo RSView32 Active Display.    This caused us no end of headaches during the NIMDA scourge. As with all things Operating System related, there's a host of if's, maybe's, and minimum revisions.  No, using Linux and Apache will not remedy this.   Oh, and neither will Windows XP.   Microsoft changed one of the principal HTTP publishing mechanisms in XP and everybody who wrote web publishing software has had to change to comply, and RSView32 isn't there yet.   Regular RSView32 works fine on XP, but Webserver and ADS don't yet. So in short, don't run out and buy Windows 2000 Server just to try RSView32 Webserver.   Get IIS or set up Personal Web Server instead.

A good book on this subject is the curiously-named "Home Automation Basics" by Thomas Leonik.    It's really about serial communications in VB6 to the MicroLogix, wrapped up in a home automation application principally to make it more attractive to the hobbyist market. You can get it from Amazon or Fatbrain.com.

Koyo was the original maker of early A-B products?   And the first to offer Windows environment ladder editors ? I've already heard that their equipment is perfect and free, and that their tech support people don't sleep or ask for salaries. Next you'll tell me about their goose and it's amazing golden eggs. Sheesh.

I've never built a PLC-5C15 Hot Backup system oustide the lab, but what you say makes sense with that I know about the equipment.   The "old way" using 1785-BCM modules to broker communications on DH+ and RIO, you would actually set your PLC-5's for the same DH+ node, and the Primary would be N and the Secondary would be N+1. ControlLogix hot backup works that way, too;  you set the 1756-CNB modules for the same address, and when they first boot up they report a node conflict, and then the SRM redundancy modules configure them to deal with it. I'm not certain if the secondary takes the N+1 node or not in that case. So, how you you use a ControlNet-connected MMI with a Hot Backup Redundant PLC-5C15 system?   I know people have used the Enhanced PanelView 1400e's and used an expression to determine which node to read from depending on which is primary.    RSView can do "alternate OPC servers" where it can switch data sources when one fails. But the standard PanelView 1000 just sends a message to whichever node it's tag is addressed to.   The Standard PanelViews don't appear to support Hot Backup I/O connections, either, so that's not a workaround. These PanelView Standard terminals might just not be appropriate for the application.

I still haven't gotten one of these for myself, but I borrowed it back from the dealer to explain a question for one of my clients. The client had been installing equipment at a chemical process plant that used 100-DNY42R DeviceNet "starter auxilaries" with in A-B motor control centers.   They had a lot of trouble with a batch of about twenty of them that had come in, saying they'd "crash the network" when installed, or otherwise "just not be recognized".   The verdict of the maintenance manager and my client was that A-B had shipped a bad batch of these devices. The story back at Milwaukee was different.  The QC manager I talked to three months later still had the returned units in a box under his desk.  He'd fired them up, and found nothing unusual except that the Autobaud feature had been turned off and they'd been software-set for 250 kb operation. That explained part of it to me;  the MCCs at the process plant had been set up for 500 kb operation, and when the hard-set starter auxilaries had been plugged in, they'd attempted to communicate at 250 kb, thus stepping all over messages that were running twice as fast, and creating a DeviceNet "Bus Off" condition.    Usually these starter auxilaries come out of the box at 125 kb, but with Autobaud enabled.   When they got purchased under a order with an MCC, though, they probably got hard-set to the data rate for the MCC under which they were ordered.... and then they were installed in a different one. What didn't make sense was that the DSA's sometimes "crashed the network" (read: "caused a Bus-Off condition") and sometimes came up and flashed their network LED's green but weren't detected by RSLinx or by the scanner module. The NetMeter helped explain it to me because I set up a 500 kb network and monitored it for bus errors when I plugged in a DSA set for 250 kb with Autobaud turned off.   About one time out of three, the bus error counter jumped twice, at one second intervals, and then a bus-off occurred.    The other two times, there would be no bus errors, and the DSA would blink it's green LED. What I deduced was going on is more or less chance;  there is a 10 millisecond interscan delay by default when you're using Polled I/O connections to your DeviceNet scanner.   Sometimes, the DSA was powering up and broadcasting it's DUP MAC ID CHECK message on the network during the interscan delay.   When it did, it didn't hear a response, and powered up at 250 kb and waited for a connection to be established. Sometimes, though, it would broadcast it's DUP MAC ID CHECK while other traffic was going on.   Because the bit widths are twice as long at 250 KB as at 500 kb, the messages were over-writing other traffic on the network, causing CAN frame errors.   These are the instances when the CAN error counters were jumping, and the Bus Off errors occuring.  It happened twice because the DeviceNet specification requires the DUP MAC ID check to be broadcast twice before a device can join the network. All I would have had was conjecture if the Netmeter hadn't been able to show me the CAN errors clearly.   The fix is just to be sure that the Autobaud feature is always turned on before you install a starter auxilary.

Hey, cool, I really like the highlighted quotations.   MUCH easier to read through than the ">>" that most debate-team style discussions take on e-mail lists or "that-other-PLC-board". LT1, you oughta be in good shape on your PanelView system.

Is the PanelView equipped with DF1 protocol or with EtherNet/IP? It doesn't really matter that much;  if you have the 1761-NET-ENI configured correctly to match the serial port of the MicroLogix, the PanelView will treat the MicroLogix just like it would an SLC-5/05.   You'll address the Micro's data tables just like you would over DH+ or DH-485 (what you called "directly"). The EtherNet/IP PanelViews are capable of doing a lot more, like  ControlLogix native tag addressing and EtherNet/IP I/O scheduled addressing with ControlLogix, but they also talk fine to PLC-5E and SLC-5/05, as well as to the 1761-NET-ENI. The main weakness I've found so far with the NET-ENI is to ask it to do too much.   The manual says it will handle six TCP connections at once;  two in, two out, and two either way.   If you have an RSLinx station talking to it, and a PanelView talking to it, now you've used up the two incoming TCP connections and have just one more to accept a MSG instruction from a PLC-5.    They're great to add a MicroLogix to an Ethernet network, but don't ask it to do much more than you'd ask the MicroLogix serial port to do.