serious issue

Efried

Active Member
With the help of my new graphic interface(http://cocoontech.com/forums/topic/27325-overview-page-wcs/#entry221786), I detected that an alternating control got stuck. Instead of toggling, one TTL got stuck i.e the value of OP2 did not change anymore. After rebooting it began working again as intended. Since I found no hint in the code whatsoever, might that be an additional problem to the 1-wire problems we already know? If this is the case we should refrain using WC as controller for sensitive processes incorporating some threat for safety and lives.
 
Efried said:
 Since I found no hint in the code whatsoever,
 
Not finding your coding error is like a typist not finding their typo.
By not finding your mistake, you can't just "assume" the problem is somewhere else. Only when you actually FIND the problem can you be sure what it was. Conjecture about what might (or might not be) is pointless and counterproductive.
 
From my experience with these devices, I think it FAR more likely you've a coding error you simply haven't spotted. It may be an unusual condition you haven't expected, or that you don't think could ever happen, but I bet you good money it has!
 
Efried said:
If this is the case we should refrain using WC as controller for sensitive processes incorporating some threat for safety and lives.
Using this board for safety critical things is a REALLY BAD IDEA even if there aren't any known bugs. Having been involved in projects that do have safety issues I suspect this board is not designed for safety critical control. And it doesn't have to be control of a nuclear reactor or some similarly serious thing to be safety critical. It might be a kitchen oven temperature control that's done in software (without a hardware over temperature cutoff that doesn't rely on the software).
 
rossw said:
Not finding your coding error is like a typist not finding their typo.
By not finding your mistake, you can't just "assume" the problem is somewhere else. Only when you actually FIND the problem can you be sure what it was. Conjecture about what might (or might not be) is pointless and counterproductive.
 
From my experience with these devices, I think it FAR more likely you've a coding error you simply haven't spotted. It may be an unusual condition you haven't expected, or that you don't think could ever happen, but I bet you good money it has!
 
yes of course it was probably my fault. By using higher TTL output bits as counter, may be this had side effects on the TTL level on lower output bits.
 
Apparently CAI support thought that I had had a bad experience with their board from my comments above as I got a private message asking me to explain the problem. I have no direct experience or problem with the WebControl board. I didn't mean to imply (and I don't think I did) that there is anything wrong with their board. But doing safety critical control on ANY board is a bad idea if it isn't designed for such things. I work on things that UL considers safety critical so I have some experience from that angle. There is significant review and testing of both the hardware and software. I was just responding to the OP comments about using this for things that involved "some threat for safety and lives." If the WebControl board has been reviewed and tested for those type applications I didn't see any reference to it in their literature but I would be happy to be proven wrong. All this, including my original response, is obviously just my opinion. Anyone contemplating such applications is advised to do their own investigation and come to their own conclusions about suitability.
 
We do support our customers, as most had experienced that we do respond to any problem report.  We treasure our customers and help them to success, there is not comparison.  If anyone experienced any problem, definitely he can write to us directly or post here. However, people sometimes post problem did not exist due to not familiar with our product, that would not embarrass us.  Honest and trustful is what we practice, because we believe good overcome evil.
 
If this is the case we should refrain using WC as controller for sensitive processes incorporating some threat for safety and lives

This is absolutely correct. There are things that could be done to increase security with the WC8 board but they could be very clumsy depending on security level needed.
 
I installed and repaired SCADA systems for 34 years and some of the techniques they used were:
 
- checkback confirmation of command signal from output back to input.
  eg.   send O/P 4 On.  WC would echo command O/P 4 On. After confirmation, originator then sends "OK Go ahead". Works well at the human level. GUI object can flash and have to be second function operated.
 
- multiple code matrix controls.
  eg. send O/P 4 ON, send O/P 8 OFF, relay at grid intersection of O/P 4 and O/P 8 has difference of voltage and operates.
         O/P 1-4 would be normally low, O/P 5-8 would be normally high. a 4 x 4 matrix allows 16 relay outputs.
 
- limited current source. Only one relay coil can operate at one time due to limited current to all relay coils. If multiple simultaneous relays are attempted none operate.
 
- BCH and checksum communications. Each command code could be followed with the bits complement and the two XORed or other check etc. 
 
Some of these techniques could be implemented in the lowly WC8 board for security but some functionality may be lost in the process.
 
Loss of communication is always a problem and high level secure controls need dedicated copper / fibre lines with backup schemes. 
 
Larry,
 
I would have to respectfully say not true.  All those you mentioned can be implemented in PLC code using commands provided.  You mentioned four things.  But not have enough information provided. 
 
1) in the automated system, where the send OP4 ON command coming?  from HTTP or from server?
 
2) Do you know there is a datatype called ALLOUTS that allow you in PLC do bit manipulation then sending all OP at once?
 
3) WC8 can not provide relay coil power, that is by design. The relay board should have its own transistors.  Adding those to the board is not hard to do, but it will increase cost for many who do not have that need.
 
4). WEBSET is two way communication. It works in one way, but  user did not use the other way because server CGI code limit should not be counted as our fault.
 
CAI_Support said:
We do support our customers, as most had experienced that we do respond to any problem report.  We treasure our customers and help them to success, there is not comparison.  If anyone experienced any problem, definitely he can write to us directly or post here. However, people sometimes post problem did not exist due to not familiar with our product, that would not embarrass us.  Honest and trustful is what we practice, because we believe good overcome evil.
 
My concern would be that you favour personal coaching and support over the supply of investigative and debugging tools too much. I have no time developing my two tools further but I think it could perfectly make sense handing over the Python code to students for further developing such tools for little money.
1. statistical analysis what lines were called how often, detecting not reached (dead) code, based on statistical or random input data.
2. code walk through, showing the variables (also bits) (debugging/tracing)
3. Status overview combining multiple WCs (SVG no scripting)
Point 3 would require options for the cgi returns &unit=0 avoiding units an CR LF.
 
I would have to respectfully say not true. All those you mentioned can be implemented in PLC code using commands provided. You mentioned four things. But not have enough information provided.

1) in the automated system, where the send OP4 ON command coming? from HTTP or from server?

I am not sure what you are disagreeing with but..
The system can be automated or in the case of SCADA ststem I worked with, manually controlled from a distant location across the city by a human operator running a large database master computer system in a control room. The WC8 board would be acting as a RTU (remote terminal unit). Control commands coud be entered into WC8 any way they can get there.
 
 

2) Do you know there is a datatype called ALLOUTS that allow you in PLC do bit manipulation then sending all OP at once?

Yes. The ALLOUTS could make the implementation easier for security.
 
 

3) WC8 can not provide relay coil power, that is by design. The relay board should have its own transistors. Adding those to the board is not hard to do, but it will increase cost for many who do not have that need.

The relay control board would be too complex and too many large components to be on the WC8. Large relays, large terminal blocks for 120-240vac outputs, and other components would be prohibitive. Users would not want high voltage controls mixed with sensitive logic levels.
 
The relay board could provide 16 relays matrixed 4 x 4.
-  OP1-4 could drive inverting buffers via a common point to common negative through a current limited source set to 1.25 x relay coil current. This would source the negative sides of 16 relays coils.
- OP5-8 could drive non-inverting buffer / level translators for the relay coil voltage positives. 5-24vdc. This is a change of level idea from my previous post. Which ever failsafe level happens when the WC8 boots up needs to be used as the OFF level.
 
The current limiting negative supply ensures that only one relay can be operated simultaneously. The 16 relay coils could be 8 latching relays is continuous closed circuits are required.
 
 

4). WEBSET is two way communication. It works in one way, but user did not use the other way because server CGI code limit should not be counted as our fault.


This is a low level communication protocol. There may be some checkbacks to confirm proper communication. Higher level checkbacks are required in these systems.
BCH checking is not likely going to be performed in PLC code but other simpler math methods could be employed.
 
If one command byte for OP1-8 is issued /needed and since the protocol allows for at least 16 bits the command byte could be duplicated in the upper 8 bits, inverted first, or other encryption methods used. The PLC could check the security and send back the same encrypted command to get confirmation from the initiating master control first. Only after the initiating master end sends an ACK the the PLC would then dump the command ALLOUTS on the relay board operating ONE relay via the matrix wired relay bank.
 
 
 
The specially designed relay board would be the key to most of the security. The WC8 could look after the communications security, fairly well, but insurance against wrong relays operating eg. an output burned out =stuck on at high level, would have to be done in the special relay board wiring.
 
Two WC8 boards could use the technique for a matrix of 256 relays or 128 latching relays or use an arbitration scheme to decide who will operate the relays in parallel for backup communications channels etc.
 
Efried,
 
I am afraid a lot of times you posted your problem as WebControl problem, but actually is your configuration problem or your code problem.
How to debug is an art one must learn by working on it, there is no tool would eliminate all the learning of hardware and electronics principles.
If you want to developing a debugging tool, that is a good thing, it will need to learn WC very well first.  If you found something in your development tool
did not work, first assume that is the debugging tool's bug.  In that way, others will be a lot easier to work with you.
 
Hi Larry,
 
Sounds like you need a relay system with control board that can not tolerate any fault or intrusion.
Ross might be able to help you design a relay board with those checksum requirement.
What will be your initiating master controller then?  If that has a web server, it can use WEBSET command two way communication feature to establish confirmation requests.
 
CAI_Support said:
Efried,
 
I am afraid a lot of times you posted your problem as WebControl problem, but actually is your configuration problem or your code problem.
How to debug is an art one must learn by working on it, there is no tool would eliminate all the learning of hardware and electronics principles.
If you want to developing a debugging tool, that is a good thing, it will need to learn WC very well first.  If you found something in your development tool
did not work, first assume that is the debugging tool's bug.  In that way, others will be a lot easier to work with you.
 
no, I was not distributing guilt, but my firm believe is that customers will also check out for supportive tools. Unfortunately your business model does not comprise that. As external you can only perform reverse engineering finding out the exact WC logic for making a debugger. Starting with the handbook is no good idea. For the time being you could deny or confirm the side effects of iterating TTLs.
 
Hi Larry,

Sounds like you need a relay system with control board that can not tolerate any fault or intrusion.
Ross might be able to help you design a relay board with those checksum requirement.
What will be your initiating master controller then? If that has a web server, it can use WEBSET command two way communication feature to establish confirmation requests.

No I think we have some bad communication confusion here :D
 
I do not need or want a relay board. I have a few SCADA RTU's in my workshop if I wanted supreme reliability and security.  Not much fun except I would have to write a master control driver and find a 4-wire modem again.  :P
 
I was attempting to explain how security could be implemented with the WC8 board  for Efried's concern about poor security and reliability.
 
Thanks Larry, I understood. Needs only some 12 V AI tolerance going DC or aconvertrr from  250 V sensing switched AC. I guess also hall or inductive measuring would be ok?
 
Back
Top