Pull Up resistor wiring

[fcwilt]

You are in the correct forum. I tend to read all new posts regardless of the forum and try to help where I can. So I don't always know the specific prodcut but in this case it was some basic electronics and programming which I know very well.
 
Now you mentioned that before you changed the code the email was being sent once per second. That suggests to me that your bit of code is being called once every second, which is not unusual for certain kinds of automation logic.
 
The question then becomes is how long does the NO output from the keypad stay closed? If it were to stay closed for, say, 2.5 seconds then you would often get two emails being sent.
 
If that is the problem then you need insure that the INPUT has gone back to 1 before testing for 0 again.

 

[siafu]

You are in the correct forum. I tend to read all new posts regardless of the forum and try to help where I can. So I don't always know the specific prodcut but in this case it was some basic electronics and programming which I know very well.
 
Now you mentioned that before you changed the code the email was being sent once per second. That suggests to me that your bit of code is being called once every second, which is not unusual for certain kinds of automation logic.
 
The question then becomes is how long does the NO output from the keypad stay closed? If it were to stay closed for, say, 2.5 seconds then you would often get two emails being sent.
 
If that is the problem then you need insure that the INPUT has gone back to 1 before testing for 0 again.

Thank you Frederick, I appreciate your help,
 
They keypad is programed to for 1 second and the WC is also set for one second.
 
I changed the code to not maker it send emails every one second, basically if input 1 was set to one emails would be sent one after the other, so I reversed that, and emails stoped. Only emial being sent is when someone uses the keypad with the correct code, and this is the way I wanted it.
 
But it always sends two emails for each time the keypad is used one time, and this is what it was doing even before I added the resistor in the loop.
 
Perhaps there is no way to fix this, it's the way it is, just have to live with two emails per code entry on the keypad. Unless there is something that the folks that know the WC in and out,
 
This happens to other applications, for example my button on the intercom, if someone presses it sends two emails per push, if they press  it twi one after the other it sends 4 emails. So I was trying to see if there is a way to fix this as well.

 

[fcwilt]

No it can be fixed.
 
We just have to figure out what is causing it.
 
Try implementing what I suggested. Examine this psuedo-code:
 
  IF INPUT IS 0 AND LAST_VALUE IS 1 THEN
    SEND EMAIL AND SET LAST_VALUE TO 0
  IF INPUT IS 1 AND LAST_VALUE IS 0 THEN
    SET LAST_VALUE TO 1
 
The goal is to respond to the INPUT becoming 0, performing whatever actions you desire, then wait for the INPUT becoming 1 before you begin testing for 0 again.

 

[fcwilt]

OK I found and downloaded the product manual and the programming manual so if you need help I can read through them and give you a hand.

 

[apostolakisl]

My suspicion is you are getting 2 emails because of the "bounce" discussed earlier.  You should be able to avoid this by using the non-blocking delay operator in webcontrol.  Simply stated, the delay operator does to things.
 
1) It checks for the true or falseness of the statement at the time the line of code is read
2) It checks to see if the value of any variables has been altered during the previous milliseconds as defined by the non-blocking delay operator
 
In other words upon encountering this line of code:
 
TSTEQ IP1[100] 1 
 
It checks the current value of input 1, if it is not 1 (false), the statement is false and it move on
if it is 1 (true), it then checks the log to see when the value was set.  If it was less than 100ms ago, the statement is false, more than 100ms ago the line stays true and webcontrol moves on.  
 
An interesting side note: the CAI does not store anything but the current value and time stamp it became that value.  The line of code will always be false if the time stamp was less than delay operator number, even if the old value would also have been true.  (like TSTLT VAR1[1000] 5, even if it was always less than 5, if it changed less than 1000ms ago, it is false).
 
If you were to use the non-delay operator in checking your value, a few millisecond transient on/off could be ignored.  You would have to experiment with how many milliseconds to make the delay.  The key here is how long does your keypad keep the output on?  If it keeps it on for a whole second, then you might use something like 700ms as the email trigger. 
 
 
Below is your original code:
 
START    
    TSTEQ RAM1 0  
    CALLSUB SET_OP1   
    CALLSUB CHK4LOW   
    TSTEQ OP1[1000] 1  
    SET OP1 0  
    TSTGT IP2[700] 0  
    CALLSUB KEYMAIL   
    TSTGT IP1 0  
    CALLSUB DOORMAIL   
    NOP    
    END    

CHK4LOW:
    TSTEQ IP2 0  
    SET RAM1 0  
    RET    

SET_OP1:
    TSTEQ IP2 1 RAM1
    SET OP1 1  
    RET    

KEYMAIL:
    EMAIL EM5   
    RET    

DOORMAIL:
    EMAIL EM1   
    RET    
 
 
Regarding the once per second emails.  It is not because the line of code is executing 1 per second.  That line of code calling for an email is probably executing several thousand times per second, the limit is in the email buffer.  The part of CAI that sends emails simply can not store execute emails any faster.

 

[siafu]

Thank you Lou and Frederick for your help.
 
Lou, I tried the 700ms option on the input, but still getting two emails.
 
In fact I tried from 100ms to 1000ms and getting two emails from 100 to 900 and on 1000ms I get none.
 
Any other option I should try?
 
Thanks for your help.

 

[fcwilt]

OK try reducing to the program to the bare minimum - just check the input and send the email as needed. Remove ALL other code.

 

[apostolakisl]

I read your code.
 
The problem is that you have nothing limiting you to a single email per on event.  Once IP1 becomes 1, every single time the code runs through and gets to the line sending it to the email sub, it sends it.  So if IP1 is on for more than one cycle of the code, you get more than one email.  You need a limiter. 
 
I can't really figure out what your are doing with the other code in there and the outputs turning on/off.
 
The jist of sending only one email per event (IP1 going from 0 to 1)
 
START
TSTEQ IP1[500] 1      (looks for input 1, your door opener, to be on and if so, next line sends you to keymail sub)
CALLSUB KEYMAIL  
TSTEQ IP1 0            (looks for input 1 to be off, and if so, sets ram1 to 0 so that an email can once again be sent the next time ip1 is 1)
SET RAM1 0            
END
 
 
 
KEYMAIL:
TSTEQ RAM1 1   
RET                     (this line aborts the email subroutine if ram1 is 1)
EMAIL EM5
SET RAM1 1    (sets ram1 to 1, so that emailing gets aborted until input1 returns to off causing ram1 to be 0 again)
RET

 

[siafu]

I read your code.
 
The problem is that you have nothing limiting you to a single email per on event.  Once IP1 becomes 1, every single time the code runs through and gets to the line sending it to the email sub, it sends it.  So if IP1 is on for more than one cycle of the code, you get more than one email.  You need a limiter. 
 
I can't really figure out what your are doing with the other code in there and the outputs turning on/off.
 
The jist of sending only one email per event (IP1 going from 0 to 1)
 
START
TSTEQ IP1[500] 1      (looks for input 1, your door opener, to be on and if so, next line sends you to keymail sub)
CALLSUB KEYMAIL  
TSTEQ IP1 0            (looks for input 1 to be off, and if so, sets ram1 to 0 so that an email can once again be sent the next time ip1 is 1)
SET RAM1 0            
END
 
 
 
KEYMAIL:
TSTEQ RAM1 1   
RET                     (this line aborts the email subroutine if ram1 is 1)
EMAIL EM5
SET RAM1 1    (sets ram1 to 1, so that emailing gets aborted until input1 returns to off causing ram1 to be 0 again)
RET

Thanks LOU, your code worked for only getting one email.
 
The output on OP1 is the trigger of the door strike, that opens the door. So now I need to figure out how to implement that to work with the input.
 
I see that you are using a set of RAM (0 and 1) can they be used over and over with other inputs and outputs? Or do I need to use a new set of RAM's?
 
The original code I posted earlier on, was taken from the Cai Webcontrol manual on how to control a switch, and it works fine, just had problem with the email being sent twice.
 
The reason I ask about RAM 0 and 1, is that you used them to resolve the email issue, but they were also used in the OP1 earlier.
 
 
So I just tried the below code, Combination of Lou's email code and original Cai door triggering code that I mused earlier.
 
Now the door triggers, but there is no email being sent at all. I suspect because I'm using the same set of RAM (0 and 1) for both the door open8ing (OP1) and Lou's email code?
 
START    
    TSTEQ RAM1 0  
    CALLSUB SET_OP1   
    CALLSUB CHK4LOW   
    TSTEQ OP1[1000] 1  
    SET OP1 0  
    TSTEQ IP2[500] 1  
    CALLSUB KEYMAIL   
    TSTEQ IP2 0  
    SET RAM1 0  
    END    

SET_OP1:
    TSTEQ IP2 1 RAM1
    SET OP1 1  
    RET  

CHK4LOW:
    TSTEQ IP2 0  
    SET RAM1 0  
    RET    

KEYMAIL:
    TSTEQ RAM1 1  
    RET    

    EMAIL EM5   
    SET RAM1 1  
    RET

 

[apostolakisl]

Yes, you are correct.  You will need to separate your ram's.
 
The easiest approach is to reserve one ram for one job.  But, there are only 8 rams, so you may run out.  The solution to this is to use the bitwise function.  With bitwise, you can use a single 32 bit ram value for 32 different 0/1's.  In other words, you can read and change each bit separately as if it were a separate ram.  So the first bit could be reserved for preventing 2 emails from keymail, the second bit for some other email, and so on.
 
The approach I just used there to prevent a subroutine from running multiple times per event works for any subroutine.  There are lots of times you want a subroutine to only run once per event.
 
EDIT:  with CAI the 32 bit number is signed, so I think you can only use 31 of the bits.  It might be possible to use the positive or negative value of the number as a Boolean value also, not sure.

 

[siafu]

Yes, you are correct.  You will need to separate your ram's.
 
The easiest approach is to reserve one ram for one job.  But, there are only 8 rams, so you may run out.  The solution to this is to use the bitwise function.  With bitwise, you can use a single 32 bit ram value for 32 different 0/1's.  In other words, you can read and change each bit separately as if it were a separate ram.  So the first bit could be reserved for preventing 2 emails from keymail, the second bit for some other email, and so on.
 
The approach I just used there to prevent a subroutine from running multiple times per event works for any subroutine.  There are lots of times you want a subroutine to only run once per event.

Thank Lou, it worked, one email, and door triggered,
 
So I only have 6 more ROM's to use for other functions now. How can I program the bitwise function as you mentioned?
 
START    
    TSTEQ RAM1 0  
    TSTEQ RAM2 0  
    CALLSUB SET_OP1   
    CALLSUB CHK4LOW   
    TSTEQ OP1[1000] 1  
    SET OP1 0  
    TSTEQ IP2[500] 1  
    CALLSUB KEYMAIL   
    TSTEQ IP2 0  
    SET RAM1 0  
    SET RAM2 0  
    END    

CHK4LOW:
    TSTEQ IP2 0  
    SET RAM2 0  
    RET

SET_OP1:
    TSTEQ IP2 1 RAM2
    SET OP1 1  
    RET    

KEYMAIL:
    TSTEQ RAM1 1  
    RET    

    EMAIL EM5   
    SET RAM1 1  
    RET

 

[apostolakisl]

Check out wikipedia.  It gives a pretty good answer.
 
Basically, you use the ANDB to test a bit, ORB, to set a bit, and XORB to flip a bit.
 
ANDB RAM1 4 is true if the 3rd bit is 1, otherwise it is false
ORB RAM1 4 RAM1 sets the 3rd bit to 1
XORB RAM1 4 RAM1 flips the 3rd bit (0 to 1, 1 to 0)
 
decimal = bit
1  = 0000001
2  = 0000010
4  = 0000100
8  = 0001000
16= 0010000
 
etc

 

[apostolakisl]

I wrote this using bitwise concept.  I haven't run it, but I think it should work.  Give it a try and let me know.
 
START
TESTEQ IP2[500] 1
CALLSUB KEYMAIL
TESTEQ IP2 0
CALLSUB SETBIT3   
END
 
 
KEYMAIL:
ANDB 4 RAM1   (sets the 0 bit to 1 if 3rd bit is 1, otherwise 0)
BNZ ABORT       (if 0 bit from above is not zero (it is thus 1), it branches to abort)
EMAIL EM5       (otherwise email gets sent)
ORB 4 RAM1 RAM1    (sets 3rd bit to 1, which blocks future emails)
RET
 
ABORT:
RET
 
SETBIT3:
ANDB 4 RAM1   (checks to see if 3rd bit is already 0)
BZ ABORT          (if it is 0, it aborts)
XORB 4 RAM1 RAM1   (if it is not zero this flips it to 0 so email can be sent)
RET
 
By the way, tell me exactly what your code is doing, I am quite certain you could have this program significantly shortened/simplified.

 

[fcwilt]

Hey Lou,
 
I not sure if you should be testing the input for a 0 or a 1.
 
The Keypad output is NO (normally open) and is connected to ground. If the INPUT is non-inverting then when the Keypad output is active you need to check for 0. But I think I read that the INPUTS can be set to be inverting in which case you would test for 1, as you are doing.

 

[siafu]

I wrote this using bitwise concept.  I haven't run it, but I think it should work.  Give it a try and let me know.
 
START
TESTEQ IP2[500] 1
CALLSUB KEYMAIL
TESTEQ IP2 0
CALLSUB SETBIT3   
END
 
 
KEYMAIL:
ANDB 4 RAM1   (sets the 0 bit to 1 if 3rd bit is 1, otherwise 0)
BNZ ABORT       (if 0 bit from above is not zero (it is thus 1), it branches to abort)
EMAIL EM5       (otherwise email gets sent)
ORB 4 RAM1 RAM1    (sets 3rd bit to 1, which blocks future emails)
RET
 
ABORT:
RET
 
SETBIT3:
ANDB 4 RAM1   (checks to see if 3rd bit is already 0)
BZ ABORT          (if it is 0, it aborts)
XORB 4 RAM1 RAM1   (if it is not zero this flips it to 0 so email can be sent)
RET
 
By the way, tell me exactly what your code is doing, I am quite certain you could have this program significantly shortened/simplified.

Hi Lou, Yes this works, it sends one email, but that's it it does nothing else.
 
Basically here is what the desired outcome is.
 
IP1 is hooked up to my door buzzer, and when someone presses the button I just want one email to be sent to me from email1
 
IP2 is hooked up to the keypad, and when someone enters the correct code, OP1 is triggered for 1 second, that sends a signal to the door strike that opens the door, then sends an email from email5
 
That's basically it.
 
START    
    TSTEQ IP2[500] 1  
    CALLSUB KEYMAIL   
    TSTEQ IP2 0  
    CALLSUB SETBIT3   
    END    

KEYMAIL:
    ANDB 4 RAM1  
    BNZ  ABORT  
    EMAIL EM5   
    ORB 4 RAM1 RAM1
    RET    

ABORT:
    RET    

SETBIT3:
    ANDB 4 RAM1  
    BZ  ABORT  
    XORB 4 RAM1 RAM1
    RET
 
I have other code that you helped me with some time ago, where it controls the heat, and will also like to implement that into a code that works with the keypad and the door buzzer.
 
Thanks for your continued help.