Joe E.

If your HMI won't support tag-based addressing, you have to make the Control/CompactLogix talk like a SLC/PLC. In your RSLogix 5000 project, go to Logic->Map PLC/SLC Messages... To connect to the N7 register, for instance, you would set the file number to 7 and assign it a controller tag that's an INT array. The HMI should talk to those tags as though it were talking to the N7 registers of a SLC. I had to do this recently to connect a 1756-L55 to a PanelView 300 Micro.

You probably want to use EITHER N7 registers OR counters to keep track of elapsed time. Both will work with the correct coding. At a quick glance, I see that when the day rolls over (hours = 24) you write 0 to the hours N7 register but don't reset the hour counter. This means that your hours counter goes to 25 at the end of the next hour and you will never again increment the day since it will never again equal 24. It's a bit more robust to use a GEQ instead of EQU here, but you still want to choose either counters or integers. The counters are probably simpler to use in the code. If you need the information to live in integer files as well (maybe for an HMI that can't address counter accumulators), then I would just copy the counter.acc registers to N7 registers every scan. That way you only need to reset the counters. Make sense?

I opened the program in SLC Logistics, and it doesn't look right. All it displays is "SLC-100 END 885" "SLC-150 END 1200" (see attached screen shot) This may not be the correct software to use, or I may be doing something wrong (I'm not experienced at all with these things).

In "later" versions (after 13, at least as far back as 18), you can go to Tools -> Options -> Ladder Editor -> Display and check the "Show Input Operands on Left; Output Operands on Right" option.

I've never used the emulator since I generally have the physical device on the table in front of me. I just tried it on an existing project and it worked fine. May be a dumb question, but do you have the PLC set up under "Communications" in the navigation pane?

When I need a serial port, I start with the USB unit, just because it's handy. I usually have my laptop in a docking station which plugs into the same connector as the legacy port extender. When I need to go out on the floor, I just undock the laptop and grab my handful of cables, including the serial adapter if necessary. In my experience ,the devices that won't talk to the Keyspan adapter also won't talk to the port extender, so I usually don't bother with it. Not sure if it's a hardware issue or an OS issue. Probably hardware since other computers running XP SP3 with native COM ports seem to work mostly OK. I keep the extender in the drawer just in case, though. My computer is running XP Pro SP3. I had 7 on my home computer for a while but never used XP mode. My understanding is that it's a sort of virtualization environment, but I could be way off on that. If I were you, I would seriously consider the use of virtual machines if you have an XP license you can use. So far, it's been a clean, easy solution for me. For example, when RSView decides to get froggy, I can just erase the VM and restore the original from the archive. Hard to do that with a native install.

I have one of these for my company laptop. Be advised that, on my machine at least, it does NOT appear to function as a native COM port, so any devices that won't work with virtual COM ports will also not work with this. Which OS to choose will really depend on which programming software programs you need to run. For instance, if you're using RSView Studio (or its newer name FactoryTalk View Studio), you'll need to use version 6.1 if you go with Windows 7. XP will work with up to 6.0 (according to our vendor. We're still using 4.0). There should be a matrix somewhere on AB's website that shows which OS you need for which version of which software. I think that will drive your OS selection.

It's been a while since I played with VirtualBox. I don't remember having any trouble getting the Keyspan adapter to work. Make sure you've installed VirtualBox Guest Additions. This helps integrate the VM with the host OS. Just as a test, have you tried connecting a USB flash drive to the VM?

The DE9 connector is fairly typical, in my experience. We use this one: https://support.automation.siemens.com/US/llisapi.dll?func=cslib.csinfo〈=en&objid=6ES7972-0BB60-0XA0&caller=view We have a machine that has adapters to go from the DE9 to a round connector that is at least similar to what Tom749 posted.

For this, I generally set the VM's LAN connection to "Bridged". It will have its own IP address at that point, so you need to be careful not to step on your host machine. You will need to select the VMware LAN adapter from the list under "Set PG/PC Interface" in Simatic Manager. I also have to disable the Symantec Endpoint protection, since corporate IT has locked out the settings and I can't add an exception. YMMV. By the way, I'm running from memory here. The computer that's set up to do this is not terribly convenient at the moment.

I've never done it on that particular model, but have with some old AB units. I think the hard part would be locating replacement relays. If you open up the controller you should be able to get numbers off of the existing relays and then practice your Google-fu to find their specs and then find a replacement. I would expect the relays to be thru-hole components, which makes them a little more straightforward to replace. As for whether it's practical or not, what's your time worth? What does it cost to send it out for repair?

I thought about this some more and tweaked now it's going to work a little. Since there's only one 24vdc PS, the inputs can be segregated without any trouble. If I turn off power to one of the machines, the input module really doesn't care that the field devices are de-energized. Interestingly, it runs fine with only one 24v power connection, but needs 2 0v connections. The 1794-OB16P, however, cannot be easily separated. There is only one power connection that supplies both the module itself and the outputs. This isn't 100% clear from reading the datasheet, but that's how it appears to be working.

I'm using a 1794-IB32 plugged into a -TB32 terminal block. According to the data sheet (and the AB IO wiring diagram book), it looks like I can split the inputs into 2 groups of 16 each. It shows connecting +V1 to pins 35, 37, 39, and 41 and COM1 to 36, 38, 40, and 42 for the Inputs 0-15. There's a similar arrangement for inputs 16-31. I'm willing to experiment a little but don't want to break anything. Is it OK to split the inputs further into groups of 8 with different supplies for 0-7 and 8-15? I would "assume" (yeah, I know) that pins 35-38 are associated with inputs 0-7. Will I damage anything if I power up only pins 35 and 37 without powering pins 39 and 41?

We actually have an executable "EVMOVECF.EXE", provided by either AB or our distributor (it's been a lot of years and I don't remember which). It resides on the USB flash drive and is run from there. It works fine for moving licenses around. A quick Google search turns it up here: http://www.rockwellsoftware.com/support/download/detail.cfm?ID=3428 (I have NOT tested that download link)

Also, be aware that the software will only update from the cursor down. If you select an instruction in the middle of the network, the stuff before it won't be updated. Click on the network number and it should update the entire network.

The License key shows up in the "removable devices" list in VMware Player. When I tell it to "connect - disconnect from host", it disconnects from the host, but doesn't connect to the guest. No errors, just no connection. As mentioned, other USB devices work fine. I ended up doing an "Offline transfer". It took a few steps and I had to type in a long alphanumeric key, but it worked and I was able to use the software normally.

Alright, I'm setting up a new laptop for our maintenance guys (Panasonic Toughbook). It has Win XP Pro SP3 (with a bunch of corporate IT junk) as its native OS. I've created a clean VMware VM running a clean XP Pro SP3 install. I'm using VMware Player v3.1.4 build-385536. On one copy of the VM, I have successfully installed RSLogix/RSLinx and have done some preliminary testing getting online through Ethernet/IP and our 1784-U2DHP adapter. I'm not finished testing it, but we need a good Siemens install more than another good AB install, so I made another copy of the original, clean VM. The Simatic Manager (v5.5, SP1) software installed flawlessly, but I can't seem to get the License transferred. VMware sees the USB License key in the native OS and tries to connect it to the VM, but it won't go. I get the bubble in the native OS saying that it's safe to remove (just like when I connect a regular USB flash drive to the VM) but the device never appears in the VM and never shows as "connected". A standard USB flash drive connects and disconnects just fine. I used another computer to move the license from the license key stick to a standard USB flash drive, which went fine. Now, when I connect the standard USB flash drive (that worked fine before), it appears to the host OS like it's the license key stick and the same problem occurs (VMware can't connect it to the VM). I installed just the Automation License Manager on the host OS to see if it would bring a driver for the license key with it, but nothing changed. I have poked around a little with the network transfer part, but didn't get very far. Even though it's bridged and gets a good IP address automatically, ALM in the guest OS can't find any other computers when browsing. The native OS can, but I don't really know what to do from there. I'm not a networking guru, so I don't want to poke around too much and risk breaking something. I wouldn't think it's really needed anyway. I then dug out an old yellow floppy disk with a license for Step 7-Basis v5.3. My laptop was able nicely to transfer the license from the USB key to the floppy disk (using a USB floppy drive), but I was unable to get the new VM to see the floppy drive. I actually suspect problems with the native OS since it took a couple of tries to make it show up. Even when it was there, VMware couldn't see it so couldn't connect it to the VM. Has anyone here successfully made this work? I really like the idea of using VMs to make software maintenance easier, but if it doesn't do much good if I can't activate the software. About all I got from Siemens tech support was that it "should work OK", but that they don't support virtual machines. Basically, we're on our own. By the way, I'll also need to transfer a license for WinCC Flex and maybe S7-Technology.

I want to repeat and emphasize what Ken R. said about limit checking. It is critical and can save you some weird troubles down the line. We had a machine that had been running "fine" for years. Well over a decade without this problem. One day, the operator went to the setup screen on the HMI and the PLC faulted. It was repeatable, that all was well until they selected the setup screen, then it would fault. They were calling a recipe selection subroutine when the HMI went to that screen and that subroutine contained an indirect address. It somehow magically got changed to a value that pointed to a non-existent data file, which faulted the processor. We added a limit check just before that line of code and all was well.

I second that motion. Your AB stuff *should* be OK on Win7, unless you need a PIC driver. That won't even work on XP SP3. A Virtual Machine won't help either, since it's the native OS's serial drivers that matter. The 1747-UIC works nicely over USB, though. I'm just starting to get set up with virtual machines and would strongly recommend you do the same, especially for the RSView stuff. I've had the software die in really weird ways where it couldn't be resurrected (or uninstalled, or reinstalled). A VM solves that problem handily. Whatever route you take, maximize the RAM, especially if you decide to use VMs. Win XP won't map above 3GB, and some of that will be taken up with memory-mapped hardware, so if you want to do VMs, you might seriously consider Win7 as your native OS.

I'm also not a fan at all. I just need to program touch screens, no fancy SCADA. I don't need to run Windows on my operator interfaces. I just need a touch-screen HMI. The RSView/FTView software (along with price, of course) is a large part of why I won't buy any more PV+ HMIs. The only time I will remotely consider the possibility is if I can't find a way around connecting a screen via DH+. And even then, we're looking at other alternatives.

If you don't want to monkey with your windows drivers, you can use Rockwell's 1747-UIC USB to DH485 interface converter. You'll also need cable 1747-C13. The two combined is 1747-UICC13 and cost us about $300 from our distributor (your price may vary). It's not bad to set up and use and has good instructions with it. We've used it to successfully communicate with SLC 5/03s, fixed SLC500s, and a PV with no problems at all. We're using XP Pro, SP3.

You might also consider the MicroLogix 800 line. I'll echo Bob and suggest 24VDC for controlling relays that control the actual loads.

The G3 should support bit addressing. Which version of the software are you using?

I've never used Labview myself, though many of my classmates did as part of their intro to engineering class (we used Matlab). We do have a fair amount of Labview stuff running, though. Some are just HMI and SCADA type applications. Others manage our machine vision and gauging systems (PLC gives them a "go" trigger and waits for a "good" or "bad" signal). At a previous employer (they manufactured BLDC motors and amplifiers), I worked with LabWindows CVI from the same folks as LabView (NI). It uses a lot of the same drivers, but you write code in C. I didn't have too much trouble getting sequential stuff to happen.

Also, you don't need to buy the paid version of VMWare Workstation. The free VMWare Player will let you create a new virtual machine and install your OS on it. You just need the OS install media and license.