Non-Blocking Delay On Input Help

[cwb212001]

Hi,
 
I have a TSTEQ IP2[5000] 1 that isn't waiting the 5 seconds before going true.  I've read Lou Apo's explanation of Non-Blocking Delay and the way I understand it is IP2 has to be equal to 1 & it has to be equal to 1 for 5000ms before being true and executing the following line.  I did some testing as described here with a LED and it is instantly turning my LED on (as well as sending my email).  I've posted my code below... I'm sure there is something simple I'm missing.  Any ideas?  My FW is 03.02.17.
 
START    
    CALLSUB INIT_VARS   
BEGIN:
    CALLSUB CHECK_IP1   
    CALLSUB CHECK_IP2   
    GOTO BEGIN   
    END    

INIT_VARS:
    SET VAR1 0  
    SET VAR2 0  
    RET    

CHECK_IP1:
    TSTEQ IP1 1  
    SET VAR1[30000] 1  
    RET    

CHECK_IP2:
    TSTEQ IP2[5000] 1  
    CALLSUB CHECKVAR1   
    RET    

CHECKVAR1:
    TSTEQ VAR1 0  
    CALLSUB SENDEMAIL   
    RET    

SENDEMAIL:
    BNZ VAR2 BEGIN  
    SET VAR2[30000] 1  
    EMAIL EM1                           **Replaced with SET OP1[5000] 1 for testing**
    RET  
 
What I'm trying to do with the code is send an email every 30 seconds if IP2 is activated for more than 5 seconds as long as IP1 has not been triggered.  When IP1 is triggered it blocks the email for 30 seconds.
 
I appreciate any help and ideas you might have!

 

[CAI_Support]

Which sub version of your firmware, is that 3.02.17d, 17e, or just 17?
We have changed the non-blocking delay on IP in the 17f, so that it can have both directions, i.e. 0->1 pulse, or 1->0 pulse,
Non-blocking delay on OP is not changed.  If your board has bootloader, we can send you update firmware to have the new change in it, otherwise, you will need to send back for us to re-program it with bootloader and newest change.

 

[cwb212001]

Thanks CAI, I will probably take you up on that.  That looks like that's what I need.  The web GUI shows plain .17; it was purchased in 03/13.  I will contact you through the website for instructions.  Thanks for the quick response.

 

[CAI_Support]

Having board updated with latest version with bootloader will ensure you can always get latest firmware update easily.  We do encourage everyone running latest firmware.  The latest firmware has a lot of enhancements.

 

[az1324]

SENDEMAIL:
    BNZ VAR2 BEGIN  
    SET VAR2[30000] 1  
    EMAIL EM1                           **Replaced with SET OP1[5000] 1 for testing**
    RET
 
don't branch out of a nested subroutine

 

[cwb212001]

SENDEMAIL:
    BNZ VAR2 BEGIN  
    SET VAR2[30000] 1  
    EMAIL EM1                           **Replaced with SET OP1[5000] 1 for testing**
    RET
 
don't branch out of a nested subroutine

 
Curious why I shouldn't branch out of a nested subroutine... what happens?  It seemed to work okay except for the testing IP1 thing.

 

[az1324]

because CALL has to end in RET

 

[rossw]

because CALL has to end in RET

 
Just to expand on that with a "reason" - a gosub pushes the current address on to a stack, so it knows where to return to. At the end of the subroutine, the "return" instruction pops the source address off the stack and things resume.
 
If you jump out of the subroutine, the return address never gets popped of the stack. The next time you call the subroutine (and don't "return") the stack gets further depleted. When the stack is full, either your code won't be able to call the subroutine further (or potentially ANY subroutine), or you get stack corruption, or the device just crashes and (hopefully) reboots, or any number of "bad things".

 

[CAI_Support]

Thanks az1324 and rossw for accurate explanations!

 

[cwb212001]

Gotchya.  Thanks guys!

 

[pittom]

so this is bad ?  
 
 
COUNT:
TSTEQ RAM8 1  
RET    
INC VAR8   
SET RAM8 1  
CALLSUB RESETCT   
RET 


 
ON:
SET OP4 1  
CALLSUB COUNT   
TSTEQ OP8 0  
CALLSUB SENDmail   
RET  

 

[CAI_Support]

You can have up to 8 level CALLSUB, but each SUB must end with RET, so that the stack is properly popped back.

 

[pittom]

ok thanks,   so this is better?
 
 
on:
        set op4 1
 
TSTEQ RAM8 1  
RET    
 
INC VAR8   
SET RAM8 1      
 
TSTGE RAM3 CTS  
RET    
 
SET RAM3 CTS  
ADD RAM3 9 RAM1
 
        tsteq op5 1
        ret
        tsteq var1 0
        email em4
        set var1 1 
RET   

 

[cwb212001]

So... this is what I came up with as an alternative to my branching out of a subroutine code.  Please let me know if anyone sees a problem with this... other than my TSTEQ IP[5000] 1 issue I'm working on.
 
Thanks,
 
START    
    CALLSUB INIT_VARS   
BEGIN:
    CALLSUB CHECK_IP1   
    CALLSUB CHECK_IP2   
    GOTO BEGIN   
END    

INIT_VARS:
    SET VAR1 0  
    SET VAR2 0
    SET IP1 0
    SET IP2 0  
    RET    

CHECK_IP1:
    TSTEQ IP1 1  
    SET VAR1[30000] 1  
    RET    

CHECK_IP2:
    TSTEQ IP2[5000] 1          *Try TSTEQ IP2[5000] 0*
    CALLSUB CHECKVAR1   
    RET    

CHECKVAR1:
    TSTEQ VAR1 0  
    CALLSUB SKIPEMAIL
    RET    

SKIPEMAIL:
        TSTNE VAR2 1       
        CALLSUB SENDEMAIL                          
        RET

SENDEMAIL:  
    SET VAR2[30000] 1  
    EMAIL EM1   
    RET  

 

[az1324]

SET IP1 0
SET IP2 0
 
I don't think that does anything.
 
CHECKVAR1:
    TSTNE VAR1 0  
    RET
    TSTNE VAR2 1
    CALLSUB SENDEMAIL                          
    RET
 
Simpler.