Eddie Willers

You've got it: the Trend object only logs while it's visible unless you have configured a Data Log object to hold the data in the background. Just limit the size of the datalog file, and it will write over itself after a number of records. There's no harm in keeping the datalog running all the time as long as it's not a gigantic file.

You can purchase both of those products from Rockwell Automation distributors. They are not free products, and cannot be simply "downloaded" from some outside site. Rockwell doesn't have representation in Mauritius, so the closest RA distributor is going to be in South Africa. You can contact Rockwell Automation in South Africa at: Rockwell Automation (Pty) Ltd Riverview Park Janadel Avenue Halfway Gardens Midrand 1685 South Africa P O Box 7096 Halfway House 1685 South Africa Tel: 27 11 654 9700 Fax: 27 11 654 9701

Definitely, the Woodhead/SST Profibus DP master module for the SLC-500 platform is the best way to interface Profibus DP networks to the SLC-500 controller.

A-B offers an internal flatscreen replacement for the CRTs of PV1400e terminals as they grow dim or fail. That's a zero-effort retention of the existing system. DH+ applications are much easier to translate to RSView ME than RIO applications, in my experience. If you're not comfortable buying and learning the new software, hire out the job to Rockwell or an integrator who knows both platforms.

If the drives appear with question mark icons during a network browse, then you are simply missing the EDS file that allows RSNetworx/RSLinx to recognize them. If they don't appear at all, they are not responding to the software's attempts to connect to them via an explicit message. I've seen some devices that can only establish an I/O connection *or* an explicit message connection, but not both simultaneously. You can connect to them to configure before you get an I/O connection going, but as soon as the scanner has an I/O connection established, you cannot connect to the drives, even for browsing, with an explicit message. Not a great feature set, if you ask me. To determine this conclusively, you have to remove (or deactivate) one or more of the drives from the 1747-SDN's scanlist, then cycle power to the drive and attempt to browse it again. Not easy during production, but the only way to be certain. Check the Mitsubishi documentation to see if they mention an Unconnected Message Manager (UCMM) object. If they have a UCMM, they should support both messaging and I/O connections at the same time. Last time I commissioned a Mitsubishi drive on DeviceNet, we found that the drive would not recognize the scanner going into Idle mode (like on a controller fault) and we ended up dropping power to the whole network in an Idle condition so that the drives would not run away when we put the controller into Program Mode.

Bummer about the lack of backups. I presume you're going to embark on a program of backing up other systems in the facility that are in similarly precarious situations. Maybe the PanelView isn't communicating for the same reason that it lost it's program. Is there an error message on the screen ? Because there are so many different variations of the A-B PanelView product, you will have to post the exact part number for anyone to be certain of how to communicate with it. You mentioned that the PanelView connects to the SLC-5/03 using a 2706-NC13 cable. That is a straight-through serial cable that connects to Channel 0 of the SLC-5/03 controller. This doesn't tell us for certain what protocol (DF1 Full Duplex or DH485) the PanelView is using. The PanelView's port labels and the PanelView part number will tell us for certain. You mentioned being "up the Suwanee". Are you in Georgia or in Florida ?

It's often said that you can have things done fast, or done right. We saw what happened when Rockwell Software tried "done fast"; the result ws RSView SE 3.0. I'm willing to wait if it means the product quality and reliability go up.

The limitation in an EtherNet/IP network is almost always the port on the controller. The CompactLogix is meant to be a small machine controller, so it doesn't have a massive communication coprocessor. In your excellent description, you did good job of describing about "how much" data you're requesting from the controller. The second half of the equation is "how often ?" Use the diagnostic webpage of the CompactLogix to determine how many Class 1 packets per second your I/O connections are taking up. You can also figure that out by adding up the connections in the I/O configuration in RSLogix 5000 according to the equations in the EtherNet/IP Performance and Application Guide. Investigate the update rate of your PanelView Plus displays. Do the same with your RSView32 scan classes. communications timeslice value. Default is 20%. Five simultaneous HMI sessions qualifies as a "high bandwidth" requirement in my book, so I'd increase the timeslice to 30 or 40%. Put in GSV instructions to monitor the Module connections of the POINT adapters to make sure the CompactLogix isn't dropping those I/O connections (it shouldn't be, but it's possible) when the RSView sessions are hammering on the port.

I think an important question is whether or not "getting the laptop working" involved a clean operating system installation. If files that Rockwell says should be in the registry are not... that points to an OS problem or MS Installer problem. Have you called Rockwell Automation technical support on this issue ?

There are three DH+ cards for PCI bus computers that I am familiar with. Because DH+ is an older dedicated-purpose industrial network, none of these devices are "low cost". A-B makes a 1784-PKTX card, a PCI version of the 1784-KTX. Check to be sure that it is compatible with your PCI bus, which may be 5V (older) or 3.3 v. Data-Link Corp. makes a PCI card called the DL-PCI that communicates with DH+. They also make a DL-3500 device that connects the PC to DH+ via USB or RS-232. Woodhead Connectivity (SST) makes a PCI card called the 5136-SD-PCI-U. You may wish to consider which driver software you will require when making your decision. A-B RSLinx will work with the A-B card and the Data-Link card (it emulates a COM port) but I don't know if the RSLinx "SD/SD2" driver will work with the current version of SST's 5136-SD-PCI-U. Your other option is to communicate from your computer directly to the SLC-5/03 controllers using the RSLinx DF1 Half Duplex Master Polling driver. Check out that caps lock key when you get a chance, too.

You do not use the "1747-PIC/AIC+" driver in RSLinx to configure the 1747-UIC. Instead, you use the "RS-232 DF1 Devices" driver. The 1747-UIC will appear as a COM port on your computer when you install the drivers that rgurin linked to. I think there is a small instruction pamphlet that comes in the box with the 1747-UIC that describes the proper settings for the RSLinx driver. Here's a direct link to the installation instructions document, which also includes the RSLinx DF1 RS-232 driver settings on page 11: 1747-IN063C For quick reference, the driver settings are Device Type 1770-KF3/1747-KE Station Number 00 19200 baud, No Parity, 1 Stop bit CRC error checking Full Duplex Protocol

RSView Studio only uses RSLinx Enterprise communication drivers to download runtime files to PV+ terminals. RSLinx Enterprise is configured entirely within RSView Studio, in the Communications tab. RSLinx Classic can be used as a data server, but has no role in downloading to the PanelView Plus terminal. In fact, sometimes Classic and Enterprise will contend for the same hardware resource (like the serial port) which confuses some inexperienced users. Call your Rockwell Automation distributor and see if you can get them to run through the fundamentals of how RSView Studio and RSLinx Enterprise work together. There is also an extensive online documentation set included with RSView Studio.

You can read all about the DataStore ActiveX object on the A-B Knowledgebase: Datastore ActiveX A88751639 This object can't run on PanelView Plus terminals, but it can run on their close cousins the VersaView CE.

If the system was running fine, what changed in the installation or program at the time the problems started ? For best performance, you should limit the number of simultaneous explicit messages being routed through a 1756-DNB to five. Are any of the explicit messages resulting in errors ? Are any of them not working as expected (i.e. might they be getting sent to the DNB itself instead of a node on the DeviceNet) ? What firmware revision is the 1756-DNB ? If you have access to any DeviceNet metering or diagnostic devices, the network utilization and CAN error rates would be useful information. I think I recall, in the distant past, a DeviceNet scanner performing a reboot when a particular malformed response was returned from a slave device explicit message. Can you tell us anything about the Lenze parameter read performance or mechanism (i.e. is it using Class 0x0F for the Parameters or a vendor-specific Class ?)

Hey, that's great news. Now we know that there's a whole Division at your company who are cheapskates.

Och, you kids are so spoiled these days, with your Plug-and-play and your automatic drivers ! The 1784-KTXD is an ancient beast, a card for the ISA bus. Those DIP switches onboard it define it's Memory location and interrupt. Most modern PCI and PCMCIA devices automatically get these things assigned by their "plug and play" functions, but not the old ISA cards. RSLinx contains the driver; there's nothing separate to install or register. You need to match the RSLinx driver configuration with the interrupt and memory location that you set with the DIP switches. It's been a while since I had to find a free interrupt and memory location on a Windows 2000 PC. The A-B Knowledgebase should have some good hints for you regarding this card.

Hal, I encourage you to tone down your approach if you want to remain welcome, and to be taken seriously. I know all about your experience, your influence, and your skills, but frankly I discount them all because your manner is so very unpleasant. Lighten up !

Yes, all those controllers have at least one port that uses a special 8-pin mini-DIN connector, which wires up to the 9-pin D-sub connector on your computer. The A-B part number for the cable I use is 1761-CBL-PM02. The wiring diagram for these cables is available from the A-B knowledgebase, but I don't recommend trying to build one yourself. Those 8-pin connectors are unusual and hard to wire into. A few small (garage-scale) companies have built slightly lower priced cables, but I have a hard time trying to justify even a small effort to save money on a $35 cable. PLCCables.com appears to still be in business. A-B used the unusual connector because these connectors also carry 24 VDC to power auxilary equipment like the old handheld programmer, and Net-AIC, Net-DNI, and Net-ENI interface modules. If they'd used a standard 9-pin connector, thousands of users would have blown up their serial ports by plugging in cables that connect the 24V pin.

A-B engineers wrote some example code to do exactly what you describe; perform Modbus RTU commands using the ASCII mode of the CompactLogix serial port. It is included in the sample programs that come with RSLogix 5000. Unfortunately, this code is very complicated, and I've been told by some who have tried to use it that there are deficiencies in it. Therefore, I would not recommend it for a beginner. The MVI69-MCM is really the most straightforward way to get Modbus RTU functionality on a CompactLogix controller. Other methods include Modbus/DeviceNet gateways from Western Reserve Controls, Hilscher, and HMS Fieldbus, as well as EtherNet/IP to Modbus gateways from Real Time Automation. There is even a Modbus RTU/DF1 converter that A-B sells to connect to PowerFlex 4/40 series drives. There's always a price for functionality; it's not realistic to say "I have $0 and I need a function that's not built in". If this is a one-off project you're going to spend many times more in labor than you would have in hardware. Tell us more about the Modbus devices you need to communicate with.

It doesn't do that to me. Did you create this folder under "all users" or just for your own user ID ? What OS are you running ? I am running RSView Studio 4.0 and it's a LOT more stable than the previous releases. I only want to scream at RSI once or twice a week these days, rather than every time I try to start the software.

The 1770-KF2 is VERY expensive and large. If A-B were interested in selling more serial to DH+ converters, they would have done a redesign sometime in the last 18 years. I recommend a work-alike alternative to the KF2 from www.protocolconverter.com The DL-3500 is cheaper and works just like a 1770-KF2.

The very early MicroLogix 1000 controllers only supported DF1 Full Duplex; the DH-485 and DF1 Half Duplex capabilities were added later. You say the MicroLogix is firmware 2.0.... that *ought* to support DH485, but it's an "autoswitching" feature and doesn't work well point-to-point. Usually you have to hook the MicroLogix 1000 up to a DH485 network with activity already present in order to have it switch.l Try adding the MicroLogix 1000 to a network that already has DH485 traffic on it and see if it comes up on a DH485 browse.

I recently inherited a VersaView 200R computer from a mothballed project. I don't have the A-B documentation, but in my experience with A-B computers they're pretty closed-mouthed about what's really inside them. So, I'm going to take this one apart and have some fun with it, and post the findings here on the MrPLC forum. My unit part number is 6155R-NS2KH, Series A Rev A. The "2K" must mean Windows 2000, as it has a license sticker on it for Windows 2000 Professional and it boots to Windows 2000. There's an RSView32 runtime license and application on the computer. I immediately took off the cover (7 tiny screws for the cover, 4 for the hard drive) and found there's a single-board computer inside with a PC/104 expansion bus. Silkscreened onto the board is the vendor name: "Wafer-6820". Google then led me to ICP industrial computer products: http://www.icpamerica.com/products/single_...WAFER-6820.html Terrific ! Now I know there's a FDD connector on there somewhere so I can patch in a floppy, and I might be able to connect a CD-ROM to this somehow, too. More news as I get further into the box.

I got into the hard drive, which is in a nice solid carrier, though without any shock mounting. A-B part number is 6189-P25HDSTD A, with another A-B sticker repeating the 6155-NS2KH part number over the Travelstar data. There is some old clear adhesive near the connector; it's possible that the 44-pin IDE connector was once glued on, and that this hard drive is a replacement. The IBM part number 07N8325 says this is a 20 GB drive, which matches its information in Windows. This was a very popular laptop hard drive, used by Dell and HP and Compaq. Some of the online reviews I've read complained of failures in laptop applications, so if I put a new one in I'll keep my eyes peeled for another make. I think I'm going to make an image for backup of this one for now, before I break more stuff. I have a 44/40 pin IDE adapter so I can attach this to my big desktop system and use Norton Ghost to burn an image of the drive to CDs.

The 1761-NET-AIC only does physical conversion from RS-232 to RS-485 electrical signalling. It does no protocol conversion. The 1770-KF2, conversely, actually converts from DF1 Full Duplex protocol on RS-232 to DH+ protocol on DH+ signalling. The MicroLogix still thinks it is "speaking" DF1 Full Duplex protocol, but the 1770-KF2 device converts that traffic to the DH+ protocol. It's a little like asking if you can put a Chrysler 440 Hemi into a lawnmower. While it might be physically possible, the lawnmower isn't really built for the racetrack. I suspect Sergei has an application where his customer has a small application but a DH+ network installed in their plant, so they want to use the inexpensive MicroLogix 1500 controller but also have the PLC-5 networking on DH+. It would probably be cheaper to put in a small PLC-5 or SLC-5/04 than to try to connect a MicroLogix to the DH+ network.