TConnolly

Have you recently changed from using the EVRSI activation to use Factory Talk Activation?

If you are using a ControlLogix PLC and it has has an ethernet card in it you can program the PLC to send brief email and text messages. Most phone providers allow you to send email as a text message by using phonenumber@cellproviderservice.com/net/whatever. There is a technote in the Allen Bradley Knowledgebase at AB.com on how to do this. You will need a tech-connect contract to access the KB and RSLogix5000 PLC programming software.

Ever since the ML1400 came out we haven't used anything else for small platforms (we want the e-net and the ML1100 is too small). For everything else its ControlLogix L71s now that they are cheaper than the L61. The compact logix is a great platform and they are better priced than the older SLC systems. We have used it but only in limited applications mainly because it compounds our spare parts inventory.

Are you using an older EVRSI activation or a Factory Talk activation?

Keep up the good work Tim.

Length is destination address length. It should be 1.

I use a lot of the Beckhoff IO. Its almost plug and play with AB's ControlLogix - Beckhoff has a few software tools that help you set up the communication and data mapping and from there its a piece of cake. Beckhoff tech support has been really good in my experience and the stuff is reliable and inexpensive.

You don't need to use a comparison. You can directly address the bit in the integer. If you are writing a value of 0 or 1 to N10:0 then address bit N10:0/0. You can also write integer words to B file words, for example you message write to word B12:0 and address bit B12/0 in your program.

Is the time zone set properly in the PLC (Controller properties Date/Time tab)? Is Windows configured for the right time zone? What rev of firmware are you using?

The Real input is fixed at 1.0. Open the TOT tag and enter 1.0 for the .IN element of the tag. Same for the other values I listed. The result is a real indicating how many hours have elapsed.

Use the TOT instruction and configure it to totalize time instead of using a timer. In the TOT tag configure input at 1.0 and gain at 1.0. Set timebase to 2 to totalize hours. Set enable to 1. Set ProgProgReq to 1. My preference is to place it in a periodic task but it will run just fine in the continuous task. Refer to the instruction set reference manual to learn more about this useful instruction - ie, you can use the targets to trigger maintenance flags or other time based notifications. When you use a timer and counters you miss two full scans plus a portion of a third scan for each interval. A PLC timer is a computer instruction, not a device. Your actual time interval will complete at some point in the middle of a scan. You will loose the elapsed time until the instruction is next executed, then the subsequent scan to reset the timer, and then the scan after that to restart the timer. It may not seem like much but over the course of one day a one second interval timer in a program with a 1msec scan will loose between three and four and a half minutes of time. There are tricks you can do to avoid resetting the timers and loosing the 2 to 3 scan interval, but since you're using FB just use TOT instead. It won't have that problem.

It sounds like you've picked up on it. The curve is for pumping speed while you're trying to control pressure so I wasn't sure if I stated it well after I re-read my post. If you were to trend your system pressure over time with pressure on the Y axis and time on the X axis it would probably look similar to the same curve but with the curve rotated counterclockwise by 90 degrees, which might help you visualize the conversion. Good luck.

I recommend putting the PID in a periodic task and letting it execute continuously. When it is not being used put it in manual mode and set the output to pre-determined values appropriate to the task. The exact flow characteristics are naturally highly dependent on the machinery and associated piping. Technically the change is not an abrupt one but there is a point for every system when its becomes obvious that molecular flow dominates over entrained flow. If you can run your system at max pumping speed and trend the pressure you'll see it. There will be an initial high speed decrease in pressure that appears to slow down linearly at first but then it hits a point where it begins to dramatically slow even more and the curve will start to flatten out. My first attempt would be to divide the curve into three parts, the first short part that shows a steep but kinda linear pressure decrease, the primary part of the curve, and then the rest beyond the curve where it starts to flatten out and try to tune each section. Then as I saw how well that performed I would either add more gain sets or see if just two sets would work, one for the initial drop and one for the rest.

Vacuum pumping at a controlled rate can be very tricky. Vacuum pumping does not behave like steam or pressurized air. It is not a linear process as you have to contend with a constantly changing mean free flow path length. Mean free flow path is the average distance an air molecule travels before colliding with another air molecule. When pressure is high the mean free flow path is very short - there are lots of collisions between air molecules. As air moves toward the low pressure inlet of the vacuum pump additional air molecules are entrained and the flow momentum carries chamber air in that general direction. As pressure decreases you have fewer molecules and fewer collisions and the pumping process changes from entrained flow to molecular flow - at that point momentum transfer is no longer in the general direction of the pump inlet and random molecular flow dominates. When that happens the only air that you remove from the chamber is what happens to randomly wander into the pump. (Keep in mind there are still ~1018 molecules per CC so a lot of molecules are still being moved, they are just behaving differently). Put in simpler terms, you soon reach a point where you can no longer "suck" air out of the chamber. Technically you can't really "suck" air out but we tend to talk about it that way - unfortunately that leads to poorly designed vacuum systems because someone didn't account for the exponentially increasing mean free flow path. To control the rate using a PID you will probably need to to use multiple gain sets, you will need at least two gains sets and probably more depending on how far down you want to pump your pressure. Also your vacuum system needs to be well designed. Many vacuum systems have two different pumping mechanisms each with its own associated vacuum piping - there is a rough vac loop that has small diameter piping and a high vac loop that has large diameter piping. The rough vac loop is used at high pressures where flow is entrained. The high vac loop is used at low pressures where molecular flow dominates. You probably won't get satisfactory control with a single on/off valve but might do OK with a set of parallel valves with a small foreline, medium foreline, and large foreline. One method we use is to use a motor operated butterfly valve in a large foreline but we only control pumping rate until the pressure drops enough that there isn't a windstorm in the chamber (below the transition from entrained to molecular flow), then open up and let it pump as fast as possible. Another method of controlling pump down pressure is to open the foreline valves to the vacuum pumps and let the pumps pump at max rate and inject a process appropriate gas from a high pressure source. Since that is much easier to control (like the steam pressure control you mentioned) it makes chamber pressure easy to control - though somewhat wasteful unless the process appropriate gas is air.

Is this an XIO or XIC instruction on the rung in front of the PID instruction? While that is OK for a a PLC/5 or CLX, its a huge no-no on a SLC. The SLC PID must be on an unconditional rung or bad and usually undesirable things happen to the integral sum.

I'm looking for suggestions on a good sci-fi novel that sticks to the laws of physics, deviating only when absolutely necessary to move the plot along, and keeping that to a minimum. One that focuses on telling a good story rather than technobabble.

I recently read "Through Struggle, The Stars," the first book from newbie author John Lumpkin Set ~130 years in the future Japan and China are in a costly space race that leads to war. The US, the UK and the EU all try to stay out of it but they are inevitably sucked in. The protagonist is a recent graduate from the Air force Academy in Colorado waiting for his slot in flight school. His plans are derailed when hostilities break out and he is assigned a temporary position as a military intelligence liaison officer, an event that will change the course of his life. Circumstances put him in a position to uncover the real reason Japan picked a fight with China and he proves himself to be a promising intelligence officer as he becomes more and more intrigued with his new career. The day comes that he will have to make a choice.

The first one is a flange or other removable connection, for example there may be a removable instrument or a removable hose to the left of the valve. You can see some examples of that if you will look at the P&ID drawing you posted. There are several ball valves that are attached to instrument balloons. This indicates that you can close the valve and isolate, remove, and service the instrument. The first thing you need to do to understand that P&ID is to understand what the instruments are. I posted an ISA tag reference in this post http://www.plctalk.net/qanda/showpost.php?p=158326&postcount=9 Feel free to use it to help you decipher the instrument tags.

You can use the FFU instruction again. Just unload the value to a discard register and subtract that much from your running total and reaverage. If you kept the previously unloaded value you could load it back in or you can let the queue be with an empty space in it. You can program multiple FFU and FFL instructions to the same queue.

Good catch Bob. The Add 1 is not necessary as shown. For some boneheaded reason I was thinking that since a FIFO starts at position 0 I needed to add 1. Except that even though it starts at 0, after it inserts a value it increments the position, so R6:0.POS = the number of element in the FIFO. By bad. I have removed that from the program attached to the previous post.

Welcome to the forum. When a cycle begins initialize a PEAK_PRESSURE variable to the current pressure with a one shot. Then whenever the current pressure is greater than the saved peak pressure move the current pressure into the PEAK_PRESSURE variable as the new peak pressure. At the end of the cycle move the PEAK_PRESSURE to a FIFO queue where all the previous peak pressures are held and then compute the average. If you use a FIFO and keep a running sum then you don't have to sum the entire queue every time you compute a new average. See the attached program. PeakStoreAndAverage.RSS

If you have an existing bridge then use it. Its pretty easy to message through the bridge. You won't need to involve a processor in the bridge rack. If you don't want to use the existing bridge then the second option is to go with the DHRIO module in the CLX chassis and connect it to the DH+. Then you can exchange the data with a message instruction. You'll essentially have two bridges for some redundancy.

Another way could be like this. File N100, 101, and 103 are integer files containing ten elements to define a recipe that can have a variable number of ingredients up to ten steps. File N100 contains the ingredient numbers, File N101 contains the ingredient quantity. File N103 contains the blend time. Word 0 is the first ingredient and quantity, Word 2 is the second ingredient and quantity, etc. So, Word N100 N101 N103 0 5 2 0 1 1 4 0 2 3 7 60 4 2 1 60 5 0 0 <- end of this recipe 6 0 0 7 0 0 8 0 0 9 0 0 You can use a counter to step through the recipe and indirect addressing to determine which ingredient to to use. The ingredient numbers control various feeders or prompt the operator to add an ingredient manually.

You have HMI screens. So you have the required components. All you need is the software. I'm perplexed, what other components to you need? Is the operator also heaving buckets of stuff into the mix by hand? Even if that is the case, can't you still automate the amount of stuff he is putting in by pressing buttons and have the HMI tell him when its time to scoop stuff in by hand and how much?

Eliminate the operator ingredient buttons altogether. The operator selects a recipe. Presses start. Everything else is sequenced by the controller.