side effects?

Efried

Active Member
are there documented side effects from using OPs as VARs or RAMs? In my case I'm pretty sure that storing WSREPLY away in OP alters one VAR.
thanks
 
Efried said:
are there documented side effects from using OPs as VARs or RAMs? In my case I'm pretty sure that storing WSREPLY away in OP alters one VAR.
thanks
 
Giving us specific instances may help someone else confirm it one way or the other.
I've certainly not experienced it, and I use them all extensively.
Also, give us the firmware version... it's possible there's some interplay, but I'm not aware of any at this point in time.
 
WSREPLY only works when WGET read values back from remote HTTP server.  That has nothing to do with OPs or VARs, unless you store WSREPLY value into them.   You have to provide us your PLC code so that we can help you identify where was your problem.
 
OP5 is a bit space, WSRPLY is a 32 bit number. So what is in your reply will make a lot difference, it may or may not set OP5, depends on which bit in the reply was 1.  Have you checked what reply value did you get?
 
CAI_Support said:
OP5 is a bit space, WSRPLY is a 32 bit number. So what is in your reply will make a lot difference, it may or may not set OP5, depends on which bit in the reply was 1.  Have you checked what reply value did you get?
 
I see some strange characters in the html interface of the WC. Seems that there is no bounds checking when setting OP.
 
You are assume things.  It is casted correctly in the firmware. Like we said before, please post your PLC code so that we can see what you actually doing, also identify the version of firmware on your board.
 
CAI_Support said:
You are assume things.  It is casted correctly in the firmware. Like we said before, please post your PLC code so that we can see what you actually doing, also identify the version of firmware on your board.
 
Hmm I don't know what hands on experience you have, here is the screenshot attached, clearly showing bytes with OPs not Bits when assigning WSRPLY to OPs.
 
 
et ceterum censeo: weak board protection supports NSA collecting our email account data
 

Attachments

  • Ocgi.PNG
    Ocgi.PNG
    13.5 KB · Views: 13
Efried said:
et ceterum censeo: weak board protection supports NSA collecting our email account data
 
I consider that your constant whining about real or perceived problems MUST be fixed by CAI or you're going to go in the corner and sulk, is getting beyond a joke.
 
The NSA and other LEAs are already collecting pretty much everything you do. The absence of encryption in sending email from the WC8 to your email gives them exactly NOTHING more then they currently have. Adding encryption of any sort (and I suspect you wouldn't be happy with anything short of 1024-bit) is so far beyond the capability of the processor and resources in the WC8 that it's simply impractical.
 
There are other ways to engineer around the problem you perceive to be the end-of-the-world that don't require everyone else be inconvenienced (or financially penalised) by the changes you seem to be demanding.
 
Using additional "bits" in outputs is something I documented here a year or two ago. There was some discussion about it, but in the end I didn't persue it. It was a side-effect of something else. While there may be some logic inconsistencies in the WC code, there is clearly logic inconsistency in YOUR USER CODE too, because stuffing a 32-bit number into a single-bit output is silly. "Expecting" the WC to second-guess what your code is trying to do is a recipe for disaster. Be generous in what you accept, be conservative in what you send. Code to expect and safely handle the unexpected, and to output what you MEAN in an unambiguous manner.
 
You have an older firmware, could you please update the firmware first, you can find the download link from this forum.  The display issue had resolved long time ago. Current firmware version is 3.201.8D5.  Your firmware is five version ago. 
 
We do not recommend you put board on the open Internet.  If your board is behind a firewall, you can use stunnel to enable SSL encryption.  There is a thread discussion back couple years ago, that explained how to configure stunnel so that on the open internet is SSL enabled email and HTTP, inside firewall, it changes to non-SSL.
 
CAI_Support said:
You have an older firmware, could you please update the firmware first, you can find the download link from this forum. 
 
The display issue had resolved long time ago. Current firmware version is 3.201.8D5.  Your firmware is five version ago. 
 
We do not recommend you put board on the open Internet.  If your board is behind a firewall, you can use stunnel to enable SSL encryption.  There is a thread discussion back couple years ago, that explained how to configure stunnel so that on the open internet is SSL enabled email and HTTP, inside firewall, it changes to non-SSL.
 
thanks for the update, I cannot update in the midth of operation of the device, since the procedure is not that easy. A tested one click solution would be preferred.
 
http://192.168.0.24/geto5.cgi gives 'µ' as result, not 0 or 1
http://192.168.0.24/geto7.cgi gives '½' in this very case.
So that speaks for a storage problem, glad that it has been fixed in newer releases.
 
Regarding email, I believe that the transmission of the password to the WC should be secured and the password displayed as '*',
 
You are reporting issue fixed five versions ago, but you don't want to update firmware to get fix. I am not sure what we can do to help you. The update procedure is very easy, many have done that.  Even we would develop something you wanted, you still had to update to get that feature.
 
As far as encryption goes, WC8 CPU can not handle encryption. We had tested back few years ago.  If you need email encryption from the board, please consider WC32.  If your firewall supporting stunnel, the email password will be also encrypted by stunnel even for WC8 boards.
 
Code:
http://cocoontech.com/forums/topic/21499-webcontrol-email-through-google-email-server/?hl=%2Bstunnel+%2Bsmtp
 
Back
Top