How to simulate a FOR..NEXT loop?

[New2PLCs]

In a processor like the MicroLogix 1500 which does not have a built-in FOR..NEXT loop instruction (I've seen some web sites that indicate that some processors do have this instruction), how does one simulate this functionality? NOTE: I want to loop within a scan.

In the AB ML 1500 manual, I noticed in the section on shift registers it said something about using JMP, LBL and CTU to loop if you wanted to shift more than once per scan. But I couldn't figure out how to get those to work as a loop. I bet there's a way to get RSLogix to output the rungs of what I tried in ASCII so that I could post it, but explaining it might be easier. I just had a LBL on a line with a CTU and later, after the logic I wanted to loop, a JMP going back to the original label. To exit the loop, I examine the CTU done bit and jump to a label on the line after the other JMP instruction. Thanks,

-Don

[Steve Bailey]

You put the label earlier in the ladder logic than the jump instruction. The reason you need the counter is to make sure that you have a way to exit the loop. Getting stuck in an endless loop could have disastrous consequences, since the I/O aren't getting updated while the program is looping.

It's been my experience that there are very few places where it's a good idea to loop within a PLC program. When you're accustomed to programming in other languages, you tend to try to program the PLC using the tools that you already know how to use. I'm confident that there are ways to accomplish what you want to do without looping. Remember, the PLC already loops back to the beginning of the program without you having to do anything.

[Allen Nelson]

Use a LBL, and JMP backwards through the code. Initialize a "counter" before the LBL, and increment it through the JMP. Like this:


N7:0 IS THE I IN "FOR I=1 TO 20". SETTING THE COUNTER TO ZERO HERE MEANS THAT IT WILL START AT ONE ON THE NEXT RUNG.
+---- CLR -+
----------| N7:0 |
+----------+
<BR><BR>
INCREMENT THE COUNTER EACH PASS THROUGH THE FOR-NEXT LOOP.
Q:0 +-- ADD -+
--|LBL|--------| N7:0 |
| 1 |
| N7:0 |
+--------+
<BR><BR>
PUT WHATEVER CODE YOU WANT HERE. WITH INDIRECT ADDRESSING USE N7:0, OR SOME FUNCTION OF IT.
<BR><BR>
THE "NEXT" OF THE FOR-NEXT
+--- LES -+ Q:0
---| N7:0 |-----(JMP)
| 20 |
+---------+

[Gerry]

Note that the CTU won't increment except on a false-to-true transition. You will need to force this in your loop by resetting the counter's enable bit - most easily done with an unconditional OTU.
The ADD instruction, as shown in Allen's example, does not require a transition.
Conditioning the (looping) JMP with the LES comparison or XIO of a counter done bit saves using more JMP's and LBL's. The counter's accumulator can also be used for indirect addressing.

[New2PLCs]

Steve,

Read the thread entitled "Energy Management System". If you can show me how to program my final attack on the problem (in the last post from me) without looping, I will bow to you as PLC God. (If you can do it in any manner, you will rank as a minor deity in my book.)

Allen,

You know, I've was playing around with similar logic to do that without the JMP and LBL instructions, with each scan being on iteration in the loop. All I have to say to defend myself for not thinking of that on my own is "I'm a noobie!" :)

Gerry,

That's the missing ticket I needed for doing it with the LBL, JMP, and CTU instructions. I didn't see how to achieve the desired result in the way the AB manual mentioned. I guess it doesn't make much difference, but the way Allen suggested seems simpler to me and I'll probably use it. Thanks. :)

-Don

[Peter Nachtwey]

Originally posted by Gerry
The counter's accumulator can also be used for indirect addressing.

Actually that is indexed addressing. In indirect addressing N7:0 would be initialized to the start of the array and the LES block should compare with the start of the array plus 20. In the above example, indirect addressing could only be used if the data or array start at 0.

[Allen Nelson]

Don:

As Steve pointed out, unless you have to have each compressor evaluated every scan, you don't need the for-next loop. If you can stand a slight delay (up to 500 msec), then take my code, delete the LBL and JMP instructions, and move the CLR instruction to where the JMP is.

On the first scan, N7:0 will be zero, until it hits the ADD, and the logic will be scanned using n7:0=1. On the next PLC scan, N7;0 will be =2, and so forth, until it hits 20, at when it will go back to zero.

Another method of not doing the looping is to use subroutines. You could create LAD 4 for the processing of any (N7:0) compressor, and then pass a number to N7:0 just before the JSR, like this:

+--- MOV -+
---+---| 1 |
| | N7:0 |
| +---------+
|
| +--- JSR -+
+---| U:4 |
+---------+
<br><br>
+--- MOV -+
---+---| 2 |
| | N7:0 |
| +---------+
|
| +--- JSR -+
+---| U:4 |
+---------+
<br><br>
et cetera


Not as elegant, perhaps, but it works too. This technique works better than For-Next if there are specific compressors that you DON'T want evaluated - disable the rung, and you don't execute the subroutine (which means that any outputs that the subroutine has enabled, remain enabled - something to be VERY careful of).

One more possible solution to your problem: Just what is the consequence of exceeding the load limit? Will a breaker trip, or is it just the cost of electricity? My energy bills always go up in summer, because i've balance the cost of electricity with the cost of comfort. I'm not saying to be intentionally wasteful, but if that MaxLoad is set in stone, there will be days when even the VPs get "hot under the collar" (pun intended).

You know you've got a no-win situation (unless you're lucky and a 50% duty time is sufficient for each compressor to keep everyone cool). At the very least, put the MaxLoad in a register, rather than a hard-coded number, so that you can (if needed) expose it to an HMI, and adjust it up if things just get too miserable.

[New2PLCs]

Peter,

I'm not sure what you mean. What's the difference: you can initialize the counter's accumulator value just as you would N7:0, no? Would you mind explaining, please? Thanks,

-Don

[Allen Nelson]

Originally posted by Peter Nachtwey


Actually that is indexed addressing. In indirect addressing N7:0 would be initialized to the start of the array and the LES block should compare with the start of the array plus 20.

Indexed addressing manipulates S:24. To use indexed adressing, you would write N7:0, or the counter .ACC to S:24, and then reference any address with a '#' sign.

My example was "FOR i=1 to 20". If I had wanted, say 5 to 25, I would have done a MOV of 4 in the initialization rung, and a LES of 25.

In the above example, indirect addressing could only be used if the data or array start at 0.

In my original example, the array actually starts at one, not zero, because the pointer is incremented from zero to one on the next rung, prior to it being used in any addressing scheme.

[Peter Nachtwey]

Allen, I usually put my code before the increment so the arrays can begin at 0. Incrementing before the code does start the array at 1.

New2PLC. I dread explaining this. Let's say there is an array of compressor runtimes for four compressors at N7:101 to N7:104.

To sum the run times using indexed addressing:

clr N7:0 INDEX
clr N7:1 SUM = 0
lbl q:0 mov N7:0 S:24 LOAD INDEX INTO S:24 INDEX REGISTER
add #N7:101,N7:1,N7:1 SUM = SUM + ARRAY[INDEX]
add N7:0 1 N7:0 INDEX = INDEX + 1
les N7:0 20 JMP Q:0 IF INDEX < 20 THEN REPEAT

Notice the # in front of the N7:0. That means that S:24 is added to N7:101 to form the effective address

To sum the run times using indirect addressing:

mov 101 N7:0 POINTER = 101
clr N7:1 SUM = 0
lbl q:0 add N7:[0],N7:1,N7:1 SUM = SUM + [POINTER]
add N7:0 1 N7:0 POINTER = POINTER + 1
les N7:0 105 JMP Q:0 IF POINTER < 101

Notice the [ ] around the 0 in N7:[0] this means N7:0 contains the address or register number of the register you really want to access.

[Tom Jenkins]

I agree with Steve and Allen. It is generally NOT necessary or a even good idea to use a for-next loop in ladder logic. Unlike high level languages, the very structure of ladder logic is desigend for evaluating repetitive logic, making for-next loops redundant. Besides, it is much easier to troubleshoot successive rungs evaluated once per scan than to troubleshoot the logic in a for-next loop where intermediate results are undoubtedly not accessible.

And, as many regulars here know, I firmly believe that good prgramming, by definition, must be easy to troubleshoot!

[New2PLCs]

Peter,

I'm sorry, I should have made it clear that I know the difference between indexed and indirect addressing. Your first post still doesn't make sense (to me.) In his example Allen shows the structure of a loop and mentions using indirect addressing. Then, Gerry showed how to do it the way I originally asked about, using a counter, and says you can use the counter accumulator for the same type of indirect addressing functionality. Then you say it's really indexed addressing. Sorry to be so thick, but I don't see what you meant.

-Don

[Gerry]

Don,
I think you've got a handle on the problem and know how to do what you want. This may have been a rare mis-fire on Peter's part.

As for the concept of 'dumbing down' your programs to supposedly make them easier to understand or troubleshoot, I am strongly opposed. Following this maxim, one would avoid not only loops, but indirect and indexed addressing, subroutines, etc. for fear of confusing the unwashed masses. And without the tools, one would avoid many potential applications. Rather akin to burning books. It is arrogant to assume that electricians are incapable of learning anything new or that they are not even interested. Besides, getting equivalent functionality to a 'banned' technique will more than likely be 'long-winded' and bug-prone and genuinely difficult.

[Peter Nachtwey]

New2PLC,
When I saw N7:0 set to 0 I assumed ( oops ) that Gerry really meant indexed as opposed to indirect address. Setting N7:0 allows one to access arrays or data using indirect addressing starting at 0 or 1 depending on whether the index is pre incremented or post incremented. I always start arrays at 0 and post-increment pointers or indexes because this is often more efficient than starting arrays at 1 in many cases where the array is a power of 2 long. In my narrow thinking, didn't consider the other options such as starting the array at 1 and pre-incrementing like Allen does. Oops again.

[ganutenator]

I too believe and try my hardest to make programs easy to follow. I can't tell you how many times I have reduced multiple confusing rungs using redundant contacts down to 1 or two rungs of logic. It has been my experience however, that just using coils and contacts DOES NOT necesarily make a program easier to understand. IN FACT if I come across a FOR/NXT routine that is written correctly, I find it much easier to comprehend. Why, because a For/Nxt routine has boundaries. You can easily determine what the programmer was trying to accomplish by writing that section of code. The hardest part of reading programs written by others is not in figuring out how a rung of logic works, but trying to figure out WHY or WHAT the programmer was trying to accomplish by writing it. (Which is why I can't emphasize enough... that you should write comments explaining what you were trying to accomplish when writing a particular section of logic, rather then trying to explain that a false to true transition of B3/0 latches coil B3/30 and loads N7:0 into the FIFO stack N7:[N8:0] where N8:0 is the pointer into the indexed array. If I want to understand how an instruction works, I'll look it up in a book. TELL ME WHAT YOU WERE TRYING TO ACCOMPLISH!!!

Excuse me, I was just venting there for a second. Probably all of the Heinekens. But seriously, you will find that a section written with a FOR/NXT loop may appear difficult at first, but you will come to long for them after trying to decipher a program that is badley written with all XIO XIC OTE instructions where 80% of the contacts or coils will never come in to play.

One example of a good use for For/Nxt loops is to replace the god awful AB file intstructions like the FAL, FSC, and FBC that only operate every other scan. A For/Nxt loop is awesome for this. And since I am venting..... What in the hell was Rockwell smoking when they created the average (AVE) instruction.

[Tom Jenkins]

"It is arrogant to assume that electricians are incapable of learning anything new or that they are not even interested."

Well, pardner, I is personally not jist referring to elctricians or technicians, but to any feller what has to de-bug a program, including the original programmer six months afterwards, and other engineer types involved in the project after the original programmer has moved on down the road. I've made a litle money over the years rewriting code that was so durned clever that it was undecipherable. Many of these program techniques was elaborate and tricky, way over my haid, but totally uncalled for in terms of fulfilling the primary function o' making the durned machine run. Time is money, and service time is the most expensive of all.

By all means, pardner, use the best tool fer every job, but if it ain't obvious whut is going on, mebbe another technique is really better even if it ain't as compact. After all, ya already paid fer all thet memory, so why not ues it?

gatenutenator hit it on the haid! Good commenting is esential, and if the code ain't obvious ya had better go to great lengths ta explain whut is happenin' and WHY it is gonna happen thet way!

KISS - Keep It Simple Stupid! The programmer ain't gettin' paid fer demonstratin' his expertise, he's gettin' paid fer makin' a machine or process perform as intended with the lowest total life cycle cost!

[rsdoran]

As for the concept of 'dumbing down' your programs to supposedly make them easier to understand or troubleshoot, I am strongly opposed. Following this maxim, one would avoid not only loops, but indirect and indexed addressing, subroutines, etc. for fear of confusing the unwashed masses. And without the tools, one would avoid many potential applications. Rather akin to burning books. It is arrogant to assume that electricians are incapable of learning anything new or that they are not even interested. Besides, getting equivalent functionality to a 'banned' technique will more than likely be 'long-winded' and bug-prone and genuinely difficult.

Well now being one of the unwashed masses what I see being said here is "It doesnt matter what you do they got the pretty little red/green lights to use!"

As far as electricians/maintenance people being capable of learning about plc programming. Why should they? They spent many years learning a specific trade to support their families/themselves. Why should they be forced to learn a whole new language/job just because.

OK some are interested so take the plunge, so they take personal time, company time and learn a little about this PLC thing. All of a sudden New machines come in that are based on IEC standards so no original code no can view/monitor/edit. Cant get the code? Why? The unwashed masses arent entitled to it.

Doesnt really matter any more, the day of the floor maintenance/electrician doing much with a plc is fading, too many features are added in every day and the programming is going to fadeaway from ladder altogether.

Dont know what dumbing down is, you should use what is needed, NOT use something just because its there.

When its all over with though make sure you tell us unwashed masses which pretty little light goes to what device, maybe we can figure the rest out somehow.

[Gerry]

Some apply this principle as if it was Keep it Stupid Simple.
A number of years ago, I was shown a draft copy of 'programming guidelines' for PLC5's from a large corporation with substantial engineering resources. The guidelines purported to ensure that programs would be readily understood by all and sundry. It included statements like:
1. Never use SFC's
2. Only use on-delay timers, never off-delay
3. Never use retentive timers as sometimes they don't get reset

There was lots more but I've purged it from memory. In spite of their engineering resource, this document was prepared by a contract draughtsman.

The point, I think, is that these sorts of rules that artificially restrict the approaches to a problem are probably a reflection of the promulgator's learning experience and failure to (at least initially) understand.

"As far as electricians/maintenance people being capable of learning about plc programming. Why should they? They spent many years learning a specific trade to support their families/themselves. Why should they be forced to learn a whole new language/job just because. "

RS, do you really mean this? Should the automobile have been suppressed so blacksmiths could carry on making horseshoes? Should electronic fuel injection be banned because carburettor technicians don't want to know?
Nobody can be 'forced to learn' if they refuse. I accept that there are people who refuse to learn, but they must understand that the world does not owe them a living.

[Terry Woods]

I have always been a proponent of the idea of using every tool at your disposal to accomplish those controls necessary to maximize the performance of any system. Just as a machinist or carpenter needs to be careful with the tools he uses, so too the PLC programmer must be careful with his tools!

Speaking of carpenters, (in general) there are three types of carpenters:
Rough Carpenter (Framer)
Finish Carpenter
Cabinet Maker
Each has their own set of tools. Assuming that the talents of each is restricted to their particular craft, you shouldn't ask one to perform anothers' specialty. You know what you get when you as a ask a Framer to build a Coffee Table (remember 4x4 furniture? Quaint!).

The analogy that I'm trying to present is not about the people, but rather, their tools and the particular talents required to use those tools.

Each set of tools and talents needs to be brought to bear in their turn. The task is not done until the Cabinet Makers' tools are brought to bear.

The Rough Carpenter can work with tolerances of +/-1/8".
The Finish Carpenter can work with tolerances of +/- 1/16".
The Cabinet Maker works with tolerances of +/- 1/32" or even 1/64".

If you consider the job done after the Rough Carpenter is done, then you should expect results no better than a Rough Carpenter (stress on the "Rough") can provide.

Likewise for the Finish Carpenter.

It is only after the Cabinet Makers' tools are brought to bear that the job is really done! (Of course, this assumes that these guys are good at their jobs.)

Bottom Line?
Use all of the Tools and Talents you can get your hands on to produce the best product you can!

Now, back to the subject at hand...

Comments are certainly required for those that get into the program.
It is very easy to make comments for programs that are reasonably organized (modularized, or at least, for smaller systems, properly ordered).

If you write spaghetti-code, you deserve all of the grief that comes your way. Of course, the backlash of spaghetti-code, even if you understand it, is that no one else will understand it! Even if it is commented!

Good Code almost comment's itself! (But don't let that stop you from actually entering the comments!)

The whole battle about how simple to keep code is generated because there are, in general, three different perspectives when it comes to programming and maintaining PLC's.

The three perspectives are...
OEM (Original Equipment Manufacturers)
Contract Programmers maintaining any number of different systems.
In-House Programmers maintaining Local Systems


The OEM wishes to maintain code in as much of a cookie-cutter fashion as possible. This is entirely reasonable. Sometimes, however, the OEM has to build a one-off (one-of-a-kind). Again, the OEM tries to keep the code as close as possible to the House-Standard. This practice is primarily designed to make things easier for the OEM. From the OEM's perspective, it is simply more efficient to do. I can't complain about that too much... after all, the OEM is in the game to make money.

In many situations, users are NOT ALLOWED to get into the program; only the OEM is allowed. In this case, there is no need to consider the ability (or lack, thereof) of those users that would attempt to maintain the system program. Certainly, Peter does not dumb-down his code so that it is easy for anyone to understand. He needs his code to be only as easy to understand as he requires.

Generally, as time goes on, an end-user usually finds that the OEM code does not provide all of the bells and whistles that an end-user (operator or maintenance) might like to have. Of course, the OEM will have every right to say "Yeah, but we built it to Spec!"

It's almost always the case that end-users don't really know what they want until they come up against a situation where they say, "Gee, I wish it would..." do this or that. They simply didn't know they were going to need it when they provided the spec.

In this case, if the code is closed, the OEM is contracted to provide the necessary changes. And again, the OEM will build to spec - you should expect no more, no less - a contract is a contract! The OEM is under no obligation to make the code easy for the local maintenance folks to understand - the code is closed. The OEM will, and should, make the code according to their own in-house rules. And so it goes...

If the code is open, then you might get a hold of a "Contract Programmer". And again, the code will be fixed, changed, updated, whatever, according to the agreed spec (or, at least it should be).

The result depends on how good this programmer is. A decent programmer will build the code in a reasonable fashion. If the changes require the use of a For/Next function, then the programmer should use it and explain how it's being used.

On the other end of the spectrum, you have your In-House Programmers. We are on-site, day-in and day-out. We have to suffer, on a daily basis, the consequences of the code we write. Those in-house programmers that care about what they are doing to the production folk and maintenance folk take it to heart when they hear complaints about this or that aspect of the code.

We also have time to contemplate more effective ways to do this or that. Some of the systems we work on are forever in development. We are also on-hand to explain to the operators and the maintenance folks how this or that works. I usually write up a "Technical Flash" explaining any new changes to the program and provide it to the operators and the maintenance folks.

I do not like phone calls at 2:00 AM and I do everything I can to prevent them from happening.

So, from my perspective...

K.I.S.S. ? ? ? ? Keep It Stupid, Simpleton ???

I say BULL! I also say...

K.I.C.K.A.S.S. ! ! ! !

Keep It as Complicated and Knowledgable As necessary to Support the Stategy!

When I design code, I make it only as complicated as it needs to be in order to accomplish the goal. I do not limit myself to using only those tools that everyone knows how to use.

If someone doesn't understand what's going on simply because the code is beyond their intellectual capacity to grasp (despite the comments, and I do make pretty good comments)... well... I can show them where the programming and math books are - then it's up to them. In terms of actual applications, I will not slow down for stragglers!

Anyone that is responsible for maintaining equipment and then, does not take the steps (intellectual steps) necessary to provide that maintenance should be replaced.

I go to great lengths to provide troubleshooting tools for the operators and/or maintenance guys. These are screens that are designed to indicate the status of all I/O for all system modules. Operators can call up a screen at any time, or, when a fault condition occurs, a screen pops up automatically.

One of the more helpful screens I have comes up when an operator tries to do something but the system won't allow it. If the operator pushes a particular button trying to perform a particular action, the screen pops up and indicates why the program will not let the action occur.

If a fault condition occurs, a screen pops up automatically, indicating the affected module and provides a "Go to Page #" for more details and possible solutions.

If operators and maintenance folk choose not to take advantage of the tools that are provided, what can you do?

At some point, after trying to make the program as idiot-proof as possible, you are faced with the need to get rid of the idiots!

This position can be taken only by those programmers that recognize that a programmers responsiblity is to use whatever coding is necessary to make the system as easy as possible for the users - not the programmer! Minimalist Programmers are the Bane of Operators and Maintenance folks!

[Peter Nachtwey]

>Certainly, Peter does not dumb-down his code so that it is easy for >anyone to understand. He needs his code to be only as easy to >understand as he requires.

I certainly don't dumb down code. Here at Precision Pickle Company we slice pickles with precision and fanaticism. Sometimes this requires code that is can be quite advanced. However, I feel it is better to raise people up than dumb code down. I don't work alone so, as stated above, it is very important to document the intent.

[Terry Woods]

Roger-D !

[rsdoran]

RS, do you really mean this? Should the automobile have been suppressed so blacksmiths could carry on making horseshoes? Should electronic fuel injection be banned because carburettor technicians don't want to know?

No, but those that chose to learn how are to be commended. Should those that dont know HOW be forced to? Should the blacksmith be forced to learn autos after spending a life learning to be good at what he does? We are talking choice here, your choice will affect hundreds maybe thousands of "skilled workers" now and tomorrow. You have the choice of writing 20 lines of code that many can understand easily or maybe 10 that uses advanced features that noone but you (maybe another programmer) can understand ever.

As Terry ( who is by far the most eloquent) stated, you use what is needed when needed with (hopefully) documentation to say what/why.

Here is how I see it, most electricians/maintenance can understand and deal with relay logic. That is what I dont understand, when RELAY LOGIC was prevalent so many didnt understand, so many devices used and large panels needed for the simplest machine. Today though it seems the olders guys (like me i guess) can understand relay logic and anything that resembles it. I dont know why any spec would state not use any form of timers/counters because they have been around for 40 yrs or so.

The thing is we understand RLL. The new features available with plc's make it more difficult, which for some means at age 50 or so with wife, kids etc we have to learn more more more, just to maintain our jobs. The new kids understand the programming stuff but are worthless overall for the old stuff or just plain electrical/electronic diagnostic/repair work (from lack of experience mostly). Thing is they wont stay long enough to learn the electrical part ( or in some cases the company wont put them in the postition). The bad part is after years of doing what is needed by the electrician/mechanic the programmer can make more money because they can understand just the programming and none of the electrical/mechanics. You understand how that works dont you, they make/fix the program but need the electrician/mechanic to understand precisely what is needed when it is needed.

Gerry, I dont know what you meant by your use of the term "unwashed masses". Most here are in some way either an Engineering graduate or in an Engineering position. I am not, I am an hourly worker that has to deal with a multitude of machines, plcs, and electrical/electronic devices...ie one of the unwashed masses I guess that has to understand what y'all have done with the plc.

This thread took a turn somewhere, the guy just needed to cycle 11 compressors. This isnt a complicated process (even for me) why the need for all the fancy ****? For/next loop, indirect-indexed addressing...gonna use C, C++ etc whats next? Why would anyone one thats not familiar with the machine(s), plc's, plc programming and results worry about all this FOR/NEXT, indirect/indexed etc etc etc. Why start there? A spec was stated DONT USE by him and another...is it written in STONE?

Shouldnt a more in depth look at the process be warranteed OR trying something like a sequencer (drum comes to mind cause us unwashed masses understand them) be used at first? Technically what I have observed is that more input devices are needed for a more accurate way to control what is being done.

Just another case where the electrical/epa/hvac certified guy is overwritten by the "kid" that knows how to program but doesnt have a clue about the system.

[Gerry]

Well, I agree no blacksmith should be forced to give up making hoseshoes. The key concept here is force. But nobody should be forced to keep buying horseshoes either.
As you say, Terry is very well spoken and, may I say, verbose. He also says, and I quote, " At some point, after trying to make the program as idiot-proof as possible, you are faced with the need to get rid of the idiots! ". And to quote Peter, "I feel it is better to raise people up than dumb code down".
This thread has gone off on a tangent, but rather interesting, don't you think?
The issue of program documentation has been expounded. This is a vital component of any system, no argument from me. It is, however, quite a separate issue from whether or not for/next loops should be censored.
In this business, as in many technical fields, one cannot afford to stop learning. Age accords you experience, but that is not sufficient, on its own, to keep you up with the play. FYI, I am pushing 56, I graduated (with a diploma, not a degree) when nobody knew what a PLC was or might become (except, perhaps, Morley & Strueger).
In mentioning 'unwashed masses', I was presuming to speak for the attitudes of those who would make restrictive rules. You are right to be insulted by such an attitude, but please realise that it is not MY attitude.
And then we get back to the original problem - how to keep everybody comfy without spending any money. Every project has to contend with the eternal triangle of specification, time, and cost. A supplier knows you can't manipulate one side of the triangle without affecting one or both of the others. Consumers tend to be oblivious. So, Micrologix 1500, some thermostats - you need to reduce the spec, take an enormous amount of time, or spend a bit more money on hardware.
I could care less if Don uses loops, sequencers, or a truck-load of timers in his system - it's HIS system. I DO object to him being advised to avoid valid techniques for invalid reasons. And if he takes a fuzzy logic approach, I will cheer him on!

[Terry Woods]

I posted this reply just a few minutes ago but it disappeared!

Don,

I've considered your HVAC problem over the last several days (with a few distractions along the way - Ain't TANGENTS GREAT!!) and have come to a conclusion or two...

Without using Temperature Sensors to determine which room has a legitimate need, you can not determine when someone has the thermostat set to 40-Below! Should that room have a higher priority simply becqause its thermostat is calling for cooling all of the time???

You might just as well let Mr. BIG have all the AC. Then, you might consider buying a bunch of those hand-held, battery-operated fans for the rest of the unclean-losers (dry-ice seat cushions?).

Under that condition, I can't think of any fair, equitable and consistent way to distribute the available cooling energy to the rooms that really need it.

Another good reason for using Temperature Sensors is so that you can determine which rooms are acting like Heat-Sinks. Those rooms will need special attention! At least, until you get them better insulated.

Your best chance might be to use a sequencer. It's easy enough to determine all of the legitimate patterns. If you have a room that needs a priority, ensure that the patterns for that room occur more often. Some rooms will already show up in multiple patterns.

I still think that Fuzzy is the way to go. Fuzzy is real good at handling any dynamic changes in the multitude of relationships. And you can add all of the flavorings you want (Positive or Negative priorities) on a dynamic basis if you wish.


TANGENT ! ! !

Whadaya mean Verbose???

I thought the word "Eloquent" was more appropriate! (Look it up!)

And HEY!

Did anyone make it down through all that there verbosity to see K.I.C.K.A.S.S. ? ? ?
I thought it was kinda cute! Made it up myself, don cha know?

I recognize that only those in my position can appreciate it.
What I worry about is that I'm the only one in my kind of position!

[New2PLCs]

Terry,

I've been waiting for you to comment on this again. And ultimately you let me down by coming to the same conclusion everyone else has: I'm screwed. ;) Actually, your first post indicated that you immediately understood the nature of the problem, which was a step ahead by itself. I don't mean to offend anyone here, a lot of people offered great comments and suggestions and I really appreciate the consideration it was given. It's not a problem that at first glance looks near as unmanageable as it has proved.

I'm not sure if you missed my last post in the "Energy Management System" thread, but I offered some additional thoughts on the problem (and ultimately an "algorithm" for the ladder program.) I think your case where one zone's thermostat is set to 40-below is handled, though maybe you see some problem that I don't. Would you please let me know if this is the case?

Here's the algorithm I ultimately worked out:

<blockquote><hr>I'm thinking of setting up each of the compressors with a starting priority, 1-11, with 11 being the most important. I've got 1 timer per compressor. When a thermostat calls for cooling AND the compressor kicks on successfully, I'm going to use that timer to lock that compressor in for a predesignated minimum amount of time. As long as the thermostat is still calling, it gets to run for X minutes. Now, if the thermostat is calling for cooling but the compressor can't come on due to load restrictions, I'm going to use the timer to start counting 5-minute (arbitrary number) intervals. For every 5-minute interval, I'm going to take the compressor's starting priority, add 2 (arbitrary number), and store it as an overall priority for that compressor. When any compressor's overall priority gets high enough, it's allowed to shut off any compressors for which the overall priority (when it last kicked on) is lower, provided that the running compressors have been allowed to run for their minimum time. The overall priority for a particular compressor gets reset to the starting priority for that compressor once it has run.

...

While my head spins when I think of trying to implement this in ladder logic, it should be possible, and I think it is about the best one can do, given the nature of the problem. I think there are enough "fudge factors" to ensure an adequate amount of "tweakability":

1.) Starting priorities for each compressor
2.) Minimum time each compressor can run
(My tactic for handling the case where a large compressor gets locked out for a longer period than desired is to just increase it's minimum time--it will eventually come on; when it does, let it run longer.)
3.) Time interval length after which you increase overall priority when a unit has been calling but not allowed to run due to load restrictions
4.) Amount that you increase overall priority per interval for which a unit has been calling but not allowed to run<hr></blockquote>

In your case where a particular zone is always calling for cooling, the corresponding compressor will inevitably get a chance to run (as long as it's waiting and not getting to run, it's priority keeps going up until it gets high enough to where it will kick out a lower priority zone once that lower priority zone has run for a preset minimum time.) However, once it runs, it's "overall priority" gets reset to it's starting priority, so other zones that have been wanting to run, will now (eventually--how quickly is adjustable by fudge factor #4 above) have a higher overall priority and until they each have a chance to run, the zone set to 40 below will be forced to wait it's turn (until it's priority is high enough AND the others' minimum time is up.)

Now, I may have completely misunderstood that overview on fuzzy logic that you pointed me to, but it SEEMS to me like I'm doing something of the sort with this algorithm. I have a lot of flexibility in my fudge factors for tweaking the system, and my system sort of balances itself out the best it can when it gets lopsided. (Or so I think.) It takes a situation with a lot of factors that in worst-case scenario will never be "good", and (hopefully) makes the most of it in the majority of less than worst-case scenarios.

[The reason the system prompted this other topic (the simulating FOR..NEXT loops--which I understand is not an optimal or "natural" programming technique in ladder logic, as so many were quick to point out) is that I am examining all the inputs (thermostats calling) in one ladder scan, and I need to determine within this one scan (loop through and calculate load for all running compressors whose minimum runtimes have been satisfied) if the compressor with the current highest priority has enough load space (compressors it's allowed to shut off) to run. A little messy perhaps, but when I contemplated doing trying to do it without looping in this way, a sharp pain shot through my head from temple to temple. My original plan was actually to loop naturally WITH the program scan, checking each of 11 compressors every 11 scans, but timers and one-shots didn't like it when I tried to use indirect addressing with them--how unfriendly!]

Thanks again for all the help,

-Don

[Terry Woods]

ALRIGHT !!!
You Pushed the right button!
(Besides, I hate being beat by any mechanical problem!)

This assumes that you are still not going to use Temperature Sensors. Things would be a lot easier if you did!

The main objective should be to bring all rooms to set-point and then baby-sit only those that need it as they need it. In order to accomplish that, I think you need to do some investigating on your own and then have the PLC do some Empirical Data gathering for you. I think you need to know the following:

The capacity of each compressor ( 1-Ton = 12,000 BTU's / Hr )
The cubic-foot volume of each area serviced by a compressor.

Now, calculate the PER** for each compressor...

Comp #1 (12,000 BTU's / Hr ) / 35,000 Cu-Ft = .34 PER**
Comp #2 (18,000 BTU's / Hr ) / 65,000 Cu-Ft = .27 PER**
etc.
** (Phony Efficiency Rating) You may find that some areas are beyond rated size!

This gives you a really rough idea of which compressors are going to be most, or, at least, more effective - but not quite. Now comes the part where your PLC puts on the Sherlock Holmes hat...

This might take a while (a few days?), but as time goes on, the system should get better and better at making the "right" choices, instead of being subject to so much arbitrariness. The name of the game is to use the energy as efficiently as you can. And, thereby, reduce the over-all call for energy at all!

So... Using whatever priority system you want to use, have the PLC start to keep track of how long it is between a demand going off and the same demand coming back on. It might be seconds, minutes or even hours (though, not likely).

You also need to track how much longer the compressor ran AFTER the demand went off. This will give you a relative indication of how effective an area is at "keeping its cool".

As time goes on you will be able to identify the lesser efficient areas (Get them insulated!).

You should then be able to develop a regular routine for the more effective areas and service them BEFORE they call for it. "On-Time" for those areas should be predictable.

Meanwhile, as problem-areas issue calls for service, you can sacrifice some of the regular service time for those. This should be OK since you should be ahead of the game with the more efficient areas.

That's my best shot! Now, if you want code, let's talk!

[New2PLCs]

Terry,

<blockquote><hr>That's my best shot! Now, if you want code, let's talk!<hr></blockquote>See subject line. :) Actually, I have <u>finally</u> got my code working (I think) the way it needs to in my main sequence, now I just have a couple more parts to tie down, one of which seems a bit tricky, as I'll explain below.

<blockquote><hr>ALRIGHT !!!
You Pushed the right button!
(Besides, I hate being beat by any mechanical problem!)<hr></blockquote>Just keeping you on your toes, man. ;)

<blockquote><hr>Now, calculate the PER** for each compressor...

...

** (Phony Efficiency Rating) You may find that some areas are beyond rated size!<hr></blockquote>Ok, this PER of yours would be reflected in the value I am increasing my "overall priority" by (for a particular compressor) for every time interval that the thermostat is calling but the compressor can't come on due to load limits. I can adjust (or have the PLC adjust) this value for each compressor; currently I get the values dynamically from a data file. For now, however, I am going to assume the PER for each unit/zone is the same (probably a grossly invalid assumption, I know, but bear with me one more sec.)

The only adjustment I'm going to put into the program to start with is one where the PLC keeps track of the number of times in one day that a compressor is turned off while the thermostat for that zone is still calling for cooling. If the number of times that happens exceeds say 3 times, it will assume that this zone is just not getting cool enough with the minimum runtime (time for which the compressor <i>has</i> to be allowed to run) currently allotted to the compressor and it will bump up the minimum runtime for that compressor accordingly (not to exceed a certain value.) Then after a few days of running, I can evaluate whether or not the system is working effectively by seeing if any of the compressors have maxed out this runtime.


OK. Though the way you outline doing the system doesn't exactly match my own, much of it is similar and I get the feeling that it will work at least somewhat well (i.e., within the given constraints.)

The part I'm currently stuck on is logic to turn off compressors when another has reached a higher priority. I have to go through the list of compressors that are allowed to be shut off (the ones for which their "minimum runtime expired" bit has been set) and determine whether or not the load space that would be freed up when they shut off will let my "waiting" compressor run (otherwise, there's no point of turning them off if the thermostat is still calling.) I thought about loading a FIFO with the index of the compressor instead of setting a bit to indicate when a compressor has run for it's minimum time and can now be shut off, but I would need to be able delete values from the middle of that FIFO when it came time to actually shut the things off, a seemingly most unnatural way to do it. I'm looking for a better option.

I need a good way to keep a "list" of compressors (the ones that can be shut off) where it's easy enough to delete any value within that list. Also, this is a tricky part that requires (I think) looping within a scan, since I sort of need to determine in that scan if I'm going to shut a unit off or leave it run.

Whew. What a nice, fun problem.

-Don