Eddie Willers

The *simplest* way is to attach a 1770-KF2 to the serial port of the MicroLogix 1500. It's also VERY expensive, and quite bulky. There are third-party DH+ interfaces available that cost less then the KF2, such as those from www.protocolconverter.com. MicroLogix controllers were just never really intended to go onto DH+ networks, that's why there is no cheap or modular interface for them. The most requested network these days is usually Ethernet.

I think the DriveTools integration is only for those tabs on the Connection configuration that allow you to launch DriveTools for that particular device from it's I/O connection configuration within RSLogix 5000. Just cancel/click past those notices and you should be able to get the 20-COMM-E devices into the I/O tree okay; you just won't have the DriveTools functionality. I have only DriveExplorer Lite on my machine and I don't get those errors from Logix 5000 anymore.

I do that when I'm using DH-485 or DF1 networking because it allows the PanelView to read and write an array transaction instead of multiple network transactions to data table elements all over the controller. That puts the least load on the network, so you can get the best pushbutton and display performance. It's also a good practice so that somebody working on the PLC program knows which data table elements are being written to by the PanelView. I've encountered "mysterious" program behavior in which PanelView changes were being made to data table elements I expected to be static.

Call A-B technical support and arrange to have their field support guys crack the password for you. It's the only ethical way to do it. We don't discuss password cracking on this site.

Unfortunately, Nilesh, this is a serious problem. It appears that you have "bricked" the controller by interrupting firmware download. It is very uncommon but it is possible. If the battery is not connected, simply cycling power will reset the controller. There is no other reset method. If RSLinx can "browse" the controller via DF1, you can try re-downloading the firmware. If RSLinx cannot browse the controller via DF1, you must replace the controller. When I load firmware into FlexLogix controllers, I strongly prefer to use an Ethernet card.

I've never heard of these Widgets before today. I'll admit, they look cute ! In my opinion, a system using six of A-B's largest PLC-5 controllers isn't "small", but then I don't know what sort of budget you've been given to work on this. For a PLC-5 system of that scope I generally use RSView32 and the Webserver. That scales nicely depending on how many tags you have to view.

Maybe the original poster is referring to the fact that the 1784-PKTX is a 5V PCI card. Many new computers have 3.3V only PCI buses, not "Universal" PCI buses that support both 5V and 3.3V. I got bitten by that on a Dell server PC; Dell adamantly refused to give details on their PCI voltage, saying only that they used "PCI 2.0". It turns out that "PCI 2.0" allows the manufacturer to support 3.3V, 5V, or both, so it guarantees nothing. Rockwell is said to be working on a 3.3V version of the PKTX, but I heard that the project was outsourced to India and they are two years behind in development. I could be wrong; that problem I ran into was last summer and they might have made some progress. SST (www.mysst.com) and Data-Link (www.protocolcoverter) both have non-Rockwell DH+ cards. These do not support RSLinx, but do provide a PCI interface to DH+.

Type the word "excel" into the RSLinx Help index and go from there.

Strictly speaking, the "addresses" in a Modbus RTU frame are represented in "twos complement binary", not in "hex" or "decimal". 02 hex = 02 decimal = 00000010 binary, for example. 0C hex = 12 decimal = 00001100 binary, for another example. It doesn't really matter what form your programming software represents the value, as long as it comes out correctly in binary format. The only way a "hex address" and a "decimal address" could be different is if the Eurotherm device were using Modbus ASCII protocol, in which numbers are represented by their ASCII codes instead of in binary format. A-B supports only Modbus RTU format, and everything I read about the Eurotherm device says that it sues Modbus RTU format too. When you say "memory address", do you mean the Modbus register, or the network slave address ? You might have to get between the MicroLogix and the Eurotherm with a serial analyzer to figure this out for certain. Can you communicate with the Eurotherm via their own software ? Trapping and analyzing that traffic might give you a place to start.

In other networking systems like A-B RIO, the memory location in the controller corresponds to the network address and slot number of the 1794 FLEX I/O module. With DeviceNet, however, the memory location in the controller for a 1794 FLEX I/O module is entirely dependent on the "mapping" that you perform in RSNetworx for DeviceNet. Generally, FLEX I/O uses 16-bit data elements, while the 1788-DNBO uses 32-bit data elements. You will probably have to use COP instructions in ladder logic to sort out the FLEX I/O data from the Input and Output tags of the 1788-DNBO.

I don't think a SoftPLC or any other brand is going to be the best fit, Raul. The PLC-3 system is likely running A-B Remote I/O chassis, and might even be a redundant hot-backup pair. No other control brand will let you re-use that 1771-series I/O, and SoftPLC's hot standby doesn't support A-B I/O chassis. PLC-3 conversions are a big investment in engineering time. I probably quote one every couple of months, but have not sold many because I get customers who have a tiny fraction of the original controls budget to do the retrofit, and they usually add a big stack of features they want to add to the controls, while maintaining all the original I/O and wiring. ControlLogix has been my platform of choice. It gives me more options for new features, like adding Ethernet or DeviceNet or Profibus. The big gotcha has been making sure that there is enough CPU resources to handle a lot of old-fashioned Remote I/O, especially with large numbers of analog modules. This is why guys who make PLC-3 conversions a speciality win a lot of business, and guys who only dabble tend to make expensive oversights.

I thought that ordinary FlexPak drives get as big as 600 horsepower, with the very biggest around 1500 HP. You specified 2500 horsepower. If you already have a lot of FlexPak drives, then you probably know the name and phone number of your Reliance salesman. Maybe he can help you choose a Reliance or A-B drive for your application. A 2500 horsepower drive isn't really something you just choose out of a catalog.

The 1395 drive gets that big. You can see the drive at this address: http://www.ab.com/drives/1395/index.html You can get local A-B sales office phone numbers from the www.ab.com website. I think this application will get their attention. For large drive systems, I work with Rockwell's "LDS" business, which has a lot of former Reliance drive engineers in it. What are you moving with that monster motor ?

Harmony is a subsystem of RSLinx, and is responsible for that "RSI Directory Server" icon that accompanies RSLinx in the services toolbar. Here's how I always fix Harmony problems: 1. Shut down RSLinx and the Harmony server. 2. Delete Harmony.HRC and Harmony.RSH. I think they are both in the Program Files .... RSLinx directory. They might be in another RSI directory.. search for them. 3. Reboot. RSLinx will rebuild the Harmony files the first time the program is run. You'll lose your shortcuts and driver definitions, but they software ought to function correctly after this. The next step is to start uninstalling and reinstalling, and that's a lot less fun.

That doesn't look like a CNC application to me, just a simple indexing application. I'm not sure what you meant by "CNC slot card"; the ControlLogix has motion control via analog or SERCOS or SSI but it's not CNC-like. A-B has the Ultra 3000 series servocontrollers that you can connect to with ControlLogix motion or DeviceNet. If there's only one or two axes of motion (and you're set on A-B) I would start looking at the MicroLogix 1500 and the new Ultra 1500 servo controller. The MicroLogix 1500 can do simple step-and-direction motion control fairly easily. If you want to use an SLC-class controller, look into AMCI's stepper controller modules. Don't try the old SLC "IMC-110" servo or stepper modules; they were junk when they were new.

Siemens Instruction List (IL) programming is unique in it's low-level approach to PLC control. In my experience, hardcore programmers love it and maintenance guys hate it. Rockwell's closest comparison is the Structured Text language that all the ControlLogix-family controllers support.

Floating Point numbers (REAL datatype) and Double Integer (REAL) datatypes are both 32 bits long, but they are not the same. REAL datatype tags in ControlLogix use the IEEE 754 single-precision format. You can read up on it and understand the whole mantissa / exponent thing if you like. Think of that pair of INT array elements as hexadecimal, where 16544 = 0x40A0 hex. INT[0] = 16544 dec = 40A0 hex INT[1] = 0 dec = 0000 hex If you were to COP both of these into a REAL datatype tag (use Length 1 in the COP instruction), the first element would go in the lowest two bytes, and the hexadecimal representation woul be like this: REAL = 000040A0 hex Check how that would convert to a floating point number using this website: http://babbage.cs.qc.edu/courses/cs341/IEE...E-754hex32.html You will see that in that order, those values translate into... well, some very tiny number. In this order, though: REAL = 40A00000 hex = 5.0 floating-point decimal You could use the Swap Bytes instruction, or you could just set up the INT array elements in the right sequence before you use the COP instruction to move them into a REAL datatype tag.

Since you connect up to the PanelView terminal directly, you probably have a good idea about how it must connect to the SLC. If you are using a serial port, the PanelView is probably using that serial connection too. If you use a DF1 driver in RSLinx to connect to the PanelView, the PanelView is using DF1. If you are using a DH485 driver in RSLinx to connect to the PanelView, the PanelView is using DH485. The SLC-5/05 has an "Ethernet Passthrough" function you might be able to use. You're probably going to have to read up on it in the User Manual or the Online Help in RSLogix 500. If you can describe the exact port configuration on the PanelView, Forum users can give you more suggestions. The part number of the PanelView (the exact part number) tells that precisely.

If you have 1747-SDN firmware 4.15 or above, you can do this with the "1747-SDN Passthrough" driver in RSLinx. This driver is similar to other "passthrough" drivers in that you have to define the SLC and the 1747-SDN through which you want to connect. You don't "drill down" in RSLinx, instead the path to the SLC-5/04 and the particular 1747-SDN is represented by the driver itself. The 1747 and 1771 DeviceNet passthrough drivers are awfully slow, though. I only use them when the alternative is driving a couple of hours to get my 1770-KFD or waiting for one to arrive by air freight the next day. I have seen OEMs who try to go cheap and don't give their service guys 1770-KFD or 1784-PCD interfaces. All of those guys hate DeviceNet because they have been purposely given the worst possible tool,

The XM-120 is as simple as Entek gets. I was able to set up thresholds on it and get the alarms into a ControlLogix through a 1756-DNB the one time that I worked with the XM products during a workshop. Their other product is an analog-output device called a "Sentinel", but it lacks self-diagnsotics and digital DeviceNet communications.

The first page of that application note tells us the bad news: Since the CompactLogix supports only EtherNet/IP and none of those listed protocols, your only option is to add a card that does support one of those protocols. Prosoft makes two MVI69 modules that may be of interest; the MVI69-MNET supports Modbus/TCP protocol, and the MVI69-GEC supports generic ASCII protocol over Ethernet. I wish that A-B would add a generic Ethernet "string" instruction in Logix, but I don't see any evidence that it would be useful outside these sort of low-volume integration projects. If the "open ASCII" protocol used by the robot was simple enough, you could use a 1734-AENT POINT I/O adapter and a 1734-232ASC module to send and receive ASCII strings to and from the robot. I recently saw an application where that was done with a simple stepper motor controller and it took a couple of days to accomplish and test.

Here's the deal; MicroLogix controllers can use DF1 or DH485 as their two main comms protocols. It's settable in the RSLogix 500 configuration software. DF1 is point-to-point, so just the MicroLogix and the PanelView or the MicroLogix and your PC can talk to one another. Two devices only. Just two. Never three. Four is out of the question. DH485 is multipoint, so you can have the PanelView, the MicroLogix, and your PC all talking at once. It will actually support up to 31 devices, but 3 to 15 is typical. When you have purchased a DF1 PanelView, you cannot just select DH485 as its communication protocol. It's different firmware, and maybe different hardware. If you use a 1761-NET-AIC and set the MicroLogix to DH485 protocol, you can hook up your computer using DH 485 protocol but... the PanelView won't talk that and there's no port to hook it up ! The long shot way to do this is with TWO 1761-NET-AIC modules. You could convert the PanelView 300 terminal to DH485 protocol (using the existing RS-232 serial port) with a flash firmware upgrade (this is not documented but does work). You need TWO 1761-Net-AIC modules connected back-to-back on the DH485 trunkline (the six-pin Phoenix connector) to get enough serial ports to connect the PanelView, the MicroLogix, and your PC. If that sounds like too much trouble, just live with the plug/unplug dance for now and get the right stuff the first time for the next machine.

You need to be more specific about your hardware and architecture. There's no such thing literally as a "wireless hub". I have a Netgear WGR614 on my desk. It is a 802.11b/g Wireless Access Point and Router. It has four Ethernet switch ports, one Ethernet WAN port, and an antenna. The devices I connect to the switch and the devices that I connect via 802.11b wireless are part of the same IP network. 192.168.1.1 My computer, via wireless. 192.168.1.2 1756-ENBT 192.168.1.3 PanelView Plus 192.168.1.9 1788-EN2DN bridge I can access all those devices from my PC. However, a computer on the network attached to the WAN port on this Negear WGR614 cannot access those devices. They are hidden by the router's built-in NAT function (Network Address Translation) and firewall. So, specific configurations would have to be done to the router to make those devices on my subnet visible to the outside world. This could be done with Port Forwarding, or with something called a DMZ table. It's an interesting topic. What more can you tell us about your system ?

The SLC-500 does offer a "redundant" I/O scanner module, the 1747-BSN. This gives two SLC-500 controllers the ability to work the way an old PLC-5 hot backup system did, because they will scan the same I/O. If both controllers keep the same program, then they can work as "backups" to one another. This is not as sophisticated as the ControlLogix system, where the two controllers are literally running in parallel and changes made to one are made to the other automatically. Because the uses of redundant controllers are as widely varied as the uses or ordinary controllers, I don't think you will find "examples" outside of the User Manuals.

Emphasis on MORE. There are many different ways to connect a PanelView to an SLC controller. You will have to post DETAILS about your connection before anyone will be able to help you. It is OK if English is not your native language, but it is not OK to expect Forum members to guess your question.