suggestions for enhancements to webcontrol (not 32)
- Thread starter bbsux
- Start date
They're read-only in PLC code - at least, I understand they are read-only. Do you know something I don't??
CAI_Support
Senior Member
The only reason we making UROM read only in PLC is that any mistake in PLC code could ruin EEPROM chip within few seconds or few minutes. For example, if someone didn't know SET command direction, he could debug the code for few minutes, it would be too late when he found the bug.
Do you have any proposal for how to prevent user mistake ruin the EEPROM chip? We love to hear it. We have been thinking the LCD display issue. thank you for bring that up to us.
Do you have any proposal for how to prevent user mistake ruin the EEPROM chip? We love to hear it. We have been thinking the LCD display issue. thank you for bring that up to us.
Well, two thoughts.
1. Why should you be the ones to prevent stupidity? OK, sure, if there's no possible UPSIDE, but when you disable a useful command just because someone being careless could damage the board? How do you prevent someone poking 12V into say, the humidity sensor terminal and blowing up the chip? You don't. Make it clear in the manual that it has a limited write cycle and to use it carefully. Or call it something else - like FLASH - so you READ from UROM1, and WRITE to FLASH1
2. You could add a modest delay to the write cycle. Say, a second. For the infrequent times a user will want to write, this shouldn't pose a great problem, but would make discovery of an issue like you mention, much more obvious and less damaging.
Actually, scrap (2). If you were detecting a power-fail and trying to save critical values before power was lost, those extra few seconds might make all the difference.
bbsux
Active Member
Cai_support here's something out of left field - you said there are a few unused pins left on the board, right?
could you implement a low end i2c for the LCD to use? If possible that could open up a huge amount of thing we could do!
an LCD board that displays I/o and has the ability to switch them. New kinds of sensors.
its probably a pipe dream, just thought I'd bring it up...
could you implement a low end i2c for the LCD to use? If possible that could open up a huge amount of thing we could do!
an LCD board that displays I/o and has the ability to switch them. New kinds of sensors.
its probably a pipe dream, just thought I'd bring it up...
CAI_Support
Senior Member
Thanks for your suggestion. Both Ross and BBsux.
There are few extra pins on the board, but I2C does not work on those pins, unless we implement a lot of timing control in firmware. But we are thinking how to provide the display functions. We are thinking to provide a 1-wire LCD module, or implement the display feature in an Android app through existing network. I think LCD can be a lower cost option. Android app could be more popular for people have Android tablet or phone. There is a very limited code space on the processor. We want to make a decision that helpful for most business customers. Either way this is not a fast action item, we will take some time to get either one done.
It might be an idea by allowing user to short one of the spare pin to the ground to enable UROM to write. So that they know the consequences when they jump the pin. Although we are not responsible for user making damage to the board, we do have customers contacted us for damaged hardware.
There are few extra pins on the board, but I2C does not work on those pins, unless we implement a lot of timing control in firmware. But we are thinking how to provide the display functions. We are thinking to provide a 1-wire LCD module, or implement the display feature in an Android app through existing network. I think LCD can be a lower cost option. Android app could be more popular for people have Android tablet or phone. There is a very limited code space on the processor. We want to make a decision that helpful for most business customers. Either way this is not a fast action item, we will take some time to get either one done.
It might be an idea by allowing user to short one of the spare pin to the ground to enable UROM to write. So that they know the consequences when they jump the pin. Although we are not responsible for user making damage to the board, we do have customers contacted us for damaged hardware.
Character display is not only lower-cost, but also makes for a stand-alone controller. I'd much prefer this option.
Well then, make it a switch in the GUI like "Enable Web polling" - put it with the UROM setup page, make it default to disable, put a clear warning beside it. Don't waste more I/O pins!
Another thought.... you have multiple email profiles now, but each one sends mail only to the same address.
It would be useful if there was more than one email recipient. Leave the SMTP server setting the same, but let emails be sent to different people. This way you could let different people know about different events. (Eg, email for non-critical events, but email-to-SMS for urgent stuff - like "heater turned on" is fine... but "basement flooded" needs attention immediately!
CAI_Support
Senior Member
Do you have a RESTful URLs server that we can see how that works? Can that be a regular Apache server or IIS server?
CAI_Support
Senior Member
WebControl 8 newest firmware 3.02.16 allows each of those 8 emails being send to 8 different receipions. In addition, it allows one board to do HTTP GET call to set another Webcontrol board VAR or OPx value from PLC logic. This HTTP GET can also set to web servers, if the server has proper CGI code to process the call made from WebControl. When the other board or remote web server is down, future HTTP GET call will not send.
There is really no space for adding other feature. But we could modify the behavior. For example, this HTTP GET is for setting value for other boards or web server. We could modify the code so that use this to send through UDP port, instead of HTTP (sorry, you can not have both on this board).
This version is for feature addition. There is no firmware bug fix in this version. All current shipping boards have this new firmware. Please contact us if you have any question.
There is really no space for adding other feature. But we could modify the behavior. For example, this HTTP GET is for setting value for other boards or web server. We could modify the code so that use this to send through UDP port, instead of HTTP (sorry, you can not have both on this board).
This version is for feature addition. There is no firmware bug fix in this version. All current shipping boards have this new firmware. Please contact us if you have any question.
CAI_Support
Senior Member
If HTTP GET performed on your web site, your CGI could actually reply certain things in the GET call processing in MIME header. WebControl board can then read that to set a VAR or RAM, if certain format is agreed.
Does anyone think that is necessary?
Does anyone think that is necessary?
HELL YES! Asked for this 12 months ago, it wasn't "possible" back then, so absolutely!!!
There is no such thing as a "http get over udp". HTTP is a TCP connection.
Arguably, the biggest problem with UDP is that there really is no guarantee that the packet was delivered. The sending application has no acknowledgement. For logging that may or may not be a problem. For control, it almost certainly is a problem.
CAI_Support
Senior Member
HELL YES! Asked for this 12 months ago, it wasn't "possible" back then, so absolutely!!!
Hi Ross,
Could you please provide details on this? Should we just set VAR8 value for return code? Typical HTTP server response is like this:
HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Etag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: none
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8
To make the processing easier, we would hope any string located in the first 64 byte of the server reply, if possible. So that we just read reply from clients, and parse the first 64byte for possible command. If you have certain need, maybe you can setup a server to allow us remotely test the code for you.
When you say "the first 64 bytes" of the server reply - do you mean of the header, or of the data past the header?
I think it's going to be a very big ask to expect people can get their user data within the first 64 bytes of the reply including header, because many http daemons don't provide for insertion that early.
If it's after the header then fine, and if you specify the answer will be (say) "immediately after the =" or whatever, then so be it.
If you have the codespace for it, it would be perhaps "nice" if the server could reply with something like:
var1=12345 - perhaps be able to specify where the answer will go? Perhaps be able to return multiple answers?
Imagine: a webcontrol board could come on-line, make a request of a "provisioning server" which could send back a bunch of registers. The lat/long, unique ID code, time offset and local variables relevant to that webcontrol boards purpose!
