Strange VAR behavior

Tschmidt

Active Member
One of the features of my greenhouse controller is to send an email at 6AM and 6PM each day logging the min/max internal temperature between emails.  Randomly the low temperature value was incorrect rather than being min for the entire period it is getting reset to current temp sometime through the 12hr period. The way my code works is once the email is sent, VAR1 is set to 1000 and decremented each pass through user code. When it gets to 0 min/max value for previous period is reset. This provides enough time for the email to be sent before the values are reset.
 
Controller is WebControl  v03.02.17d (early version no boot loader). I added some debug code to send a test email each time the min/max temperate gets reset. I'm using VAR1 for three purposes: If VAR 1 is 0 - new min max value set, if value is 1-1000 delay routine that allows email to be sent before temp values are updated, and value of 1001 indicates email has been sent and to accumulate current min/max value during the 12 hour period.
 
What I'm seeing is VAR1 randomly gets reset to 0. Double checked the only time my code does that is when value is decremented after 6AM and 6PM email sent. As a test moved VAR1 code to VAR8. Did a one time set of VAR1 to 1234. Problem still occurs using VAR8 and when it does VAR1 is reset to 0.
VAR reset occurs at multiple times of day and some times when it occurs my test code sends a single email but some times more than one indicating the VAR is being reset for multiple passes through user code.
 
Hard to believe this is a WebControl FW bug, since it is pretty significant and others would have noticed but I cannot fine anything wrong with my code.
 
 
 
Here is the fragment of my code.
VAR8 - Email delay state: 0=set min/max temp to current, 1-1000=temp reset delay, 1001 email sent
 
 
EMSTATUS:
    TSTEQ    VAR8 0
    GOTO    NEWMINMAX ;set new 12 hr min/max value
    TSTEQ    VAR8 1001
    GOTO    LOGGER    ;update 12 hr min/max value.
    DEC    VAR8
    RET

NEWMINMAX:
    EMAIL    EM6 :test email
    DELAY    5000 ;blocking delay for test email
    SET    VAR8 1001    
    SET    VAR4 T2 ;max inside temp
    SET    VAR5 T2 ;min inside temp
    RET

LOGGER:
    TSTGT    T2 VAR4
    SET    VAR4 T2
    TSTLT    T2 VAR5
    SET     VAR5 T2
    TSTEQ    CH 6
    GOTO    MORNMAIL ;send 6AM email
    TSTEQ    CH 18
    GOTO    EVENMAIL    ;sent 6 PM email
    RET

MORNMAIL:
    TSTEQ    VAR6 18
    RET

    EMAIL    EM7
    SET    VAR6 18
    SET    VAR8 1000
    RET    

EVENMAIL:
    TSTEQ    VAR6 6
    RET

    EMAIL    EM8
    SET    VAR6 6
    SET    VAR8 1000
    RET  
 
 
 
 
 
 
 
 
 
Thanks for reporting the issue. If you have a board with different firmware version, you could try to see if they work better. The problem could happen in some testing version firmware, but not in earlier or later firmware.  We made a few testing firmware for a few customers for their needs. Then based on customers feedback, we might remake that release with a later build date.  I don't remember if we made special testing firmware for you for that particular release date.
 
Since 3.02.17e firmware, thanks to AZ1324, we started shipping firmware with bootlaoder. That makes the testing firmware update a lot easier.  If your board does not have bootloader, we would recommend to send in for update with bootloader, so that you can always update to the latest firmware, if you found any issue.
 
This is standard CAI firmware. This is one of the three boards you updated for me in late June.
 
Swapping boards is a pain because I soldered a wire to the flashing LED to drive some external indicators. The only other WebControl FW rev I have is 3.02.17b, but that is being used for wood heat controller.
 
What I'll do next is set up another rev v03.02.17d board naked, connected to a 1-wire temp sensor and run just the temp update email code and see what happens. Not as good as swapping out the entire board but much easier.
 
It's too bad I just missed the bootloader FW update. Would be nice to try the latest and greatest FW to see if the issue is resolved without having to send back the board.
 
If anyone else has seen strange VAR or RAM behavior hopeful they will chime in.
 
/tom
 
Just wanted to post an update on my VARx reset problem.
 
I have not set up the test system yet because so far, since I made the initial post, problem has not reoccurred. Perhaps it is monitoring this user forum. :)
 
I still have test code running that sends out an email each time temps get reset and I manually set VAR1 to 1234 or 4321 each time it gets reset back to 0. So far everything is working correctly, no anomalous resets.
 
I though it might be noise on the 9V supply because I'm using a FET to switch the humidity fan, tested that theory by toggling the fan multiple times without problem.
 
I'll keep monitoring - I hate when problems stop without knowing root cause.
 
/tom
 
I had strange thinks happen whan sending email and vars. I had var1 and var2 record hi,low temp of day and reset at 11pm. Found out it was not the board but something was causing board to reset (power supply or spike from storm)that is why.  I put a email to let me know if board reset.
 
Code:
START   
        email em1 ---this is the first thing it does if it restarts
        delay 2000
	SET OP1 0  
	SET OP2 0  
	SET OP3 0  
	SET OP4 0  
	SET OP8 0  
	SET RAM1 0  
	SET RAM2 50  
	SET RAM7 0  
	SET VAR3 0  
	SET VAR4 2000  
	SET VAR8 0  
	SET RAM4 665  
	   
LOOP:
	TSTEQ CT 23:59:0  
	CALLSUB RESETVAR
 
In firmware 3.02.16c and 3.02.17 (without letter after 17), there was a compiler bug that could cause problem. The compiler bug was not did code optimization correctly.  We fixed it by reducing queue sizes, and remake the firmware.  In older firmware, this problem does not exist, because our feature sets not reached to RAM limit yet.  In later firmware, like current shipping 3.02.17d/e/f, this problem had fixed.
 
If your board has this problem, please send it in for update with a latest version.  That will also get bootloader on it for easier firmware update in the future.
 
Just wanted to update my old thread about this problem.
 
The intermittent greenhouse problem has reappeared. I added some debug code to the Greenhouse and Wood heat controller. One of the roles of the wood heat controller is to monitor Greenhouse 5V and a freeze alert signal to generate an audible alert if the greenhouse is in danger of freezing.
 
The wood heat controller reports occasional greenhouse 5v failure  but usually the greenhouse controller is fine. But finally have had several instances where the wood heat controller flags loss of greenhouse 5V and the greenhouse controller reports a reset condition.
 
So now it is a matter of determining root case: 9V SMPS, system wiring, or WC 5V regulator. I'm leaning to the SMPS because when it fails cycles between good/bad for a little while before it stabilizes again for a long time. Systems send one email on each failure event so get 3-4 emails per event over a <1-2 minute time frame..  That implies something with fairly low thermal mass. The fact most of the times the WC does not reboot indicates loss is short enough so 3.3V is not compromised. 
 
Hoping it gets worse to make troubleshooting easier. As much as I would have liked to blame this on CAI firmware looks like a straightforward hardware problem
 
 
Film at 11 - :)
 
/tom
 
 
 
Tom,
 
I suppose your board has latest 3.02.18b5 firmware. If not, maybe consider update to that version. Then check power supply to make sure not having any problem with power. When weather changes, especially when cold weather reached to connectors and wirings, metal shrinks slightly, could make some connection loose.
 
Unfortunately the WC board is fairly old, it was my first project. It is running FW  V.3.02.17d. You guys graciously upgraded three of my WCs as a result of the temperature status bug. Alas I just missed out on the ability to download new FW.
 
I agree it is most likely the power supply. When I get some time I plan on opening it up, wiggling everything and if nothing else shows up replace the power supply and see what happens.
 
/tom
 
Tom,
 
We still offer firmware update services, as long as the hardware rev 2.2.2, it can be updated.  We only charge fee to cover the shipping and handling, for customer inside US with first class package, that is $10.  Other shipping service cost may vary, please let us know.
 
Back
Top