Ken Roach

Do you have a ControlLogix REAL-type tag array set up in the "Map PLC/SLC Messages" function in RSLogix 5000 ? The ControlLogix needs that mapping table in order to be able to interpret PLC-5 type addressed messages from a legacy device like the 1770-KF2. Does the Bailey system give you any kind of error code ? How about the ControlLogix MSG instruction ?

As far as I know, PBASE won't allow you to "test run" the program; you need the BASIC interpreter in the module for that. PBASE is long, long obsolete. It won't run in any type of Windows environment. You are better off using Hyperterminal or any other terminal program to download and monitor. Most of what you need to test in an A-B BASIC module program are the CALL instructions that use the 1771 or 1747 backplane, or use one of the module's serial ports for an A-B specific function (like DF1 comms). Only a sophisticated emulator would do that, and PBASE was anything but sophisticated. If you have a program where you only need to test some functions that are not backplane or protocol specific, you might try to get a BASIC52 emulator.

That's probably it. The controller you have was built between June 1995 and July 1996 (the production run for AC-powered Series B controllers). In RSLogix 500, you should choose "Bul. 1761 MicroLogix 1000" The "DH485/HDSlave" features weren't added to the MicroLogix 1000 until Series D in 1998. Programs compiled for that version have features that the earlier MicroLogix controller won't understand, thus the "not a controller program" error. When you change the Controller Type in RSLogix 500 and download, the error should go away.

That's a wierd one. Most of the time you can't download a program if it's for the wrong type of controllers. It's possible that the program in the MicroLogix has simply become corrupted but has not been cleared. The easy solution is to re-download the program file. I've also seen this when the wrong version of MicroLogix 1000 is selected in RSLogix 5000 software. If you have a MicroLogix 1000 Series A controller, for example, but you select "MicroLogix 1000 DH485/HDSlave" as your controller type (features that were added much later) then you could get Error 10h. What's the Series Letter of the controller, and what Controller Type do you have set in RS Logix 500 ?

Ian is correct; the PanelViews that use the old PCCC type networks (DF1, DH485, and DH+) only support PLC-5 or SLC-500 style addresses. I usually set up an array or two just for PanelView communications and then set aside a periodic program to copy my functional Logix tags to the tag array that is mapped to PLC-style addresses.

Because AI is DOS based, it uses the old DOS hardware access methods. These won't work in Windows NT, 2000, or XP because there is an impenetrable operating system layer between the application and the hardware. As Firetubes said, you can use AI version 8.x with Windows NT/2000 by using RSLinx for communications. RSLinx has the proper Windows drivers for the 1784-PCMK card, and AI can talk to RSLinx using API calls, not hardware access.

The error message means precisely what it says: the *.ACD file you have is incompatible with RSLogix 5000 Version 7. If you aren't using any of the new features in Versions 8, 10, 11, or 12, then you can perform the operation suggested by the message: Open the *.ACD file with a newer copy of RSLogix 5000, save it as a *.L5K file, and make appropriate changes to the *.L5K exported file. What those changes are is what you may need help with. For that, contact Rockwell Automation directly. If the real problem is that you don't have new software/firmware support, you should buy a support contract and get upgraded to a newer version. If you have a system that is fixed at Version 7 and somebody supplied later version software, it's up to them to provide you Version 7 compatible program files.

Years ago there was a clever company called Pro-Log, who built "STD-Bus" industrial computing products. Before their acquisition by Motorola's industrial computer group, they made a GENIUS / RIO bridge device. It was really pretty neat; It was a GENIUS master and a RIO slave and you could set up block transfers to it and emulate multiple racks and other nifty stuff. According to my research, it was fast and compact. But.... They stopped making it. There just wasn't enough GENIUS conversion going on. When I spoke with the product manager he said he had parts and drawings on the shelf, and could deliver ten of them in a month once he had a solid order. This was of course the classic "cart/horse inversion" problem; my customer wanted to see a demo before he'd invest anything in the conversion from Series Six, and I didn't have the budget to buy the minimum number of GENIUS/RIO converters. From my research about the Pro-Log gateway, it was superior to the X-Link because the X-Link only transferred one "datagram" at a time from the RIO image to the GENIUS bus. This would like sending a book in the mail, one page at a time. The Pro-Log gateway transferred whole big blocks of datagrams at once. I'm no GE expert, and this project never flew, but it might shed some light on why there isn't too much in this product category on the market.

A classic A-B controller conundrum. You're probably familiar with A-B's 16-bit signed Integer data elements. These allow you to use 15 bits of data plus one sign bit to represent integer numbers between -32768 and +32767. This weakness is exactly the reason that ControlLogix controllers use 32-bit data elements. The new MicroLogix 1200/1500 controllers have a Long Integer data type that allows them to use 32-bit signed integers too. But when you're using SLC-500 or PLC-5, you are stuck with that limitation. To count to 999,999 the easiest thing to do is to use two cascading counters: One counts only 1's, and the other counts 1000's. Your first counter will have a preset of 1000. Every time it's Done (C5:0.DN, for example) bit comes on, that bit should trigger a second counter with a preset of 1000. You can display both counters side-by-side in your HMI. There are other ways to beat the 32767 limit, but I'll leave those up to other Forum members.

There's no publicly available software utility to convert PLC-3 logic to PLC-5 or ControlLogix logic. Rockwell's GMS service division has some internal tools they use in turnkey products; that work is headquartered out of their Detroit and Salt Lake offices. There's also an integrator on the east coast of the US called "Javlyn" who have PLC-3 -> 5 conversion down to a science. If you have a conversion project they are very likely to be your best route to get it done.

File this one under Fiction, alphabetized by author. APS, AI-500, and RSLogix 500 are the only programming packages that have ever been available for the Allen-Bradley SLC-500 programmable controllers.

um, why ? The 1747-PIC is readily available new and used, and B&B Electronics makes a cheaper equivalent. Are you really that dedicated to "build versus buy" ?

I spoke before I looked; GE's website is pretty slim on PAC information, but at least they did publish some user manuals: http://www.geindustrial.com/support/docume...nts/gfk2224.pdf I suspect you're out of luck if that user manual is current. It says that the PAC Ethernet interfaces support only GE's proprietary Ethernet protocols, not any of the open ones like Modbus/TCP or EtherNet/IP.

I don't know anything about GE's PAC70 product. I presume that it can use one or more of GE's three Ethernet-compatible protocols: EGD, SRPT, or Modbus/TCP. Of those three protocols, the only one that you can get a ControlLogix interface for is Modbus/TCP. Prosoft Technology (www.psft.com) makes that module.

The SLC-5/04 serial port with 1761-NET-ENI should appear, protocol-wise, just like an SLC-5/05. Doesn't Wonderware include a direct driver for A-B PCCC Ethernet devices in their standard driver set ?

Post an example of how your successful syntax was configured in the OPC Test Client, and also an example of an unsuccessful syntax in RSView32. If the OPC Test Client is on the same PC as RSView32, then RSView32 certainly should be able to see all the same data as the Test Client. I did find a Technote about "registering OPC servers on the local machine" on the RSI Knowbase. Go to support.rockwellautomation.com, bring up the Knowbase search, and find Document G29550158. Document P7973 also talks about Remote OPC and DCOM. In fact, go ahead and search on "RSView32" and "Remote OPC" as keywords. Does RSView32 ever give you an error message for the tags that are addressed to this remote OPC server ?

File Name: 1771-SDN Diagnostic Display tabulator File Submitter: Ken Roach File Submitted: 2 Oct 2003 File Category: PLC Sample Code Makes a table of the "diagnostic display" values that scroll across the 1771-SDN indicator. Click here to download this file

It sounds like you might not be selecting the PCMK driver. It's been foolproof for me since the Plug-and-Play driver for Win98SE came out four years ago. RSLinx has just one configuration window for several different card types; PCMK, KTX, PKTX, etc. You have to select "PCMK" in the configuration window. What operating system are you using, and what version of RSLinx software ? You also might have an honest-to-God conflict with another device. Are you running and other PCMCIA cards or peripherals on this PC ?

Actually, if you have a 1756-ENET with Series B firmware, you can support EtherNet/IP I/O connections. It's only 10 mb and half-duplex, and only 900 frames per second instead of 5000 frames per second, but it does work. It's pretty good for Produced/Consumed Tags over EtherNet/IP. Older 1756-ENETs could be flashed to Series B firmware if they came from the factory with 1.18 firmware and had the PAL chip from Hardware revision H or later. The 1756-ENBT is faster and cheaper.

Most devices ship with an "Electronic Data Sheet", aka EDS file. This describes the device's encoded DeviceNet data objects to an EDS-based configuration tool, of which RSNetworx for DeviceNet is probably the most popular. If your slave device has an EDS file, it most likely can be configured using RSNetworx. If your 3rd party device is a Master, it can't be configured with RSNetworx. The ODVA never set out a universal standard for Master configuration, so each vendor does it themselves.

loosewire, the 1761-NET-DNI is really just a DF1 encapsulation device. It doesn't provide "DeviceNet" access per se, just a way to wrap up DF1 and transport it over DNet. It won't do the same things that a 1770-KFD will do. I have a number of customers with 1771-SDN based systems who are disappointed with the speed of the 1771-SDNPT passthrough driver, and want central access instead of having to walk down to the DeviceNet with a KFD. We're eagerly awaiting the launch of the 1788-EN2DN that will let us drill down using RSLinx from Ethernet to DeviceNet.

If you forgot to set an IP address, then the SLC-5/05 controller is probably still broadcasting a "BOOTP Request" message on the Ethernet port. Use the BOOTP/DHCP Server utility (look under RSLinx Tools or just under Rockwell Software) to intercept BOOTP requests and set an IP address in the controller.

I cannot explain why A-B gave up on the DF1 protocol manual after about 1996, but they did. The SLC-500 single-bit write technique isn't described in that book. They way I think it works is that you're never precisely writing a single bit; instead, you're writing a word with a mask. Use the Protected Typed Logical Write with Mask command; That's Command 0x0F, function 0xAB. It's just like the Protected Typed Logical Write w/ Three Address Fields except that it adds two bytes for Bit Mask. CMD = 0x0F STS TNSW [byte Size] [File No.] [File Type] [Element No.] [subelement No.] [bit Mask] Data Again the bit mask is two bytes, low byte first. Bits =1 in this mask designate bits affected by this write command. I wish there was an updated and corrected DF1 manual. I dug this out a couple of years ago while troubleshooting a 3rd party driver.

"Ouch" is one word for it ! :*-( I've been told that the "Smart Cable" is an RS-232 to current-loop serial converter, so that something from B&B or Black Box might do the same job. But I've never read specifics about it. The price for the Smart Cable is of course less of a money-making device and more of a mechanism to encourage users to upgrade away from this obsolete and expensive-to-support controller.