Switch Case statement Doubts

John Paul

I am facing a compiler error when i run the commented sections of the code in the axi file which i have attached in this post.

I want to run a switch case where each case will be integer values or char values in a structure array. I am getting the following errors, if anyone has a workaround i will be thank full . If else statements compile fine.


ERROR: C10591: CASE value is not a constant

Morris

Hi,

Im no guru (really Im just beginning but I'll have a crack). It seems to me that the value after the CASE keyword needs to be a constant not a variable as it is in your file. I believe this is the same as the switch-case in Java.

Morris

DHawthorne

Yes, that's exactly it. The identifier on the CASE statement needs to be a constant.

regallion

You could use Select / Active to do what you want:

      SELECT
       {
	    ACTIVE(GET_LAST(nHVAC2FKLRBtn) == nSetpointTemp):
	    {}
	    
	    ACTIVE(GET_LAST(nHVAC2FKLRBtn) == sRoomTempAddress):
	    {}
       }

I'd probably stick GET_LAST(nHVAC2FKLRBtn) into a variable first so it's not re-evaluating every time.

John Paul

Thanks for all the inputs. If you open the axi file i have attached, instead of passing values to the each case, i want to pass them via a structure so that if the values change in future, i can change in only one area.

For example , CASE uHVAC[2].nSetTemp: . This case is same as CASE nSetpointTemp:, which compiles properly.

ericmedley

I don't think it's a case of it compiling or not. It's a case that the value of a case 'whatever' needs to be a constant. I don't think you can change the values of 'whatever' on the fly. You can change the values in a select/active, however. A select/active is a slower process than a switch/case but you do get more programming flexibility such as the case of your idea.

When you put variables in the case statement it is built with whatever value that variable is at startup.

jjames

When evaluating anything (not just in code, but anything), you have a defined set of constant parameters that prove true or false. You can't by nature say "the grass is green" and expect that statement to be true all the time - because it can be brown. So you'd say "the grass is green OR brown", in which case you can use select/active or stack your cases.

You *must* have a constant, non-variable thing to compare against when evaluating ANYTHING - again, not just in code. You can't compare an apple to an orange if the apple can be a grape sometimes.

While I always try to push the bounds of NetLinx, in this case I suggest you try re-evaluating your programming logic instead of the nature of how NetLinx works.

ericmedley

jjames wrote: »

When evaluating anything (not just in code, but anything), you have a defined set of constant parameters that prove true or false. You can't by nature say "the grass is green" and expect that statement to be true all the time - because it can be brown. So you'd say "the grass is green OR brown", in which case you can use select/active or stack your cases.

You *must* have a constant, non-variable thing to compare against when evaluating ANYTHING - again, not just in code. You can't compare an apple to an orange if the apple can be a grape sometimes.

While I always try to push the bounds of NetLinx, in this case I suggest you try re-evaluating your programming logic instead of the nature of how NetLinx works.

I agree with this sentiment. Usually when I find myself raging against the machine that is Netlinx, I really need to rethink how I am approaching the problem. The sooner I push myself through this process the sooner I can get on with something useful.

jjames

After re-reading my comparison . . . I guess I should have used grapes & raisins, eh?