Joe E.

OK, as for computer hardware, I haven't encountered anything that RSLogix 500/5000 talks to that I needed a native COM port. Allen Bradley's USB adapters 1747-UIC and 1747-U2DHP work for DH-485 (I think 9600 baud only) and DH+, respectively. I have also tinkered with an "aftermarket" version of the 1747-UIC from INDUSTRIAL CONCEPTS that doesn't have the baud rate limitations that AB's cable has, though I haven't tested it extensively. Keyspan's USA-19HS (available from Amazon) works for serial communications with the newer equipment. I think OS compatibility will be your biggest complication. If you need a software package that won't work under Win7, try VMWare Player to create a Virtual Machine using one of your XP licenses. To check OS compatibility, go here: MULTI-PRODUCT COMPARE. In the first 2 combo boxes, select "Software", type in "RSLogix" into the 3rd combo box and click "Go". Then, click on RSLogix 500, then select the version you have. Do the same for RSLogix 5000. It should then give you a compatibility matrix showing which version works with which OS. Don't take this as absolute gospel, since some folks have had good luck running older software on Win7 even though it's not "officially" supported. Your biggest compatibility problem will probably come if you get a 64-bit OS and have to run any earlier versions of RSLogix/RSLinx. You're probably going to be forced into WIn7 (at least) if you buy a new laptop, and XP is losing support updates this year, so I would recommend 64-bit Win7 with LOTS of RAM so you can run 32-bit XP inside VMWare easily.

There are other threads discussing laptop choice. As for the RSLogix 500, be aware that you can recover the license if the PC is dead. AB's support site can help you out with that. You may also contact your local distributor for assistance (you'll need to if you want to buy the software anyway).

The only other possibility I can think of right off is if there is some kind of power-up behavior you're trying to control. The help file in RSLogix 5000 states that the DN bit is cleared during the pre-scan, which is also what I would expect if you used the DN bit to control another address, so I'm not sure what the difference might be (if any).

If your display doesn't support the Long data type, you can use 2 integers. Add 1 to the less significant as suggested above. If the less significant is bigger than, say, 9,999, then add 1 to the more significant and set the less significant to zero. To avoid weird screen updates, you may have to move both registers to other addresses that are then displayed on the HMI. You would put the numeric displays on the HMI screen side-by-side with the visibility for the more significant set so it only displays when it's >0. A little cumbersome, but works as long as you only want to display and don't need to do any calculations with it.

It looks like you've created a tag called "Date_Time" of type "Date_Time". This is fine. When you want to read the hour, you would write "Date_Time.Hour". ETA: Oops. Already posted. Oh, well...

Have you tried the manuals listed on Honeywell's site?

Our system is even messier than yours, since we have 4 people with personal network access who work with the backups and an additional 6 or 8 who work with the machines, all using 7 or 8 computers, only 4 of which have access to the corporate LAN where we store the backups. It is an out-of-control disaster that I've been trying without success to get a handle on for 2 years now. It would be simpler if we could get wireless network access for the maintenance laptops on the floor, but we haven't been able to get the IS part working reliably enough.

For wiring and pin identification, see THIS MANUAL

https://rockwellautomation.custhelp.com/app/answers/detail/a_id/45249 Requires Techconnect.

I'm pretty sure you're out of luck, unless you can find another archive that has the correct code.

I have an admin account on the laptop (have to so I can even install the PLC software) but corporate IT folks have a bunch of stuff locked down, the Symantec software and user login administration among them. So far I've been mostly able to work around it, though it's very irritating at times.

I've never been able to get the software to see active Ethernet nodes, either factory defaults or ones with IP addresses already set. With the tool built in to Simatic Manager or PST. Actually, PST says that the ISO protocol isn't installed on the NIC, even though it is. The tool in Simatic Manager just comes up blank. Siemens tech support thinks it's a problem with my firewall/antivirus software, which I can't control on this company laptop. It looks like we'll have to keep the PC Adapter on hand for initial configurations.

I've only set up 2 processors new out of the box and I used a PC adapter through the Profibus port. The starter kits we bought came with a cable that (I think) can be used for initial commissioning. The CPU may come configured for DHCP or BOOTP. I don't have the manual handy to try to figure it out. ETA: on ours, either cable works. The ports are "smart" and configure themselves accordingly.

I *think* that the trial is for a week or two, so experiment fast!

Is anything else talking to the PLC through that ENBT besides the HMIs? If not, I see 2 ways to do this without causing issues: 1) Take a compatible spare off the shelf, configure it, and then swap them. This will involve the least time yelling and swearing with the cabinet open ;) 2) You could use the BOOT/P utility and just unplug the module from the chassis to reboot it as needed. For either method, you should check in the PLC project to make sure that the ENBT isn't configured to fault the processor in case of failure (probably isn't if it's just servicing HMIs and the programming PC) If the ENBT is in the project, you can change the IP address there, but I'm pretty sure you have to do it offline and download, which stops the PLC.

Don't hold back, Bob. Tell us all what you REALLY think! ;)

I have used one of these: http://www.ibhsoftec.com/epages/63444704.sf/en_GB/?ObjectPath=/Shops/63444704/Products/20266 The device itself keeps its IP address, so you can move it from machine to machine with no problems if you're using it for programming. For a Red Lion HMI, I just tell it that it's talking to an S7-300 over Ethernet and give it the IP address of the IBH unit. In Simatic Manager, it's a little more complicated since you have to set the PG/PC interface to the correct IBH driver, but that also works reasonably well for me. It's less seamless than adding an Ethernet port, but it's also cheaper. Since we only have a few S7-300s that don't have built in Ethernet, I'm probably going to end up getting Ethernet expansion cards for them since they're a lot simpler for the maintenance guys to deal with at 3AM.

:D I plan to attend. Our distributor put together a travel package that's pretty reasonable. I just have to push a PO through our system...

Sorry, I didn't catch that detail. There are some devices that just will not work with the Ethernet/IP driver. You have to use the Ethernet Devices driver. Not sure if a firmware update will help or not. You might try contacting your distributor for help on that.

This will sound weird, but I've had a similar situation before apparently caused by a bad cable. The PLC showed up in RSLinx when I used a different cable.

You should be able to just set your computer's LAN card to the same subnet. Then select the TCP/IP driver under "Options -> Set PG/PC Interface" that corresponds to your LAN card. You should be good to go. If it doesn't work, try to ping the PLC from a command prompt. If it doesn't reply, you have a LAN settings issue.

What did you replace the PV/PV+/PFlex with? That may help narrow down your choices.

The autoconfigure function *should* take care of that for you, if it recognizes the device. For the MicroLogix, it should end up on "SLC-CH0/Micro/PanelView".

If you use Visual Studio, try Advanced HMI. They have DF1, Ethernet/IP, and other drivers.

If you want to get fancier and write directly to registers in the PLC without having the PLC parse strings, you might try implementing their DF1 protocol directly: http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1770-rm516_-en-p.pdf