kaiser_will

I would suggest creating a flowchart, on paper, of how the program works. Next, create a state machine in ladder logic that coincides with the flowchart. SFC's are terribly difficult, I have found, for maintenance guys to troubleshoot. If the machine has a lot of maintenance problems, eventually the electricians will want a new screen with state machine status lights (also known as the christmas tree). I always try to use the rule of thumb that all information should be binary...if you look at the status (state machine bits or state machine lights), is it very clear if things are working properly or not (yes or no...very binary). When you can drill diagnostics down to the binary level, your work on this project is done. Use this situation as an example for developing control system standards from vendors. Just wait until your boss buy a machine that has the password set. If it was a SLC, you can bypass the password and get online. If it is a ControlLogix CPU, good luck.

I have an application where we pass alarm and message text information from the PLC to the PanelView 1000 Plus. I need to export out my message list of unique messages/alarms for completing the documentation. However, when I export the tag list into a CSV, the file does not include value (which has the text value of the alarms/messages). This is interesting as I can copy the MessageList tag (String[320]) array from one PLC to another, it grabs the value of all the messages. I tried to copy this tag array into an Excel spreadsheet with no luck, just like exporting the tag list had no luck (value is not included in the attributes). I sure don't want to hand-type all 320 into my spreadsheet for documentation, but will have to if there is not a better solution.

You could put in a ControlLogix rack with an Ethernet card and bridge your company LAN and your PLC LAN together. If you have a lot of PLCs, this works out well. However, the cost can be a bit much for a manager to expense off. You absolutely need to hide your PLC LAN behind an Ethernet switch that can handle limiting broadcast traffic. PLCs and other Ethernet-enabled devices continually want to talk to the world, and this repeated traffic will have your IT manager in a tizzy-fit trying to find the source for all the traffic. Another step that may help you out is to re-IP address your PLC network to use a convention similar to your company LAN network. I have found it helpful to work with the IT group to find a common ground set of rules for the control network, then put the rules in writing for equipment suppliers to follow. It makes no difference to a OEM hardware manufacturer as to what IP address numbering convention to go with, and it will save a lot of time to let them know your rules up-front (instead of running behind new machine startups and changing the IP addresses to match your rules). Do some research for an Ethernet switch that can limit broadcast traffic and bridge networks. We are an OEM and we install Cisco Catalyst 2955 DIN-rail mount Ethernet switches. Their price is considerably more than what you can pickup at Best Buy, but few brands can match Cisco quality and performance. Cisco has excellent documentation for you to read up on the technology out there. http://www.cisco.com/univercd/cc/td/doc/ci...k/ics/cs010.htm

Design criteria to consider are (1) accuracy and (2) distance. LVDTs have decent accuracy (typically fractional-millimeters). LVDTs are limited in distance (and their price goes way up as length grows). With LVDTs, they do wear with time since there are moving parts (rod and donut), are a function of how they are installed (i.e., improper alignment will lead to premature failure) and are sensitive to the elements (i.e., dirt, vibration, ground noise, etc.). Ultrasonic and laser distance sensors, such as Sick optics, are ever increasing in accuracy and durability, but also have limitations, such as light being reflected off of the measurement target. Develop a list of design constraints and objectives, then try to find the best-fit sensor for the application. If you run into a situation where there is not a perfect fit, you will not be the first. Go for the most reliable solution and make sure your program code has features to deal with the short-falls. Remember to design for failure.

Eddie and Commander...thanks, much, for the input. I am reading up on those features and expect to give them a whirl on our test machine.

I have an application with a CompactLogix CPU talking Ethernet to a PanelView 1000 Plus HMI. We have a lot of screens which all have a lot of information content. The idea is to create a master screen that pulls some information from other screens and automatically changes with the station available to the operator. I have a handle on changing PVPlus screens from the PLC by controlling the ScreenControl and ScreenNumber tags. Piece of cake. However, I want to build a new screen that has pop-ups that pull their content from other pages. I don't see how RSViewStudioME supports pop-ups. I could copy some content from another page, group and automate the visibility. But then if I ever change that group or the master where it was pulled from, then I have to remember to go back and dish out the changes everywhere else the information is used. That is where things can get dicey. Or if I want to bury layers of content with machine status or pushbuttons to make those layers visible, then the engineer that comes up behind me may miss the information first time around. I really miss the project content tree layout that was in PanelBuilder32. One could easily stack layers of content and pull them up without having to move other layers around. I would like to declare pop-ups and build screens with them. I know, if we were using RSViewHMI or CiTect or Cimplicity or WonderWare this would be gravy. However, that is a battle the sales engineers will not budge on.

There are a couple of ways to skin this cat. 1. You could run the chuck energize outputs through a contactor with a hard-wired circuit to put them in a safe state if the 7th axis is energized. 2. If you have control of the air chucks through like a PLC, you can put safety logic in to put the air chucks in a safe condition should the teach pendant be enabled.

Connecting to an Allen-Bradley Ethernet-based PLC: 1. Get the proper cable and verify that it is in good working order a. There are 2 types of Ethernet cables (crossover and patch); a crossover cable is for connecting a computer to another computer or similar device directly, whereas a patch cable connects a computer to devices that have connections through other hardware such as switches/routers. I do believe for computer to A-B PLC one will need a PATCH cable, even though you are not going through any other hardware (A-B designed that way). Someone can chime in to verify or correct me here. b. If you are having trouble, make darned sure that cable is working properly. Typical Ethernet cables are flimsy and fail very quickly in the industrial world. Buy good quality industrial Ethernet cables and cut-up what is known for sure to have failed. c. I always take my handy-dandy label maker and label all PATCH and CROSSOVER cables accordingly. This has bit most engineers in the tail at least once. 2. Get the correct IP address of the PLC you are trying to connect to a. For added measure, purchase a cheap label printer and print off a label with the IP address and affix to every PLC processor or inside of the PLC cabinet. This has saved my bacon so many times. 3. Make sure your computer Ethernet/IP port is set properly to communicate with the PLC you are trying to hookup with. You cannot make a phone call from the USA to Europe directly without entering the country codes. Ethernet/IP is the same methodology in that your computer needs to be setup (IP address octets) properly or have proper privelege (subnet masking) to make the call. a. Every manufacturer and OEM will IP number the PLCs on their machines to whatever the heck they want. If your employer is purchasing machines, there is very good chance that the bulk of them have vastly different IP addresses or networks already. This means you need to follow the rules for connecting up to each one, or go through and start re-addressing (and smacking Engineering for not having an equipment IP addressing scheme). b. Ethernet/IP numbers are much like a phone number, in that the 4 octets (groups of up to 3 numbers) are like (country code)-(area code)-(first number group)-(last unique number group). Computers, etc., can talk through (first number groups) to other Ethernet/IP devices via the use of Subnet Masking. The first 3 octets are often the same for all your equipment on that control network, but the last octet must be unique for every device on that network else errors will be thrown up for "duplicate Ethernet/IP address in use". c. Typically, Subnet Masking is 255 (block) or 0 (allow passage). An example may be 255.255.255.0, which would allow any device in the set (first number group) to talk within the network. d. 255.255.0.0 allows any device in any (first number group) to talk to any device. This is typical for most RSLinx driver setups. 4. So you are sure you have the proper patch cable and it is working properly. The next step is to pick an Ethernet/IP address that has privelege to talk to your PLC (i.e., the subnet masking is set right and the first 3 octet groups are the same as the PLC). Your computer has to use an address that is not in use on the network the PLC is on. a. If the network was designed by somebody else or you have no idea what is out on that network, you need an Ethernet/IP "sniffer" utility to tell you what is out there. b. I like to use FreeIPScanner (www.eusing.com). Set the first 3 octets the same (or it will scan for infinity) and to the PLC address (8.9.1 in my example). Enter the top and bottom range of the hardware you want to scan for (1 to 255 is your range). Scan away and look for the live device IP addresses in use. 5. Now you can ping what you think is the PLC IP address from what you know and what the IP sniffer utility found for you. If you see the PLC IP address in the IP sniffer utility, you are sure your Ethernet port is setup properly, you are sure your Ethernet cable is the proper one (patch) and is working properly, and you are sure that the RSLinx Ethernet/IP driver is setup properly, it is time to maybe call Allen-Bradley. The first thing they will have you do is what I have laid out for you.

1. A tip to file away for future is if you are running an application on your PC that uses the serial port, that application may need to be killed for RSLinx to use the serial port properly. For instance, I run Palm Desktop for my trusty but old Palm Vx (which gets updated via the serial cradle) and this application must be killed in the System Tray for RSLinx to run properly for serial connections. 2. The null modem cable has bit most of us at least once. Figure out your correct cable setup and label that mother so everything is crystal clear in the future. Also consider picking up duplicate serial cables and a serial port/cable tester (MCM Electronics, Granger, etc., all carry such an animal). I try to snag all the leftover serial cables from our IT guys before they chuck them all in one of those 5S cleanup fail swoops. Nothing can be worse than spending hours trying to get comms to find a $10 flippin serial cable had a bad spot. Same thing goes for Ethernet...pickup a tester and a spare cable and build up your road/project kit. Oh, and if you find a bad cable, cut it up before you trash it. I have seen electricians or other engineers pickup a cable from the trash bin and get jammed up figuring why it was thrown away in the first place.

A problem with A-B PLCs is that the processor can fault out and stop for math overflow, such as a counter maxing out or a divide by zero math function. If you ever had a process that stopped on a dime with the customer losing many thousands of $/hour, then found the quick fix to keep the processor running was to add 1-2 easy rung(s) at the end of the main file (unlatch S:5/0), engineers are inclined to add such a preventative measure to all their programs. For SLC-500 CPUs and preventing math overflow faults from stopping CPUs, check out page 4-3 of this document... http://literature.rockwellautomation.com/i...rm001_-en-p.pdf It may sound like a duct-tape solution for the real problem, but at least it keeps your CPU from faulting. I have run into strange situations where the CPU faulted for divide by zero due to the analog speed feedback, used for a speed PID loop going berzerk due to a failing encoder feedback signal. Better to keep the processor alive and develop alarm strategies to sense such a situation and bring the machine to a safe condition.

I would side with Keith here. Running coil-to-coil unwind/wind applications in torque mode can have strange consequences (tension lag or strip break) due to slight variations in strip properties (coil flat spots, coil head/tail tapering). If you have to run in torque mode, then put limitations around the torque command. You might find that the the response rate of the limitation bandwidth is not ideal, meaning you run into oscillation of strip tension due to the output varying as a function of itself. If your line has a belly roll for maintaining web tension, you might be able to fit it with an encoder and now you are set for web speed control (which is your ideal output anyway). Maintain linear web speed increase or decrease as your coil winds/unwinds, or maintain constant web speed as the payoff reel speed is increased/windup reel speed is decreased. Similar to the formula pointed out earlier, you want to either keep strip speed constant (i.e., payoff reel will be sped up as diameter its gets smaller) or keep payoff reel speed constant (i.e., web speed will be slowed as diameter gets smaller). Figure out your desired constant and develop a formula for your payoff strip tangential speed (taking into account gearbox ratios, etc.). You can trim off tension by adding a small percentage formula tied to a fluctuation in strip speed/effective unwinder torque or an operator-controlled potentiometer. Some operators love having the ability to trim off the strip tension based on their visual queues as the web is flying by, but give them access to only enough to not crash the line. On a related note, perform a FMEA (failure mode analysis) to determine the critical control variables, desired constants (such as strip speed or tension or unwinder torque), then brainstorm how to monitor or control or sense those critical control variables. If you work through the process thoroughly, the means to solve the scenario becomes apparent.

Consider setting the pumps up in a lead-lag configuration with the lead pump to run from the PID output then call on the lag pump (with another PID loop) should the lead pump not produce enough output (which would be switched into full output mode). Put limits around PID output change (as a bandwidth that is sampled in time from the PID output with a +/- allowable band). If the pumps are high-HP (i.e., costly motor/pump repairs), the lead-lag configuration is optimal if programmed to swap lead-lag configuration at some interval. I have found this to come in very handy in balancing large-HP motor/pump runtime hours.