Ken Roach
MrPLC Member-
Content count
2776 -
Joined
-
Last visited
Posts posted by Ken Roach
-
-
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.
Rsview32 webserver
in Allen Bradley / Rockwell Automation
Posted