Conditions not being met - what's going on

[Scampy]

Hi Guys,

I have a strange thing going on with my code and I'm stumped as to why this is happening.

I have several word variables:
B_PWM
B_MAX
B_MIN

The values of two of these are set as follows:

B_MAX= 4095
B_MIN= 0

I then have several case statements that are selected using the "IF THEN" statements

if counter1 => blue_on_time and  B_PWM < B_MAX then
Blue_day_cycle = DAWN
endif

The case statement is thus (I've removed nested IF THEN statements within the statement just in case that was causing the issue)

case DAWN
lcdout $FE,$80+15,"DAWN "  
if pcaPwmValue0 => blue_delay_in then 
    B_PWM=B_PWM+1
    pcaPwmValue0 = 0 
endif
if B_PWM => 4095 then
    B_PWM=4095 
endif
if B_PWM=4095 then    
    Blue_Day_Cycle = DAY
endif

So basically, if the condition is matched where the counter = blue on time and B_PWM is less than B_MAX then the case DAWN is selected. This works, but for some reason when B_PWM = 4095 the cycle doesn't change the DAY as it should. After a lot of trial and hair pulling (it's already gone grey trying to suss this out) I manages to get it to change, to DAY when the B_MAX was removed and changed for hard value

if counter1 => blue_on_time and  B_PWM < 4095 then
Blue_day_cycle = DAWN
endif

I added some diagnostics options to the LCD so I could see what's going on and displaying the decimal value for B_MAX Im getting 65535 which would explain the reason why it was ignoring the comparison as B_PWM would have to equal 65535, but why isn't B_MAX equalling 4095 when the value is set to 4095 in the first part of the code?

The reason I'm looking for a range of 0 - 4095 is I'm using an external PWM chip which has 4095 resolution

[Demon]

I'd GOSUB for a complex CASE with IF statements.

You can also merge the last 2 IFs:

    B_PWM=4095 
    Blue_Day_Cycle = DAY

Robert

[Scampy]

You can also merge the last 2 IFs:

    B_PWM=4095 
    Blue_Day_Cycle = DAY

Robert

Rob,

The case statement is thus (I've removed nested IF THEN statements within the statement just in case that was causing the issue)

I had previously nested the code, but simply changed it to separate statements to rule out that as being the cause. The strange thing is it was all working when the values were all bytes and not words.....

[Scampy]

Is there a way to limit the word size to 12 bits rather than 16. This would then give me 4095 as the maximum rather than 65535

[towlerg]

bitwise AND %0000111111111111

[Scampy]

bitwise AND %0000111111111111

Sorry, could you please elaborate and apply that to the variable ?

[LinkMTech]

I'm shooting in the dark here but...
Is =< or => the same as <= and >= causing the the non limitations?

[richard]

you need some brackets
if counter1 => blue_on_time and B_PWM < B_MAX then
change to
if (counter1 => blue_on_time ) and ( B_PWM < B_MAX) then

[EarlyBird2]

I added some diagnostics options to the LCD so I could see what's going on and displaying the decimal value for B_MAX Im getting 65535 which would explain the reason why it was ignoring the comparison as B_PWM would have to equal 65535, but why isn't B_MAX equalling 4095 when the value is set to 4095 in the first part of the code?

B_MAX is being set somewhere else in your code? Or it would be 4095 surely.

[towlerg]

Is there a way to limit the word size to 12 bits rather than 16. This would then give me 4095 as the maximum rather than 65535

YourWordVariable = %0000111111111111 & YourWordVariable will limit the word size to 12 significant bits. (4 zeros and 12 ones is 4095)

[EarlyBird2]

B_MAX is being set somewhere else in your code? Or it would be 4095 surely.

Have you solved this? If so I can stop thinking about it and move on. If not what have you found so far?

[Scampy]

Not had a chance yesterday to try and debug the code as I had to build a PC for my son. I hop to have a go at your suggestions later this evening

[Scampy]

Just had a look at the code and something jumped out at me. There was a line that read the data for the stored values from the chip, and this still has the structure for when I was using a Byte for the values. So this was corrupting the values for B_MAX and over-riding the manual values set. Commenting out the gosub read data line and the manual values I had set work. So I can set B_MAX to 3000, 4000 or 4095 and when it reaches these values it trips to the DAY case...

Time to look at that data section later tonight I think