Eddie Willers

You can use "Datalinks" to set parameters in the drive, or you can use MSG instructions in a controller to set parameters in a drive. Which parameters, exactly, do you want to change between modes ? What kind of controller will be in control of the 20-COMM-E device ?

I don't think you necessarily need to change the DeviceNet configuration. You probably just need to stop sending start/stop commands from the SLC-5/04 controller and change some of the control configuration parameters in the drive. What model of variable frequency drives are these ?

The EtherNet/IP protocol used by ControlLogix and the 1756-ENBT is open and published. There is a set of resources describing the use of the EtherNet/IP protocol on the A-B website: http://www.rockwellautomation.com/enabled/guides.html The general EtherNet/IP specification you get from the Open Device Vendors Association, www.odva.org. They maintain both the EtherNet/IP and DeviceNet specifications.

If you're going to do much DeviceNet work it makes sense to get a 1770-KFD. They aren't cheap, but they're universally compatible with everything A-B and are faster and more dependable than backplane passthrough. My -KFD rides around in my network bag along with the Keyspan 19HS USB/RS232 interface so that it can take up on unobtrusive COM port assignment. The only controllers that don't support some kind of backplane passthrough are the MicroLogix 1500 and the old L20/L30 CompactLogix. I just prefer to have a direct interface to the network so that I can do commissioning and messaging without depending on the PLC or worrying about the scanner's connection interfering with the device state.

If it were me, I would hire somebody from Rockwell Automation or another integrator who already owns AI-2 and an interface cable to come and upload the program and provide you with a printout. The thermocouple type isn't the only valuable bit of information in the source code.

An oversight by me; I was using an emulator, which doesn't support the MicroLogix 1100 operating system. In the MicroLogix family, the CPW (Copy Word) is insensitive to data type size mismatches. Use it instead of COP to make this data reformat in the MicroLogix. How about those values, Raj ?

Raj, I certainly agree that Modbus should be implementation-independent. But in the real world, it's just not. Folks who implement Modbus in embedded systems take all kinds of liberties in bit significance and byte order. Datatype is not explicit in Modbus function codes. And even if it is, there's no reason for byte order to be the same inside an A-B controller as it is inside a Modicon controller. Since your HMI application wants to read A-B datatypes, you're going to have to give it what it wants. For your application, if the data is coming over the Modbus RTU connection encoded as IEEE 754 single-precision floating point values but being stored in A-B integer data files, you need to use the COP instruction to copy the data bit-by-bit into an A-B Floating Point data file. You can then read that Floating-Point data file with your display system. For example, if you have three 32-bit IEEE 754 single-precision floating point values stored in the MicroLogix 1100 in Integer data elements N10:0-5 (six 16-bit registers), you use the COP instruction as follows: COP Src: N10:0 Dst: F8:0 Len: 3 If the data in the Modbus registers you've read into the Integer registers is in the appropriate byte order, you'll see the values you expect. If it's not, you need to swap the bytes or swap the words. If you can post the actual values in your Integer data file, and what values those are expected to represent, that will help.

I had something like that happen with a version 1.03 PanelView 550 a couple of years ago, with PanelBuilder 3.71, I think. Are the graphics turned upside down ? That's what happened to mine. Because the terminal I had was non-upgradeable, I just left the graphics as-is and lived with it. I later learned from A-B that those old terminals had an upload problem with bitmaps, and that the only thing for it was to have the original file or to process the bitmaps to turn them over. Since those terminals are critical, you ought to have an upgrade plan. The 900's aren't being built anymore; probably the safest thing is to have PV1000 Standards on hand.

First get your polled tags working, before you start attempting Unsolicited data transfer (the MSG instructions in the controller). If the Applicom program is using PLC-5 type addressing (like N10:0 and so forth), you must define ControlLogix array tags that have PLC-5 style Data File numbers. In RSLogix 5000, you do this in the Logic -> Map PLC/SLC Messages menu function. If the Applicom program is using ControlLogix-style tags then yes, you should be able to browse tag names. Very likely you will have to configure Applicom to tell it which IP address your 1756-ENBT module is using, and which slot your controller is in. Have you run this by Applicom's technical support yet ?

From the A-B website for MicroLogix 1500: There is a MicroLogix I/O estimator tool available on that website (www.ab.com/micrologix) as well. Bob has a good point for going from PLC-2 to ControlLogix. There are quite a few migration possibilities from PLC-2 to PLC-5, SLC-500, or ControlLogix. I think I'd probably "aim low" and buy a SLC-5/03 controller with a 1747-SN RIO scanner, as well as a 1771-ASB adapter for the existing I/O chassis. Justify the extra money for the scanner/adapter pair by showing that you don't have to remove and re-wire the 11 I/O modules.

Customers: "I don't want to buy that 1761-NET-AIC module anymore; you need to build an isolated RS485 port into the next MicroLogix" Rockwell: "Well, OK, but we're either going to have to use a totally custom connector, or eliminate hardware handshaking and the +24VDC accessory power pin" Customers: "Use the same connector. We don't need the 24VDC accessory power because the new MicroLogix will have built-in RS485 and Ethernet, so the only accessory that you need power for is the 1761-NET-DNI and that's not as popular as the other two." Rockwell: "We can do that. You can still use the good old 1761-CBL-PM02 cable that we've been selling for fourteen years to do RS232 connections. And the shell will be the same as all the other MicroLogix. But you're going to need a breakout box type connector to bring the RS485 pins out to screw connectors." Customers: "That sounds really easy and straightforward. What's the catch ?" Rockwell: "We're not going to put the pinout in the installation brochure or in the User Manual. You know the drill."

The MicroLogix 1100 has both RS232 and RS485 signals on its Channel 0 serial port, so you'll want to be persistent enough to find the correct pinout. Take the time to set up an account at support.rockwellautomation.com and look up Knowledgebase Answer ID # 38808. Or just search on the keywords "MicroLogix 1100 pinout". Or you could just buy the proper cable. I like not having to fiddle around with tiny pins or worrying about my strain relief; I'm trying to automate a system, not save forty bucks.

The MVI56-MCM can't be owned by more than one controller, so you cannot natively have two controllers reading its database. However, it is very straightforward to copy the module's database registers into a Produced Tag in the owner controller, and have that tag (it will be an array of INT values, probably) be Consumed by the other controller.

Rockwell uses a utility called ControlFlash to update these modules, and it utilizes the same RSLinx drivers that you use for other access to RA controllers. So you need both those software packages. The ControlFlash kits with module firmware are part of the Rockwell "Tech Connect" subscription, which gives you an authorization number for technical support and firmware downloads for the main product families. support.rockwellautomation.com is the main login page. Log in, navigate to firmware updates, and download the firmware kit for the 1756-ENBT.

Most A-B sales offices or distributors will help you get your hands on small obsolete utilities like this if they can also show you the newest products in that category to eventually replace it. Do you need help finding your A-B sales office or distributor ?

What model of controller are you using ? Although you put this post in the Allen-Bradley section and mentioned a PLC/SLC style address, you did not mention which controller. Program memory cannot be 'consumed on the fly', in the sense that it gets allocated to a no-longer-functioning routine. Controllers are much more careful with their memory than multipurpose computer operating systems. Nor can memory 'degrade over time'. Most controllers run a checksum on their program memory every single execution of the program, which detects defective memory immediately and shuts down the controller. Noise problems are going to show up on the communication ports usually when they are also affecting the controller. There's no acceptable level of memory failure, so any damage at all will fault the controller.

If you happen to have a DH485-network PanelView Standard terminal, there are functions that allow you to put the controller into RUN or PROG modes and I think also to clear faults. Look in PanelBuilder Help for exactly how to do this.

RSLogix 5000 only includes the ladder editor in the Standard edition. The other editors (FBD, SFC, and ST) are available individually or as a bundle, the most popular of which is RSLogix 5000 Professional. http://www.rockwellautomation.com/rockwell...deringinfo.html

Prosoft Technology includes sample programs for configuring and operating their modules with Allen-Bradley controllers. This includes clear explanations of the module database, Modbus addressing of that database, and programming of block transfer instructions to configure the module and to exchange data with the controller. Start there. http://www.psft.com/content/view/full/3080

I worked on one, let's see.... seven years ago, that's the most recent, and I was depending on some dusty manuals and the memory of someone in Tech Support named Rhonda. I think A-B stopped making these modules fifteen years ago or so. Since these modules were principally used for ASCII interfaces, there are far smaller, cheaper, faster, and easier-to-use modules for modern platforms and for classic PLC-2 and PLC-5 controllers. I'd say that's the opposite of "beta testing". So thanks, gravitar, for contributing to the historical knowledge on these. I am also amazed that you can buy a 2760-RB module today.... are you sure you didn't get it as a "custom classic" or from a third party rebuilder ?

If AMCI can't provide one, there's likely not one available anywhere. I imagine that the module shows up as Unknown in an RSLinx browse of the Logix backplane, with a yellow question mark. Is that the level of annoyance, or is there something else ? Right-click on the module in RSWho and select Device Properties to see if you can post the Vendor, Type, and revision information. You could probably make an EDS Stub of your own from that.

I think that building on the existing code, especially if it runs the machine correctly, is the way to go. 140 rungs is not that large a program in my humble opinion. Your first asset is that this is a small system with a small number of I/O, so tracing out (or using a wiring diagram) and labelling the physical Input and Output bits and words will provide a very good start. If you can reverse the RSView ME runtime file into a project file, you can label a lot of data display and data entry elements (integer and floating point and bit memory locations) because you will know the function of the screen objects to which they are linked. There have been threads on this and other forums about how to rebuild RSView ME project files from runtime files.

The resolution, data format, data range, and other specifications for the 1746-FIO4V module are all in the User Manual, downloadble from the Rockwell Automation literature website. http://literature.rockwellautomation.com/i...in008_-en-p.pdf This manual covers all the Fast, combination, and standard Input and Output analog modules for the SLC-500 series controllers. You can get a hardcopy from any Rockwell distributor.

The *.ACH file extension was used for several different A-B programming packages for the SLC-500 an various PLC-2/3/5 families. RSLogix 500 will open *.ACH files that were created by APS programming software for SLC's, for example. Which edition of RSLogix (500, 5, 5000 ?) are you using, and do you konw which type of controller the program is for ?

The fact that the EtherNet/IP connection is working well for PV+ downloads tells us that you have an IP address for your computer that is on the same IP subnet as the PV+ terminals, and presumably also on the same subnet as the 1756-ENBT module. Still, it can't hurt to make sure using PING that you can access each device with Ethernet cables and TCP/IP protocol before you start with RSLinx. The PV+ terminals use the EtherNet/IP driver in RSLinx Enterprise (linked closely with RSView Studio). RSLogix 5000 uses the EtherNet/IP driver in RSLinx Classic (where you configured that DF1 driver). There are two Ethernet drivers available in RSLinx Classic. The older "Ethernet Devices" driver requires that you enter the IP addresses you want to browse into a table of Station/Host Addresses. The newer EtherNet/IP driver will browse the local subnet for Rockwell devices, but it's easily defeated by firewall or VPN software. I hook up to a different system every day using EtherNet/IP, so I know it's pretty easy once you get the fundamentals down. Post what you've tried, and exactly what you see in RSLinx and RSLogix, and you'll certainly get there.