Changing from If..Then to Select Case

Hello group,

I currently have a master board that receives reports from 20 slave boards. When the master
receives the 3 digit number (what input) from a slave card it goes through 320 If Then statements then the Master assigns the actual apartment number then what to do with it after that.

I read somewhere that Select Case uses less program code space than If Then statements but haven't seen anything either here on the forum or the PBP 3.0 manual as to how many cases you can have.

My projects (I have 2 of them) have been running great now since 2005 but I am looking at possible upgrades to the system. I use 16F74's for the slaves and 18F452 for the Masters.

So the main question is, is there a limit as to how many Cases you can have using Select Case and if so, what is the limit?

Thanks in advance!

BobK

Have you considered using a lookup table?
How are the numbers sent to the master? If separately you could save a bunch of typing using select case sub routines 0 - 9, do the same with lookup tables, better than typing 320 if then statements. If not separate you could separate them.

Thanks for the reply Archangel,

In the beginning I looked at a lookup table but didn't know enough about using it so I went with the IF .. Then senario.

There are 20 slaves with 8 inputs on each. They send 000 thru 007 for the first card, 008 thru 015 for the second and so on. The Master then assigns the apartment number and based on the numbers and their grouping, sends the program to the appropriate display/printout routines. The first 160 apartment numbers are grouped by two buildings and then the second 160 numbers represent when the signal has been returned to normal and that gets the apartment number assigned then goes to a printout routine. I have a serial data line connected between the Master and a busy line that controls the traffic.

This is an alarm annunciator system that I built for my customer. There is one panel in the apartment lobby and another is in a nursing station in another building.

Here are a couple of examples:

If B7 = 065 then Apt = 509: goto DispAlarm1 (DispAlarm1 would be for the first building)
If B7 = 082 then Apt = 018: goto DispAlarm2 (DispAlarm2 would be for the second building)
If B7 = 163 then Apt = 107: goto PrntRestore (The PrntRestore routine simply time stamps the return to normal)

The first two types of lines would printout a time stamp showing which building and which apartment and the last line would printout the time and which apartment number has returned to normal meaning the reponder has reset the alarm switch. The Master panel also has a 4 x 20 display and a beeper that shows the alarm information for the office staff.

My experience has been that the if then uses less code space than select case. I had a program with a ton of if then statements in a menu and I was running low on program space so I switched all of them over to select case statements and it compiled using more code space. I went back to if then.

Thanks for the input Shawn. As I'm working on my new ideas I will try a series of variations that are starting to pop into my head. I will keep your comments in mind. Thanks again!

Bobk

Hi,
Just like for Shawn, my experience is that Select Case is "cleaner" code but takes more space than a bunch of IF/THEN. There's one difference to keep in mind though - which may or may not matter:
When you "hit" the SELECT statement it's evaluated and the program jumps directly to the correct CASE and executes that. When you have a bunch of IF/THEN each and every IF statement "in the list" is evaluated and the ones evaluated TRUE (if any will execute). With 320 IF statements it's going to take a different amount of time before the actual code in the "correct" IF/THEN block is executed depending on "where" in the list it is.

As for this code:

Code:

---

If B7 = 065 then Apt = 509: goto DispAlarm1 (DispAlarm1 would be for the first building)
If B7 = 082 then Apt = 018: goto DispAlarm2 (DispAlarm2 would be for the second building)
If B7 = 163 then Apt = 107: goto PrntRestore (The PrntRestore routine simply time stamps the return to normal)

---

Is the GOTO meant to execute only when the IF statement on the same line is true? If so I wonder if it does? I ask because to me (which does not mean it's correct, hence the question) the above looks the equivalent of

Code:

---

If B7 = 065 THEN Apt = 509
GOTO DispAlarm1

---

Meaning that the GOTO will execute unconditionally. If the GOTO should execute only when the IF statement is true I would have expected it to be

Code:

---

If B7 = 065 THEN
  Apt = 509
  GOTO DispAlarm1
ENDIF

---

Could you clarify this for me?

/Henrik.

I agree with the others - IF THEN will be less code than SELECT CASE, however a couple of LOOKUP statements will be even less. I'm not sure if the mapping ever changes, but you could even track the mapping in Excel making updates easier. This is the sort of situation that LOOKUP (or LOOKUP2) was designed for.

Thanks for your replies Henrik and Charlie.

Yes the GOTO is only executed if the If Then is true. Doing it this way eliminates the End If statement for each line. At the time I tried this several different ways and this worked out fine. This system was designed back in 2005 and has been working fine since. I just recently had a situation where the printer output stopped working and since I cleared up the problem my brain juices told me to look into potential upgrades to the system so I am going over the code for the Master and Slaves to see if I can't make this any better. The system could go for months without any alarm activations so the speed of the system going through the IF Thens is really not a problem. I am only looking at less the a couple of seconds and that is nothing in this case. The only reason I though about the Select Case is I thought I read in a code optimization article that it used less code than the If Then hence the inquiry.

I really appreciate all of the replies and for you folks taking the time to help me. I will let you know how things work out.

Thanks again,

BobK