kaiser_will

If you can host an application on a PC with continuous connection to your application, you can create an OPC topic in RSLinx; then you can create an Excel macro that communicates with this OPC topic, and now any datapoint in the PLC is fair game to be pulled into the Excel spreadsheet. This will require a premium RSLinx license, though (LinxLite will not suffice), that supports OPC and DDE. If you know your way around VB coding, you can build a poor-man's HMI in Excel to view data directly from the PLC. If you wish to archive data from the PLC, WebDock has a free datalogging package that will trend somewhere like 150 datapoints. The downside with the free download is that you are limited to the Delta-T (time duration between data records...1sec, 1min, 1hour if I remember correctly).

For Ethernet connectivity, it is always a good idea to make sure your PC can talk directly to the PLC. 1. Open a DOS command shell (Start, Run, "cmd", <Enter>) 2. With your PC cabled into the PLC, type "ping " IP address of the PLC, <Enter> 3. The latency time should be echoed back for how long it took for the Ping packets to be sent and received; if your computer comes back and tells you that all the packet send requests timed out, then your PC is not able to communicate with the PLC. Often times, I have found this test to be very helpful when PC and PLC do not want to talk together. If your PC cannot communicate with your PLC: 1. Verify you have the proper Ethernet cable (Ethernet PATCH cable for PC to Ethernet switch; Ethernet CROSSOVER cable for PC direct to PLC) and it works (take the cable to another PC-PC or PC-Device application and make sure the cable is good) 2. Verify your PC Ethernet port is configured properly (Start, Settings, Network Connections, select the port, Internet Protocol [TCP/IP]). You could be trying to use a PC Ethernet port address that is not capable of talking directly to the PLC Ethernet/IP address. Attached is a primer I wrote some time ago to bring everyone up to speed on Ethernet/TCP-IP/yadda-yadda.Primer___Ethernet_and_Ethernet_IP.doc

PLC platform and software selection should be compared based on a few simple criteria; 1. Initial Cost (breakdown into cost per I/O point including development software to get an apples-to-apples comparison) 2. Support (local, phone/chat, availability) 3. Platform longevity (how long is the product line expected to be available) 4. Application history (have you any experience with this platform) 5. Hardware availability (delivery time - this is becoming a big issue as many companies are trying to reduce inventory to control costs) One may find that experimenting with a different PLC platform often leads to new issues not initially considered. Such as attempting to reduce initial hardware costs but having to deal with greater unplanned downtime. I still firmly believe a great control system platform is contingent on local and factory support. Reach out to users in your area to find out the key players and the benefits of the control system/software they use. Likewise, ask the question "what DON'T you like about your current control system/software solution". I personally think the Japanese-based controllers all have very, very simliar software and hardware (Omron, Panasonic, Mitsubishi, Keyence). Their costs are fairly competitive and their software solutions very similar in function, cost and support.

Have you looked at flashing the firmware of the devices that are on the DH-485 network? Their firmware may have been fine for the dated PIC interface, but not for the newer AIC interface. I seem to remember a simliar scenario some years ago.

Try to download RSLinxLite. If you are using a premium RSLinx (OEM, Gateway, etc.), I believe the LinxLite download will work and your installed license will unlock the features you use. LinkLite does not require a serial number to download, they just ask your name to keep track in their database. I have run into this before and found the issue to be related to the Operating System in that WindowsXP wanted to use a different IRQ (interrupt) everytime a USB device is installed. There is a way to force the IRQ for your UIC converter so that the operating system and RSLinx always expect the same IRQ.

Mickey has a point. The UDC controllers may be adjusting the signal. Gather data to verify. The Honeywell UDC3500 controllers are acting solely as signal converters and damper controllers, and the KFM controller is the master with the PID control. Does the KFM controller support dual/multiple PID loops with separate outputs? If the 2 dampers are to run independantly of each other, then they should probably have isolated PID control loops (i.e., be driven by separate controllers - such as the UDC3500). I have no experience with the KFM controller. What steps have you gone through to tune the master PID control loop? If you have the time, it may be beneficial to gather some empirical field data with the goal of tuning the loop. In the past, I have worked through similar scenarios by temporarily rigging a PLC in place of the master controller, and using a PLC data collection package (WebDock is a freebie) to build a spreadsheet of data (date, time, PID overshoot, PID error, output values, etc.). If a PLC swap is not in the cards, you may be able to program additional controller outputs to give you what you want and use a PLC to act as the data gateway.

Does the HMI have to be a Plus? Going with a classic PanelView (and using PanelBuilder32) is an option. Also consider used/refurbished/surplus HMIs. There are a number of surplus controls distributors out there (I believe some advertise here). I initially came into contact with some of them through Ebay. They offer a similar Allen-Bradley warranty (1 year parts and labor). Dig into the risks and the cost differences and at least you have an option for cost control. If you want to stray away from a PV+, then the question to answer is communication protocol. Ethernet/IP, DF1, DH+, etc. Communication protocol will dictate what options for PV+ replacement. I have had integration success with GE Fanuc QuickPanel HMIs. Their cost and availability trumps most A-B offerings. The downside of straying from a PV+ solution is losing Logix tag-based integration. Depending on the number of screens and tags, tag-based Logix really cuts down a ton of integration time on my end.

First, was this system working reliably or is this a startup? If it was working reliably, something may have changed in the system that has uncovered the instability of the PID loop. Do a search for PID Loop Literature to get a better understanding of the parts of a PID loop and how their values can affect the outcome. Making PLC code changes to deal with an overactive PID loop only adds complexity to the problem. Can you put the slidewire on a meter and exercise it full span? I am guessing the slidewire has a deadspot (or two) where the impedance is changing non-linearly, which leads to the PID controller wanting a large change. I have run into this very problem before. A typical averaging multimeter may not fully reflect a deadspot, but an oscilloscope will. Honeywell typically has local support engineers (if you have a support contract) that are of great support in dialing a controller's application. What model of UDC are you using?

Thank you very much for the info. I will integrate reset into the PLC/HMI applications.

Is there a way to setup PowerFlex4 and PowerFlex40 AC drives for reset when they communicate via DeviceNet? Since these drives have only power in, power out and DeviceNet, there are no hard connections for reset. If any of the drives fault, the customer has to cycle system power (or at least drive power and comms power, allowing time for the drives to bleed off before powering up). The application is for a pallet conveyor system, and faults occur often due to overloading or banged up pallets. If the drive trip points are stretched out (to reduce nuisance trips), then mechanical failures occur (nuisance downtime). I believe the discrete I/O board is lost when adding the 22-COMM-D DeviceNet interface board, so the discrete programmable reset feature is also lost.

Starting up a new CompactLogix system with a L43 CPU (DF1 only). Get online via RSLinx, connect up, go to download the PLC program as usual with a startup, give RSLinx permission to update the CPU firmware, head off to lunch. Come back to expect to see the rack rebooted and ready to go online and set the IP address of the Ethernet card, but found the CPU DF1 port dead. Kaputt. No go. Apparently, the L4X CPUs can be rendered useless if you use RSLogix/RSLinx to update the firmware and do not use ControlFlash with ver. 16.23. A-B says there is no way around this other than to get a replacement CPU. Uggh!

To a first-time A-B controls customer, many can be caught off-guard when the find out the programming/development software is much more than another manufacturer. Likewise, the same customer will not like that they must purchase an annual support contract to get their questions answered or to get software updates. However, on the subject of software, this is how companies such as Microsoft have been doing business for years with acceptance. Customers expect their support contract funds to be invested by A-B into reliable software, new value-added features, and reliable/accessible technical support. I have been in the situation where a customer makes a long-term decision to migrate to another brand with cheaper (or free) software and cheaper (or non-existent) support contracts. Often, the end result is sporadic or ineffective technical support and programming tools that are light years behind Allen-Bradley. End result is the marginal annual expensed or capitalized savings seldom cover the in unplanned downtime costs. Sure, Allen-Bradley is chock-full of software or hardware quirks. But after working with a plethora of controls platforms for ~ 20 years, most (if not all) controls platforms have their own inherent quirks (or rules of use). You might want to pursue conducting a cost-of-ownership analysis to compare Allen-Bradley to others. Or consider alternative methods for reducing your system costs (such as purchasing refurbished PLCs...typically 50% of list). Suggestions: 1. For supporting maintenance technicians, I develop and instruct our own training classes with content and labs specifically aimed at their job functions. Too many 3-5 day classes have only 25% of content specific for typical customer job requirements (but the A-B offered classes cover many customer segments). => Build your own training classes in bite-size nuggets (getting online, testing communications, program version control, etc.) 2. Inline with the custom classes, I also wrote work specific work instructions (aimed at maintenance techs and project engineers) and set them up for all to get easy access to. Instructions such as setting up a PIC box, configuring a DF1 driver, going online through Ethernet, etc. 3. Cables, cables, cables. The old way was to purchase 1 cable, then hunt for the sucker whenever you needed. The new way was to purchase a set of cables for each maintenance crew (4 crews total) with the leadman in charge of the set. Everyone has the same set, in a nice bag with their laptop. Engineers sign out cables or their manager has to purchase their own. 4. Who moved my shortcut? Every maintenance shift was dinking around with the programming computers to their liking, but peeving the other shifts. We purchased one programming computer for each shift, with the leadman being responsible. They all have the same hardware and software, so all I had to do was setup one computer and ghost its drive image for the other 3. HINT: Panasonic Toughbooks, as well as some other brands, still offer portables with real serial ports. 5. What the heck is this? Engineering was allowing vendors to put anything they wanted in a new panel. A recent audit revealed we had 15+ DC motor drive platforms to support. In working with engineering, we came to narrow that list down and put into purchase specifications for future equipment orders. Work with your customers, internal or external, to make sure they understand your struggles.

Comment: FYI - The original I/O card layout in the racks is psuedo-double-slot addressing. It appears the original rack builder was versed in the old double-slot addressing days from the PLC-2, in which I/O cards were arranged in groups (Rack/Group/Slot). I believe it is only an asthetic detail in SLCs and PLC-5s. Question: Your customer has requested to upgrade processors to ControlLogix and convert the communication protocol to Ethernet-based, but what is the business justification? Data Highway is a solid communication protocol, and SLCs/PLC-5s are in the middle of their obsolescence plan. I have seen customers take the bait from sales guys telling them their hardware is obsolete, yet A-B implements very long-term obsolescence plans. For future installs, I can understand the desire to go to an open-fieldbus based communication protocol with a CompactLogix or ControlLogix CPU, but I see no deliverable in capitalizing the upgrade on existing, running production lines. Step back and ask WHY five times to build the business case for the customer's request.

RSLinxEnterprise was developed for RSViewME applications and does not support being an OPC Server. You will have to add RSLinxGateway to make this happen. You may want to look at a 3rd party OPC server, such as KEPWare. Thread on RSLinxEnterprise, RSLinx, and RSLinxGateway... http://forums.mrplc.com/index.php?showtopic=8558

You could just pull the alarm number from the PLC, store the alarm description in the HMI and pull the date/time from the HMI. The last piece of the pie is to chain the PLC date/time to the HMI. If it is a PanelViewPlus HMI, you can use a macro application with a global connection.

I will chime in with my 2 cents. I would go with Beckhoff I/O, talking Ethernet/IP to a CompactLogix CPU. If you have any pneumatic or valving outputs, Ethernet/IP to a Festo rack. Heck, you can run all of your I/O from a single Festo rack (pending I/O count).

I am with PLCMentor...check your grounding. Even though you have UPS's on the PLC power supplies, there could be something funky happening on your power delivery/grounding. Ground impedance changing instantly can wreak havoc on high-speed digital circuits. Is this control network tied to the company network? Could the IT group have made changes about the time this started? Have you looked at segmenting out the Ethernet comms to limit the broadcast traffic? Programming routing tables in managed switches to control comms traffic? Have you run WireShark to gather statistics on Ethernet comms? In a nutshell, when a system has been running then starts to sputter, my money is always on answering the starting question "what changed to my process?". Either the setup was perfect, before the root-cause incident, or the setup was doomed to fail once it was loaded beyond a certain point.

Since you are pouring a lot of time and effort into resolving this issue with no smoking gun, yet, I suggest you step back and break the problem up into pieces. Verify there is not anything going on in your power. If you have a Dranetz, put it to use. If you do not own one, your department can expense a rental for 30 days for a few bucks. I was backup controls engineer on multi-million dollar project. After commissioning, we had intermittent loss of annealing for many loads that had to be scrapped at $0.5M/load (very costly). The root-cause (2 months later) was found to be a noisy sump pump (its startup noise injected enough ripple into the main controller power supply to cause it to intermittently stop). With more engineers that one can imagine pouring over every last detail for weeks, this one slipped right through our fingers. By accident, someone was near the sump pump when it started and the machine stopped. After verifying good power, start dropping some of the network communications off (if possible) to find the break point for the comms failure.

I think if anyone here offers up the software for free or discount that might be an infringement of this board's usage policy (i.e., selling of copywritten software). I quickly found someone on Ebay selling just that...CD copies of the software with a homebrew programming cable...for $350. Obviously Allen-Bradley has not found this out (yet).

Have you tried calling Allen-Bradley tech support? Select registration from the phone tree options list. I have found tech support to be more responsive to registration issues than my local distributor. You say "iFix needs a registration number" then you got out your EVMove disk. Is this correct? EVMove is for the Allen-Bradley license, not the GE-Fanuc (Intellution) iFix license. Also, there is a USB-version of EVMove out there as (working) floppy drives are becoming a rarity. On a side note, if your SCADA node is critical, why not upgrade in parallel off to the side? You can then work through the licensing issues and other such without impacting your process.

What is the goal of having the A-B PLC and the Siemens PLC communicate? You say you want to read data from the Siemens PLC. Instead of pulling data directly from the Siemens PLC into the A-B PLC, possibly you might look at a gateway to the pull the data in and make available to the A-B PLC, which is what the ProfibusDP card will do for you.

I have been working up a brainchild idea that should not be unique. I want to connect to have the ability to connect to any of our machines out in the field, in customer plant locations, with wireless cellular modems. My strategy is that if a machine Allen-Bradley PLC has an Ethernet port, that RSLinx on my desktop should be able to communicate with it. I do not think I need a handling PC in the remote machine panel to be a communication gateway as the wireless cellular modem should take on this responsibility. My theory is that the wireless cellular modem will have an IP address, that I will define in RSLinx, which drilling down should show the PLC processor. Has anyone done this or can point me to a white paper on such? I don't want to invest in a test modem and sample a service plan to find out that another device is needed, such as a gateway.

The PLC-2...ah, the days. And your customer is not the only plant manager who is naive about what happens when one takes a steaming heap. Keep in mind that the PLC-2 uses double-slot addressing. This can be adopted in the PLC-5, but if you are not careful, you will be back-addressing your whole program. I would suggest you write up an action plan for the plant manager they have more obsolete controls in the plant... 1. Do nothing; cost = lots of downtime and pay your contractors huge sums to get back up and running (and maybe lose undocumented changes) 2. Purchase Spares: you can purchase spare PLC-2 on Ebay, from other used controls brokers; cost = a few hundred $ for spare processors, but then how do you download backups? Better keep that old laptop or desktop with the Icom software. 3. Upgrade (PLC-2 to PLC-5); cost = again, few hundred $ for surplus processors or buy new (must have programming computer and software) I purchased a stack of 2's off of Ebay in a pinch. Check it out...there are people there right now who could ship you overnight. I would hook you up, but I sold my junk bin 2's on Ebay years ago. My PLC-2 horror story...had a production with a PLC-2 and planned the upgrade on a weekend. Piece of cake. I had the program uploaded and converted and ready to rock. 15 minute job. I pulled the old CPU, slid in the new CPU, powered up, downloaded the program and a bunch of outputs started cycling on their own. Short story...one of the plastic bands on the old CPU had stuck in the backplane, and the new CPU joined one of the output backplane pins to the power rail. I had thought through everything, or did I? Spare CPU - check. Spare backplane - nope. While I had a spare backplane rushed in from our distributor, I bent the backplane pins back and said a bunch of prayers. The darned line is still running, but I took a beating from the plant manager for it.

A big factor to consider when choosing a control network hardware solution is...managed or unmanaged switches. PLCs and other industrial control hardware are notorious for flooding networks with broadcast traffic. Managed Ethernet switches give the administrator the ability to limit traffic between devices/switches. Along the same line is who will administer this network. If you, the control engineer, are in charge of your network, then it is your choice. If IT will be covering you, it is best to get their buy-in or start to rally the troops to stake your case for your own preferred hardware solution.

Thank you, Bob. I figured if I can establish an internet connection from the remote PLC to our network, via the internet and wireless modem, then RSLinx should be good to go. We will have to setup the security on the wireless modem end and do some idiot testing to make sure nothing bad can happen if the customer hooks our sub-network into their network (thus allowing anyone with wireless modem access rights to see the customer's whole network). This bi-lateral security issue may require us to add a VPN router. We do put Ethernet switches in many of our systems, thus upgrading from an unmanaged to a managed (Hirschmann or Cisco) switch should give us the VPN routing ability, and also to block out devices not in the switch table (outside intruders).