Posted: 5/3/2017 9:04:47 PM EDT
|
Are there any PLC programming gurus in here?
I have a project that entails the control of (3) of compressors. For what it's worth, the processor is an Allen Bradley Micro 830. Either one, two, or all three compressors are run depending on a suction line pressure. As the suction line pressure gets higher, more compressors come online. A 4-20mA pressure trandsucer connected to the PLC provides this pressure data. Each compressor has an hourmeter in the code. The compressor with the lowest amount of hours on it gets priority, it should be run first. The compressor with the second most hours is brought online as #2 if necessary... Compressors motors can also fault, and that is detected by discrete inputs on the PLC. So, first of all, what is the cleanest, most efficient way to determine what the smallest of a set of numbers is if there is no MIN function (or in my case, a MIN function that can only handle two numbers)? Or, better yet, in case I ever do a larger system, what is the best way to put a set of numbers in order, and associate that order with what those number are assigned to, in this case, compressors? Second, what is the cleanest way to select a compressor based on multiple criteria? Some sort of 2 dimensional array? Maybe I' making too much of this, but when I try to write it, it gets complicated and bulky *very* quickly. Thanks for any help! |
|
Wow, back when I was working this would have been a very fun task - it's the kind of stuff I did early on in my career.
But I've been out of it for so long now that I wouldn't be of much help - but I'm sure there are those here that could come up with something.... I know, not much help but never-the-less it sounds like a fun project. 
|
|
Ok, here are some thoughts for program layout:
Step 1: create nine bits, three for each compressor,1st priority, 2nd priority, third priority. Step 2: use LES instructions to find out which compressor has the least hours and is not faulted. Set bits accordingly. Step 3: start the highest priority compressor based on suction pressure being below setpoint for a set time (1 min?) Step 4: if suction pressure is still below setpoint for lets say 5 min, start the second priority compressor, same for the third. Step 5: if suction pressure is greater than the set point minus a deadband, start stopping compressors in reverse order. Watch out for what happens when the hour counter for the low hour compressor goes over one of the other compressors, this could cause some trouble. I always just do order rotation with every start. A sequencer instruction is useful for this, I am not sure if connected components workbench has one, I have never used it. |
|
Quoted:
Ladder code, ladder code everywhere...  The wiring schematics are ladders as well. Who's billing this guy $120/hr to program this?
I'm no programmer just an I&C engineering tech. What is controlling the compressor motors? VFDs? ETA Not to hijack Just a tech geek question purely selfish. |
| I do mostly modicon. I would have to use sub blocks to compare the values. I would set up the coils for the compressors on different networks, so that as the plc scanned, it would look at them one at a time to see if it should turned on. It would take two sub blocks to determine if it had the lowest hours. If yes, and the demand was there, it would set, and NC contacts on the other coils would inhibit them. The plc scanning is key. |
| Haven't programmed in a while but it would be similar to a lead/lag/standby used often in waste water treatment. Rockwell has a sample code library that you could access if you have a techconnect contract, you might be able to find it using google otherwise. Â I've never used ccw for logic but you could probably find a Logix code and modify it to work for the 830. |
|
Quoted:
I'd like to help, but the last time I programmed a PLC, it was done with either a ladder-logic compiler or Boolean. http://i.ebayimg.com/images/i/271102457736-0-1/s-l1000.jpg |
|
How dead set are you on basing everything on hours? Basing everything on hours adds more complexity to avoid things flipping when you dont want them to.
A sequencer is a good option for what you're trying to do, but might be more than the micro 830 can handle. I haven't used the micro 800 series for much yet. Another option is to use a counter to increment the lead compressor, with other conditions tied to the start rung. It's something I use for alternating pumps or blowers up to 4 units. As others said, you might find what you want in the AB sample code. It's worth a look anyway. |
|
The logic is the easy part..
First, look at run hours, usually do this once a week or so to rotate compressors to equalize run times. Second, look at fault inputs, if a compressor is failed it is disabled, taken out of rotation, and the rotation order adjusted accordingly. Now you should have a lead compressor (1), lag compressor(2), and a standby compressor(3). Use sequencing logic to compare your variable to a set point, and stage compressors as needed, probably have a min run time and a enable/disable deadband. Can't remember how AB stuff programs, but on the stuff I program I'd feed the variable and set point into a PID loop, and stage based on percentages.. No different than staging pumps based on differential pressure, or chillers based on flow/delta T/temp, or boilers, or anything else you can imagine.. |
|
We always call it ladder magic.
Sounds like a fun project. Each time a compressor start was called for I would examine the hours of each, greater than less than to determine which to start. Â Have the fault for each of the other motors override it's timer number with a branch so if there is a fault then a lower hour number won't be prioritized. Do they need to cut out one at a time as the suction changes as well? Â Another three rungs, one for each motor could decide which to cut off. Definitely latch the decisions so that the compressors wouldn't trade off as their hours or minutes passed each other. |
|
No offense, but it reads like you are under-complicating this
At some point you will probably have multiple status bits for each device: Compressor 1 is lead, compressor 1 is lag, compressor 1 is standby, compressor 1 unavailable, compressor 1 running Compressor 2 is lead, etc Compressor 3 is lead, etc You then need logic to manage these status bits, which takes some more detail about the process. Seperately you want to have the logic for what the scaled analog should be to start and stop the lead, lag, and standby. I expect that will have be some things like time delays, analog loss of signal handling, motor starts per hour, fail to run feedback, drive alarm output, etc. It really doesnt sound that hard, and would be a good learning opportunity. |
|
Quoted:
No offense, but it reads like you are under-complicating this
At some point you will probably have multiple status bits for each device: Compressor 1 is lead, compressor 1 is lag, compressor 1 is standby, compressor 1 unavailable, compressor 1 running Compressor 2 is lead, etc Compressor 3 is lead, etc You then need logic to manage these status bits, which takes some more detail about the process. Seperately you want to have the logic for what the scaled analog should be to start and stop the lead, lag, and standby. I expect that will have be some things like time delays, analog loss of signal handling, motor starts per hour, fail to run feedback, drive alarm output, etc. It really doesnt sound that hard, and would be a good learning opportunity. And you are exactly right- this is very similar to how I program chiller plants or boiler plants. Can't remember much about AB programming, the stuff I program I use function blocks (most of the time) and end up with several different sub-programs to do exactly what you're talking about. First program determines if the compressor system is enabled, and sets rotation order based on inputs (actually variables) from the 2nd, 3rd, and 4th programs Second program determines if compressor 1 control (determines from digital inputs if compressor has a failure or is out of service, keeps up with run time, and controls the start cmd DO based on input from the 5th program) Third program determines compressor 2 control (based on compressor 2's DI's, basically a copy of the 1st program with IO remapped to points controlling and monitoring 2nd compressor) Fourth Program determines compressor 3 control (yada yada yada) Fifth program determines staging order from 1st program, determines load from a PID loop, determines signal loss-sensor failure response, controls min on-min off timers, and send requests for compressors 1, 2 and 3 (to programs 2,3 and 4 respectively) Sometimes (based on what the SoO calls for) I'll do a sixth program to route failure/out of service/run time/etc alarms to another PLC or workstation. Also, most of the time I'll combine the first and fifth program into a single program- just depends on the SoO, especially if it doesn't require too many alarms. I try to KISS, but it can spiral out of control real quick. It CAN all be done with a single program, depending on the PLC involved (and I'll do it all in a single program on some of the controllers we use) but it's easier to troubleshoot and tune when done in separate programs. I'm still learning too, been doing this mess for a little over 10 years and always like seeing how someone else programs things. One of the best learning tools is a library of 'canned' programs and a spare controller you can test with, all of the schools and training in the world is no substitute for hands on- at least IMO..if I can remember, I'll post a pic of my test wall when i get to the office- anytime I can get my hands on a controller of any kind, it goes on the wall and I try to figure out what makes it tick. It can be fun and frustrating at the same time.. |
|
Quoted:
No offense, but it reads like you are under-complicating this
At some point you will probably have multiple status bits for each device: Compressor 1 is lead, compressor 1 is lag, compressor 1 is standby, compressor 1 unavailable, compressor 1 running Compressor 2 is lead, etc Compressor 3 is lead, etc You then need logic to manage these status bits, which takes some more detail about the process. Separately you want to have the logic for what the scaled analog should be to start and stop the lead, lag, and standby. I expect that will have be some things like time delays, analog loss of signal handling, motor starts per hour, fail to run feedback, drive alarm output, etc. It really doesn't sound that hard, and would be a good learning opportunity. This will definitely help. Yes, I do suspect now that, if anything, I have over SIMPLIFIED it, not over complicated it... |
