WC8 PLC 3.02.19 firmware

Based on RossW request, we added EMAILQ command to the WC8 PLC operand, its value reflects how many emails being queued in the RAM. If you do not want to lose any earlier email, when EMAILQ greater than 2 on WC8 board, you may want to hold back sending email.
 
firmware download link is here:

http://www.cainetworks.com/support/download/wc8plc030219-update.zip

update WC8 board instruction is here:
 

http://www.cainetworks.com/support/how-to-update.html

 
 
 
 

User guide can be download here:
 

funny story, I once received a buffered alarm email from the wc32; the queue length will help to cover that issue, if you provide queue erasure.
The update could have included my request for a webset counter too, so you find me half happy

Efried said:

The update could have included my request for a webset counter too, so you find me half happy

Click to expand...

 
It's remotely possible that a considered, polite request, including considered ways to reduce or eliminate the requirement for additional RAM in order to implement a facility, and that clearly identifies an actual problem (as opposed to a convenience or perceived issue), may garner a more fruitful outcome than some other aproaches.

Efried said:

if you provide queue erasure.

Click to expand...

 
How will clearing the queue help?  (Seriously)
 
If the mail isn't getting delivered, it's a network (or recipients smtp) problem. Clearing the queue locally doesn't fix the underlying problem, which is nothing to do with the webcontrol board. Clearing the queue and sending another email is unlikely to fix the problem, so why implement something to clear it (that achieves nothing?)
 
At best, clearing the queue would be an "item of convenience" - in normal circumstances, the mail queue will be cleared by the process of delivering mail.I
I would argue that if you have so many events to send that clearing the queue to let only the most recent through (in that brief time that the functioning SMTP is still accepting earlier messages) then the problem is really one of poor user/application code and less one of the email delivery system.

rossw said:

How will clearing the queue help?  (Seriously)
 
If the mail isn't getting delivered, it's a network (or recipients smtp) problem. Clearing the queue locally doesn't fix the underlying problem, which is nothing to do with the webcontrol board. Clearing the queue and sending another email is unlikely to fix the problem, so why implement something to clear it (that achieves nothing?)
 
At best, clearing the queue would be an "item of convenience" - in normal circumstances, the mail queue will be cleared by the process of delivering mail.I
I would argue that if you have so many events to send that clearing the queue to let only the most recent through (in that brief time that the functioning SMTP is still accepting earlier messages) then the problem is really one of poor user/application code and less one of the email delivery system.

Click to expand...

 
I was targeting the
Clearing of the webset stack.
Once one wc im my network is unpowered or unconnected, the whole system collapses, because of stuck stacks.

Efried said:

Once one wc im my network is unpowered or unconnected, the whole system collapses, because of stuck stacks.

Click to expand...

 
I suggest then that you need to revise your code. I needs to at least accept that a failure CAN happen, and "deal with it".
The webset requests, like email requests, should happen once the server responds again. If your code blocks and falls in a heap, it's your code that's at fault.
Again, clearing the stack may let things sort-of work, briefly... but only do a point. Once the next send fails, what then? You're back in the same situation again.
 
Clearing the queue really isn't a fix for anything. It's delaying the inevitable, at best.

rossw said:

I suggest then that you need to revise your code. I needs to at least accept that a failure CAN happen, and "deal with it".
The webset requests, like email requests, should happen once the server responds again. If your code blocks and falls in a heap, it's your code that's at fault.
Again, clearing the stack may let things sort-of work, briefly... but only do a point. Once the next send fails, what then? You're back in the same situation again.
 
Clearing the queue really isn't a fix for anything. It's delaying the inevitable, at best.

Click to expand...

 
 
Sorry my attempt to get a response into WSREPLY from every connected WC was not successful, so it's not my fault.

Might I respectfully suggest another extension to the existing code?
With the number of versions now available, and as we can "field upgrade" firmware, it becomes increasingly difficult to be sure a particular feature is available (or in some cases, that the behavior of a command may have changed).
 
Loading the firmware version (as an argument/operand)? It will mean that version can no longer be alphanumeric (hence no 3.02.19a or 3.02.19b) but thats ok, I'm happy for the minor subversion to change each time!
 
I'd suggest simply forcing 2 digits for the subversion numbers (leading zero added if necessary)  to make a 5-digit number.
 

We can add another operand FWVERSION, if that is something helpful. That is available in GUI display or /api/status.xml
The problem is that for older firmware without this operand, it will fail, since that was not in the older firmware.  It will help for future firmware for sure.
Also, it identify the hardware, since 3.02.xx identify the hardware is WC8 2.2.2 board.   4.02.xx identify the hardware is WC32 rev 5.0 to 7.0 board, with rev 7.0 current shipping board.

I just received a new HW Rev 2.2.2 board delivery direct from CAI and it has this firmware revision on it. Is it actually released or in beta at this point?
 
Have run into some issues.
1) It came with DHCP disabled and if the board is reset, reverts to that state with the fixed 192.168.1.15 address. This is a inconvenience for me as my network uses a different subnet and at first I couldn't find the board in the active devices list. OK, not a huge deal but not per the manual... luckily I had another router I could use just to get the board set up to use DHCP and/or put workable settings in for my network.
2) No matter what client or browser I use (Linux/Firefox or Chromium, Android/Chrome, Win7/Firefox or IE), the board status does not auto update. Neither the main system status nor the PLC page's statuswin.htm pages update without a forced refresh. It appears the board HW is probably OK - it sees a temp sensor and I can toggle outputs. However, none of this is reflected in the webpage display unless I force a refresh (and it feels like that is delayed a bit - count to 3 or 4 before it updates on local machine). My other 18b4 firmware 2.2.2 board updates status dynamically in all these same client/browser combos.
 
I would just go ahead and de-update this board back to the 18b4 version to see if this goes away, but will hold off in case there is something you want/need to validate the problem (and keep me out of any possible warranty issues re: "as shipped" status).

donv said:

I just received a new HW Rev 2.2.2 board delivery direct from CAI and it has this firmware revision on it. Is it actually released or in beta at this point?

Click to expand...

 
I believe it's the current "production code".
 

donv said:

Have run into some issues.
1) It came with DHCP disabled and if the board is reset, reverts to that state with the fixed 192.168.1.15 address.

Click to expand...

 
In the "Network Setup" section, check the "DHCP Enabled" box and hit Send.
 
 
 

donv said:

2) No matter what client or browser I use (Linux/Firefox or Chromium, Android/Chrome, Win7/Firefox or IE), the board status does not auto update.

Click to expand...

 
In the "General Setup" page, check "Web Polling Enabled" and hit Send.

Ross answered all the questions. I want to clarify little more on static IP address 192.168.1.15 question.
 
To most people who knows network well, let router dynamically assigned an IP address in a range is not a problem, because you know how to find out the dynamic assigned IP addresses from your DHCP server.  However, for many users who do not have advanced network knowledge, it is a great challenge for them to find out what their DHCP server/router assigned IP addresses.
 
You can simply add a second IP address 192.168.1.2 in your computer network card advance setting, so that you can access the board easily on your existing network, then assign whatever IP addresses you like or DHCP to your boards. 
 
This arrangement saved a lot of trouble for many users.  In first couple years we used dynamic IP address.  At that period of time, we received support calls daily from frustrated people who can not find the DHCP assigned addresses.  With this static IP address arrangement, we got almost none support calls for that problem.  That is probably the reason most network appliances have factory default static IP address, too.

Ross, thanks for your replies. Both worked for me.
 
CAI_Support, I understand your reasoning and see that this in fact documented well in the current manual. I actually mis-spoke the first time, it was the FAQ which led me to believe the default state was for DHCP to be enabled. Per the current content at http://www.cainetworks.com/products/webcontrol/webcontrol-faq.html:
 

1-1A: If you have DHCP server on your network, please check with your DHCP server log, WebControl is likely obtained an IP address from your DHCP server. Once your find out the IP address assigned by DHCP server, you can use browser to connect to:

http://what-ever-dhcp-assigned-ip/
You will see the login screen.

If you don′t have DHCP server on your network, WebControl's default IP address is 192.168.1.15. You must change your computer's IP address temporarily to 192.168.1.1, (make sure no other host using that IP address on your network), then from IE browser enter:

http://192.168.1.15/
You will see the login screen.

Click to expand...

 
I believe this implies that DHCP is active by default, at least that's how I interpreted it. I suggest that page be revised to state the fixed IP address is default.
 

CAI_Support said:

Ross answered all the questions. I want to clarify little more on static IP address 192.168.1.15 question.
 
To most people who knows network well, let router dynamically assigned an IP address in a range is not a problem, because you know how to find out the dynamic assigned IP addresses from your DHCP server.  However, for many users who do not have advanced network knowledge, it is a great challenge for them to find out what their DHCP server/router assigned IP addresses.
 
You can simply add a second IP address 192.168.1.2 in your computer network card advance setting, so that you can access the board easily on your existing network, then assign whatever IP addresses you like or DHCP to your boards. 
 
This arrangement saved a lot of trouble for many users.  In first couple years we used dynamic IP address.  At that period of time, we received support calls daily from frustrated people who can not find the DHCP assigned addresses.  With this static IP address arrangement, we got almost none support calls for that problem.  That is probably the reason most network appliances have factory default static IP address, too.

Click to expand...

Thanks for pointing out, that FAQ has not changed for a long time, it is time to correct it.  Thanks for pointing out!