Can't access WC8 remotely

bedi

Member
The WC8 controls A/C based on occupancy. I did port forwarding in TP-Link Deco M5 router. It worked fine for about a week during which I was in the condo- remote access worked fine too.
Once I left the condo (I don't live there), the next day the controller became not accessible remotely via open port in router (it worked without issues all the time while I was there!).
In Deco M5 app I can see the WC8 is connected to local network and it receives traffic when I try to connect to it via browser, but does not respond (1-2k download traffic but 0k upload- so it does not respond)
I am very far away from the condo now so I cannot know if LED is still blinking and if the PLC is still running and if it would execute the routine despite this network issue.
 
My question is: is that possible that PLC code (if something is wrong there) could jam the NIC?
 
That is my first thing that comes to my mind since this is the only thing that has been changed: no one is in the condo within long time, so the code works little differently now.
There is another WC8 controller that does different thing in that condo; it also connected to the same router and it works fine, I can access it remotely via another port in the router. So the reason is not in router but in WC8.
The WC8 purchased from Amazon this summer so it should be with the latest firmware (I don't remember FW version now).
 
Thanks!
 
If PLC code sending out stuff too frequently, it could become a problem for the CPU working on handling all the network traffic.  Inside PLC, its logic force itself working on time slices to handle different things, like monitor IO ports, control ON/OFF, timer, etc.  Not able to reach to its NIC does not mean the logic would not work, it might still do whatever you programmed it to do, however, when network traffic overflow its can handle, the only way is to let all network traffic to the WC8 to be die down. Ethernet protocol would send retry after each failure, but double its waiting time between retries, until certain time, the Ethernet logic would stop retry.  Wait few hours or a day, try to see if you can still reach to its NIC.
 
WC32 has separate NIC processor, so that it can handle network traffic a lot faster.  WC8 handles everything by its only CPU on board.
 
Hi Suport, thanks for reply.
 
I can see on router app (Deco M5 smartphone app) that there is no traffic coming to the controller- it is 0k al the time, unless I try to communicate with it- then I see it receives 1-2 k but does not respond.
The PLC code is not sending emails all the time- it sends email only once each time when the A/C is ON or OFF. So NIC is not busy at all.
And few minutes ago I did receive an email from the controller, informing that someone entered the condo and A/C is ON now. So at least I am relieved the PLC is running and controls the A/C as it should.
But I still cannot access this WC8 remotely. It does send emails though. It is strange it happened exactly the next day I left the condo but worked fine while I was there. Co-incidence?
I can access another WC8 that is connected to the same router and it has temp sensor too; I can see the temperature is dropping now so this is indication that the A/C control does work. But I cannot access to it...
 
I have just rebooted the router- did not help... It works with another WC8 but does not work with this one... So the problem is 100% in the WC8. It sends email but does not allow access to its GUI.
It's IP address and port did not change since I left the condo- and it worked... The only thing left is to reboot the WC8 but it is tricky in my situation. Any other ideas? And why it happened?
I have 2 more WC8 working in other places for years, never had such a problem...
 
Does your other place use the same kind of router?  I assume you have NAT setup on your router.  Receiving email indicates the board NIC and PLC logic are all working. The difference between HTTP and SMTP is that SMTP can send out email one byte at a time, till whole message sent, the email server would not drop. HTTP protocol on the other hand requiring whole message header then body being received completely, otherwise, it would not consider finished, thus requires more RAM.  If you have chance, try to use another WC8 to replace this one to see if the problem persist.  If you could reach to its GUI from inside network, but could not over NAT router. then it might be a different problem.
 
Yes, other place with WC8 use the same Deco M5 router and it works no issues. This router is connected to two WC8; only one has this problem. Again- it worked properly for more than a week; stopped working exactly once no one was in the condo for long time, thus I suspected something in the code could cause it but I check there is nothing wrong in the code; I use CTS in 3 places in the code for timing proposes and 3 RAM locations are constantly updates with new 32 bit numbers; maybe it takes too much resources from CPU? 
RAM amount did not change since I left the condo; nothing has been changed; it just stopped to be accessible from outside. I cannot replace with another WC8 and I cannot test if it reachable from within local network- I am thousands miles away from there now. I will ask someone to plug it off and on and see it that would restore the access. It is a weird issue.
 
While you were there, did you try to access it from outside, or only tested inside?  Just try to isolate the possibilities. Normally, if PLC logic running fine, it would also runs fine for the HTTP, since they are in the same firmware stack, especially SMTP and HTTP share a lot of network logic in the firmware. 
 
If the problem is the board, we will replace it without problem. Just try to find out what could be wrong with it right now.
 
Sure I tested from outside while I was there, every day few time per day. I wanted to make sure all works properly before I fly. I checked on the way to airport- it worked fine; the next day I checked- gone; I could not connect to it anymore :-(
I asked someone go there to turn it off and on; after couple of tries it did connect again and all works good so far! I uploaded the improved PLC code (just in case) and hope it would work now all the time, fingers crossed. I will update if not accessible again. Thanks.
 
In my PLC program there are few places where I check if inputs are zero.
For example, I use TSTEQ IP1 0 VAR1 Maybe it is better to use TSTNE IP1 1 VAR1 instead? Logically it is the same but maybe there is some caveat here?
 
Logically it should be exactly the same but... It is possible to use an increment instead of a simple assignment to 1 or 0. Testing for 1, may not work if this error in logic ever gets into your code. Testing for 0 is the safest IMHO.
 
It worked 2 days; this morning it is not accessible again. I will be there in January; only then I  could do something. At least PLC is running and it does its job as for now.
 
I use similar to this in 3 places in the code, so 3 RAM locations are constantly updated with 32 bit number; maybe it is too much for the CPU and it stops responding to network traffic after some time?
 
TSTEQ RAM11 1  
ADD CTS UROM2 RAM7
TSTGE CTS RAM7
 GOTO OFF2
 GOTO ON2
 
The logic: When RAM11 is 1, it constantly resets the counter; once RAM11 is 0 for more seconds than set in UROM2, it set output to 0; once the RAM11 is 1 again, it set output to 1
The thing is that RAM11 is 1 most of the time, so maybe this code is not optimal; having this logic in 3 places in the PLC code might strain the CPU resources and could cause this issue with network access?
This is the only thing I see in the code that could take resources but maybe I am wrong and it is OK and the board is faulty and that is the reason it stops reslonding to network requests...
 
OK, so I changed PLC program 4 weeks ago and it works no issues since then.
The previous program used CTS for time markers (see the previous post).
There was no any network traffic but it appears this PLC program caused this phenomenon where the board stopped responding via web- it looks like constant updating of CTS does not work well with WC8 board.
So instead the sequence in the post above, I used INC and DELAY:
 
               DELAY 500
               OR IP1 IP2 RAM5
               TSTEQ RAM5 0  
               SET VAR2 0
               TSTEQ OP1 1
                INC VAR2
                TSTGE VAR2 UROM2
                GOTO OFF2
               TSTEQ VAR2 0
               GOTO ON2
 
That works like a charm, no issues, I can access the board any time.
I know some folks here hate DELAY (like, PLC program should run all the time!) but it appears using it contributes to stable and reliable operation of WC8: since it shares resources and the resources are very limited, DELAY might help CPU to do some other stuff while the program is paused.
That's just my guess, but the fact is that getting rid of CTS and using DELAY and INC instead solved the problem with seemingly not related problem with web access to the board.
 
SLEEP will let CPU handle interrupt and stack operation, however, DELAY is not, it just looping there till all the time over.  However, sometimes, IPx signals has little bounces during switch, that could let logic working wrong, DELAY could wait out those initial bounces in IPx.  WC8 IPx responses to up to 4MHz fast pulses, those signal bounces could lead to your logic not working correctly. In that case, adding DELAY will help waiting out those spikes.
 
Back
Top