WC8 questions

[bedi]

Look, guys, I really like the board but your support seems do not know the matter... Really frustrating experience!
I am exchanging emails back and forth with someone from support (do not know if it is one person or not).
I explained exactly what is the problem many times. But they found something in the code they think is wrong and keep telling me that this is the reason.
It looks like they do not understand a simple code of 3 lines!
Moreover- even if the support were correct- it will not cause the phenomenon I am experiencing! I asked to explain why it would cause sending from EM3 instead from EM1- did not get answer.
 
So, out of no choice I put here this code of 3 lines (which is actually nothing to do with the real problem!):
 
TSTEQ VAR6[43200000] 0 VAR1
GOTO VACANT   
GOTO MOVEMENT
 
They claim that every time VAR6 flips 1-0-1-0-1, it will also go to flipping Vacant-Movement-Vacant.
This claim is actually contradict with both PLC command explanations in the manual and actual, real work of the board!
They still keep telling the same...
 
Here is my explanation (and it actually works this way in reality!!!):
 
The first line (TSTEQ) will get true if VAR6 will be zero within 43200 seconds or more.
In case of TRUE, it will go to VACANT; otherwise it will go to MOVEMENT.
 
Therefore, the line TSTEQ VAR6[43200000] 0 VAR1 means that it will go to Vacant ONLY if 43200 seconds passed without VAR6=1.
No matter how many flips 1-0-1-0 VAR6 does- it will go to Movement all the time because the condition of 43200 seconds did not meet!
It will go to Vacant only after last VAR6=1 was 43200 (12 hours) seconds ago (if VAR6 was 0 within last 43200 seconds)!
If after 12hours VAR6 gets 1, it will go to Movement again and will stay there until last time VAR6=1 was 12 hours ago.
Every pulse of 1 of VAR6 will reset counter of 43200 seconds to zero but it stays on Movement.
 
Again, even if their claim were correct (flip vacant-movement), I would get constant emails from Vacant-Movement respectively. This does not happen, of course.
My problem is that when 2 events that happen at the same time trigger their respective email notifications (from different EMs), instead of receiving 2 emails from 2 EMs, I get 2 emails from the same EM- with the same subject in the email, but I/O data inside the each email correspond to each event. There is something that cause these 2 emails jammed, mixed up when they should be sending at almost the same time.
In no way the code shown above (whether it is correct or not-does not matter) would cause such a phenomenon.

 

[CAI_Support]

Bedi,
 
I think the problem is that you do not fully understand how VARx[y] works.
In your code, your motion sensor kept setting VAR6 to 0 and 1 non stop.
Then in your code you have

TSTEQ VAR6[43200000] 0 VAR1
GOTO VACANT
GOTO MOVEMENT


What VAR6[43200000] return is the key point to understand the problem.
First of all, there is only ONE timer associated with each VAR. When motion sensor kept setting VAR6 to 1 and 0 alternatively, that timer associated timer being reset all the time. At the same time, behind VARx, there is a storage for previous value. So when your code set VAR6 from 0 to 1, VAR6 current value is 1, previous value is 0. When motion sensor set VAR6 from 1 to 0, its current value is 0, previous value is 1.
 
VARx[y] will return previous value before y expires. That is how this delay works. If VARx being altered all the time, its return will also being altered in unintended way.
 
So your logic above will moving between VACANT and MOVEMENT all the time, that is correct behavior of PLC engine, but it may not your intend action.  As we mentioned to you, you will need to arrange your code only let motion sensor set VAR6 once from vacant to movement, then no longer check motion sensor till timer expires.  If your code kept check motion sensor inside house, it will keep getting zero and one with people moving or not moving. thus all the logic do not work as your intend to do.
 
You have a neat idea to have vacation home controlled by motion detection, it will save energy and good for the environment.

 

[bedi]

Well, I just want to point out to  facts:
1. First, if you were correct, I would get email notifications from Vacant and Movement every time the code flip from vacant to movement. It does NOT happen.
2. Secondly, here is what written in the manual:
non-blocking delay operator optional to TTL input/output and VARs. 32 bit
unsigned number, represent resolution of 0.001 seconds. When the delay operator is
used on input operands the current value of that input is only used if it has had that
value for greater than the delay period specified between the brackets.
 
In my case: If VAR6 has had value 0 for greater than 43200 seconds, this value (zero) will be used. Correct?
So this value tested TSTEQ with 0, gets TRUE result if VAR6 has had value 0 within 43200 period.
If someone is inside the condo, VAR6 will flip 1-0-1 all the time when there is movement.
This will keep that TSTSEQ in FALSE, VAR1 (the result) will be zero. If it keeps in False, it will skip next line all the time and go to Movement.
VAR1 will get 1 (TRUE) only if VAR6 was 0 for all 43200 seconds. In this case, it will move to Vacant.
 
This is how I wanted the code to behave and this is actually their behavior in reality!
In reality, it DOES NOT flip Vacant-Movement-Vacant!
In reality, I get CORRECT notification 12 hours after I left the condo! For example, I entered the condo in 9AM, was there till 11AM. I left in 11AM. Then I get a notification that the condo is Vacant (and OP1 turned 0) at about 11PM- 12 hours (43200 seconds) after I left.
 
SO my code works! Exactly as I describe it, exactly as I intended!
 
This all stuff is like: I say: the grass is green. You are just saying: the grass is blue, customer just does not have the correct glasses. LOL.
 
And again (never heard answer on this): Even if you were correct, how this would cause sending notification from EM3  (from completely different part of the code) instead of EM1? This is the real problem, guys.
Would you please leave this stuff alone and concentrate to the real problem instead trying "fix" something that works perfectly?
When emails from EM1 and EM3 should be sent almost at the same time, I get 2 emails with subject corresponding to EM3 instead of one email from EM1, then one from EM3.

 

[CAI_Support]

I don not know how do you understand

When the delay operator is used on input operands the current value of that input is only used if it has had that value for greater than the delay period specified between the brackets.

You have to realize your current VAR6 value is being changed all the time by motion sensor, thus your previous VAR6 value is also being changed all the time.  Before timer expired, you will keep getting changed VAR6 previous value.  If you don't fix this, following logic will not be dependable.  Your total code is only 82 lines, PLC engine will execute them 15 to 20 times in any second.
 
We spent a lot of time to follow your PLC code with many goto from one place to another, we were able to "walk" the logic to get two EM3 when we simulate motion sensor flicking all the time.  We did not debug further on your PLC code, since we were able to duplicate the PLC code problem with reported issue.
 
There are people running much longer PLC code with very complex logic and working fine.  There are many thousands boards running out there. If this PLC engine had bug, they will all have been exprienced.  Please fix the motion sensor triggering VAR6 unintentionally first, that will help a lot.

 

[bedi]

we were able to "walk" the logic to get two EM3 when we simulate motion sensor flicking all the time

Great so may be this is the indication that you have a bug in the firmware. Because there is nothing in the code that would call for EM3 from the portion of the code that involves motion detector. These are completely different parts of the code: Motion detector controls heater ON/OF function and sending emails from vacant or movement, that's it. EM3 called from part of the code that checks current of water heater.
These parts of the code are not connected in any way, they just run one after another.
 
The problem happen when 2 events trigger 2 emails at the same time.
 
Here is what happen; read it carefully, you will understand that it is not because VAR6 flipping:
 
1.The condo was vacant for a long time; the water in the heater is cold because it it disconnected from power. Therefore, electrical heating element inside the heater is already turned ON by internal thermostat, it just waiting for the power to get the water heated. Also, motion detector is 0 all the time, because no one is in the condo. Therefore, VAR6 is also 0 all the time. All system is in static.
2. I enter the condo; motion detector senses the movement, IP1 input gets 1 for about one second, causing VAR6 to get 1 too. This very first 1 of VAR6 cause the code to go to Movement: it sends email from EM1 that says that someone is in the condo and turn the power to the heater ON- the water heater gets 208VAC.
3. Since internal thermostat inside the heater was already ON, as soon as power applied to water heater, current started to flow through heating element, causing input IP3 to get 1. This input IP3=1 trigger sending email from EM3 that says that there is a current on heating element.
 
These 2 events that trigger EM1 and EM3 happen at the same time. Keep in mind that this happen just after the first 1 of VAR6: this VAR6 was in static condition of 0 all the time before!
The result: instead of receiving 2 different emails from EM1 and EM3 respectively, I get 2 emails from EM3 but no one from EM1.
 
In fact, in reality: I get these 2 emails from EM3 as soon as I enter the condo- immediately. I do not get email from EM1.
 
I allow only one pulse of VAR6 to 1 (enter and go back immediately) and still I get these 2 the same emails from EM3.
 
Now, if I disable the input IP3 (disable triggering of EM3), I do get the correct email from EM1. it means if the system needs to send only one email at short time, it works correctly.
 
Therefore, the problem is not because continuous flipping of VAR6 here!. Please check your firmware.
Thanks.

 

[CAI_Support]

Bedi,
 
I don't know what to say. We found your PLC code bug, and made suggestion on how to fix your PLC code. But you insisted on that is our firmware bug.  I am not trained to fight with customer for whatever they want to say.  But can only leave this here till you fix your PLC code.  I spent days tried to follow your PLC code, since it is so many goto jumping around in your code. I hope you will get it fixed, since it is not a huge PLC program.

 

[bedi]

Support,
 
 I do not just say that you have a bug. I proved that you have a bug. See my previous message. It clearly shows that the problem is nothing to do with VAR6 flipping- the problem appears at the very first VAR6 getting 1.
 
When I disable IP3 (disable triggering of EM3), I get correct email from EM1. No matter how many times the VAR6 flipping. What else do you need?
 
I also pointed out that if you were correct, I would get constant emails from vacant-movement notifications every time it flips vacant movement. It will flip vacant- movement-vacant, right? This is what you said. But I do not receive such notification.
 
I implemented VAR6 only to make sure I get proper signal from detector, without any false trigering
In the earlier version of the code instead of
TSTEQ IP1[500] 1 VAR6
NOP   
TSTEQ VAR6[43200000] 0 VAR1
 
I had this:
TSTEQ IPINV1[43200000] 1 VAR1
 
This one line is equivalent to 3 lines above, the only difference is that it does not matter how long the pulse of 1 from IP1 is.
In later version I just make sure IP1 pulse is 500mS or more.
 
It worked the same way, did the job to turn ON/OFF the heater based on sensor movement and timing; it worked the way I want.
But I did receive the same 2 emails from EM3. Even without VAR6 at all
 
Or you are going to say that this line is also wrong?? I cannot allow pulses on IP1? because it will somehow magically affect EM3?
 
The PLC code works as intended, it is not my fault that you do not understand that.
And in reality check, my understanding of the code is right- just because it works exactly as I explain, as I intended.
It does not work as you describe. Grass is green.
 
By the way in emails communcation I received from support the following explanation of my code:
 
[SIZE=11pt]TSTEQ IP1[500] 1 VAR6        # motion sensor output if longer than 500mS, set VAR6 to 1, but it can set VAR6 to 0 quickly, of motion is ever not detected. [/SIZE][SIZE=11pt]ß[/SIZE][SIZE=11pt]LINE problem[/SIZE]




[SIZE=11pt]NOP                                           # do nothing, move on to next line[/SIZE]
[SIZE=11pt]TSTEQ VAR6[43200000] 0 VAR1   # does not matter IP1 condition, if VAR6 return previous value before 43200 seconds reached, set VAR1[/SIZE]




 
Wow...
"Does not matter IP1 condition"  !!! when it clearly matter- VAR6 does depend on IP1. So how it can be not matter???
 
And then: "[SIZE=11pt]if VAR6 return previous value before 43200 seconds reached, set VAR1"[/SIZE]
 
[SIZE=11pt]This sentence is completely wrong, it does not work that way- neither per their own manual, nor in reality! [/SIZE]
[SIZE=11pt]In reality (and per their manual, and as I intended), VAR1 set (get 1, i.e. true) only if VAR6 was 0 for 43200 seconds or longer.[/SIZE]
[SIZE=11pt]Because this from manual: [/SIZE]
[SIZE=11pt]"When[/SIZE] the delay operator is used on input operands the current value of that input is only used if it has had that value for greater than the delay period specified between the brackets."
[SIZE=11pt]OK, lets see: VAR6  current value: 0 for 10 min, then 1 for 3 sec, then 0 for 1 min, then 1 for 2 sec, then 0 for 1 min, then 1 for 5 sec, then 0 for 45500 sec.[/SIZE]
[SIZE=11pt]All these 1-0-1- states of VAR6 will not be used because they were less than 43200 seconds. Only the last 0 that was more than 43200 seconds will be used! And only in this case that test line will return true (because the test compares this value with 0), set VAR1=1 and go to Vacant. In all other 1-0-1-0-1 situations of VAR6 this test will return false and therefore go to Movement.[/SIZE]
 
[SIZE=11pt]This is how it really works, in real board[/SIZE], support. VAR6 does the correct job in this code, does what is intended, there is no any bug here.
 
Claiming that VAR6  flipping will somehow magically affect EM3 email sending from completely different part of the code ... well, it does not sounds good, at least.

 

[LarrylLix]

I have to agree with bedi here.
 
First, let me say that I never use these delays in my software. As an long time programmer since the 70s these opcodes are just too weird and abstract  for me and I never had any use for them.
 
I agree with the way bedi has interpreted this delay usage because that is the ŵay I interpret them also.
 
With this line
TSTEQ VAR6[4320000000] 0
 
VAR6 should only return the value 0 if it has been 0 for 12 hours [43200 seconds], by the description and bedis code should work just fine.
 
 
To implement this logic, WC8 keeps the latest value of the variable and the time in 0.001 seconds from the last change for comparison purposes. They also keep the previous value before the change. This is where the problem comes in that violates the stated and logical operation.
 
Sure VAR6[43200000]  will  return 0 if the value remains as 0 for 12 hours but what does it return if the value hasn't been 0 for 12 hours. According to CAI it will return the previous value before the last change. That is a design error.


Sooooo... this means if the variable toggles to 1 for 1 second and back to 0 the test VAR6[43200000] will return the value 1 and foil every test.

In short if CAI support is correct, in their description in this thread, it is a useless opcode operation. Either a big error has been introduced at some point in some version, or nobody has actually used these opcode delays successfully in their programs.


If a variable is toggling back and forth 0-1-0-1-0-1-0 etc.. and the VAR6[43200000] function doesnt know what you are testing for, how can it know what to return? It cant. The value being tested for has to know what you are looking for to know what to return and what not to return.


It appears CAI has created the function VAR6[43200000] to return an integer value instead of a Boolean value. It can never work like that. My evaluation is that these delay tests have never worked and never will. How can a function know what to watch for before being tested.

VAR6 needs to return an integer value.

VAR6[x] y needs to return a Boolean value and the parameter y needs to be passed to the function to do that. This doesnt seem to be happening in the WC8 PLC engine.


Let hear from users that have actually used these opcode with delays, giving details and how they have proven them working.
 
 
EDIT: Some punctuation corrected after website updated and sign back in completed

 

[bedi]

Larry,
 
The thing is that my interpretation confirmed by practice (the work of a real board). This is how it works in reality: the test will return false all the time unless the value of VAR6 is 0 for 43200 seconds or more. It does NOT follow the change of VAR6 from 0 to 1 and so on. And this is normal, this is what is supposed to be logically and this is what I intended to achieve.
If every 1-0-1 of VAR6 cause going to Vacant-movement-vacant (as support claim), I would get email notification about this; this is how my code works.
But I do not receive such notifications, meaning the code stays at movement unless 12 hours passed since last movement, then it stays in vacant as long as VAR6 is 0 for 12 hours or more. All this code works exactly as intended to be.
This part of the code control relay that supply power to water heater and this works just perfectly: disconnect power 12 hours after people left the condo. The relay does not flip on-off-on with changing of VAR6. Therefore, what support claim is wrong.
 
Now, this is in no way should affect sending emails from EM3. Sending emails is the real problem I started all this issue for!
 
Also , as I said in the previous post, I had the following instead:
TSTEQ IPINV1[43200000] 1 VAR1
 
This test does not involve VAR6 or other variable; this does the same logic as the lines:
TSTEQ IP1[500] 1 VAR6
NOP   
TSTEQ VAR6[43200000] 0 VAR1
 
So, TSTEQ IPINV1[43200000] 1 VAR1 did the same job, it worked the same way. I changed it only to prevent false triggering from PIR; so now I make sure the pulse is at least 500mS.
But I still received 2 emails from EM3, even without variable VAR6 or other in the test. Therefore VAR6 is NOT the reason for the problem!
 
Also, I got other circumstances where 2 events trigger 2 different emails from different EMs and got the same phenomenon: 2 emails from one EM.
This cannot be because some VAR flip from 0-1-0-1. that is not related to sending emails,
Don't you agree there is a problem with firmware that cause such a thing?
Especially when I explained in great details how this happen- it happen just after first VAR6 gets 1.
In response I got "I do not know what to say"...

 

[LarrylLix]

I don't know what the rest of your code is so I do not know what else could happen to make this happen.
 
If you tie up the PLC engine with some code loop or tie up the email send buffer with too much data too fast who knows what the WC8 will do. I have had to spread my http sends out on a one second basis to avoid hanging the 1wire input due to severe shortages of memory on this board.
 
On a PCB with this limited and cross-borrowed  resources everything can affect anything else. It really shouldnt but then the board wouldnt exist with so many gadgets.
 
Previously we asked that the old X10 support be removed to make some room but that was thought the obsolete protocol to be important. I have used X10 since the early 80s and I haven't seen any support on the board either,

 

[bedi]

Well, I use only 4 digital inputs, one digital output, one  temp sensor  and humidity sensor, that's it.
So I do not believe I abuse the board's resources a lot
And my code is not large, 81 lines only. The code runs sequentially to check all inputs, send emails if conditions met and turn relay on or of. that's it.

 

[LarrylLix]

You send two emails at the same time, you reported.  Is your temperature or humidity a 1wire sensor? Do you interact with the Ethernet port sending data or receiving data? Is your WC8 connected directly to  a router used for streaming or VOIP?

 

[CAI_Support]

Larry,
 
What Bedi did not show was a line in front of
TSTEQ VAR6[43200000] 0 VAR1
was another line setting VAR6 to 0 and 1 all the time.
 
VAR6 value is not set to 0 or 1 then wait till the timer time out, rather the PLC code setting it to 1 and 0 alternatively.
thus VAR6 previous value is also keep flipping.  VAR6 associated timer is also keeping being reset to restart.
 
Although he expects VAR6[43200000] only return new value until timer expired, but since his PLC code kept setting VAR6 with a new value, that associated previous value is also keep changing.  That is the correct behavior of PLC engine.  People might think PLC engine should hold off previous value change till first timer off.  But that is not possible,  His PLC code setting VAR6 value many thousands time during the 10 hours period. What kind of CPU and memory and timer to store all those changes?  We only remember previous value and current value, and ONE timer associated with each VAR.  There is the correct behavior of WebControl, it is not bug.

 

[CAI_Support]

Please note VAR6 is a 32 bit signed number. It is not only return 0 or 1, it can be any where from negative 32 bit signed number to max 32 bit signed number.  User will have legit need to set VAR6 value anytime they like.  Our description in user guide clearly stated that. 
 
This is different from IPx[y], where only logically value TRUE and FALSE exist, so that before timer off, IPx[y] only return FALSE. For VAR, its previous value is 64K different possibilities.  So if you use VARx[y] timer, then you have to follow what the PLC engine allows for VAR's previous value, and if you SET that VAR6[43200000] value before timer expires, it will get a new value and its timer will also be reset.  There are legit reasons for users wanting to set VARx[y] to a new value before timer expires.
 
If you really need to have to set a logic TRUE and FALSE, and before timer expires only get FALSE, you can use a spare OPx[y] and sets that value, when reading back , if timer is not expired, it will return FALSE.  Still, please note each time when your set OPx, if set state is different from previous, its timer still gets reset. But its value will return FALSE.

 

[CAI_Support]

Bedi,
 
TSTEQ IPINV1[43200000] 1 VAR1
where IP1 connects to a motion sensor that keeps changing from 1 and 0, that will not do what you intended either.
What IPINVx[y] does is to detect that an IP1 normally TRUE, but trigger goes to FALSE, if that negative going trigger longer than y mS, it will get 0, otherwise, it will return 1.  Your motion sensor will take 43200000ms to start MOVEMENT, that is not what you wanted. This IPINVx[y] is to complement IPx[y]-- which is  to detect normally FALSE, trigger goes to high pulse detection.
 
So that will not work for your case, either.
 
The best way as we mentioned to you, is to only check motion sensor when you are in VACANT state.  Writing a PLC program is like creating a state machine, you know how many different states the setup having, VACANT and MOVEMENT in your case, so that only check motion in VACANT state.