PDA

View Full Version : Conditions not being met - what's going on



Scampy
- 19th June 2014, 15:03
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
- 19th June 2014, 15:42
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
- 19th June 2014, 16:19
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
- 19th June 2014, 16:26
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
- 19th June 2014, 18:46
bitwise AND %0000111111111111

Scampy
- 19th June 2014, 19:33
bitwise AND %0000111111111111

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

LinkMTech
- 19th June 2014, 21:20
I'm shooting in the dark here but...
Is =< or => the same as <= and >= causing the the non limitations?

richard
- 20th June 2014, 00:22
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
- 20th June 2014, 07:23
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
- 20th June 2014, 18:00
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
- 21st June 2014, 06:35
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
- 21st June 2014, 11:42
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
- 21st June 2014, 12:15
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