WC8 firmware 3.02.18b released

[LarrylLix]

Larry's rebooting is probably related to his power supply only 300mA, the board requires 450mA for normal running.


Your sales webpage indicates only 170 mA. People are not going to be happy being  misled by an proper specification before  buying support items that do not work.
 
I have no loads other than  SWE3 module. I am guessing about an additional 4-5mA. No O/Ps or I/Ps are connected.
 


http://www.cainetworks.com/products/webcontrol/webcontrol-faq.html
WebControl™ requires 9V DC power source not exceeding 12VDC power supply. Current consumption without load is about 170mA in active mode.
 
The v3.02.18a (6/12/2014) User Guide does state a 9V 1A supply is recommended.

 

[CAI_Support]

Larry,
 
Could you please let us know your sensor wiring, are they close to any power lines, or they running all by their own?
Some users had reboot problem, once they changed the wiring by separating sensor wires and AC wires, their problem went away.
We want to help you figure out where is the problem. 

 

[LarrylLix]

Could you please let us know your sensor wiring, are they close to any power lines, or they running all by their own?

The two 1wire sensors are at the end of 1m of cable  hanging over the back of a chair about 0.7 m from a  wall about 1.5m in the air. There are no power lines, other than the 9v dc cable feeding the CAI WC board. The WC board is mounted in the metal case sitting on the saddle of the same wooden chair.
 
If I could post a picture on this crippled forum I would. hcr :angry:
 
I checked the dc to ground, suspecting power line leakage and only got 0.5ac over a 10MegOhm meter impedance.
 
I am now recording times of rebooting to look for patterns or coincidence with other events.

 

[CAI_Support]

In the past, you mentioned that power supply was not stable.  Did you try a different power supply?
The BRE board and 2.0.2rev  takes 170mA during idle, the PLC boards in 2.2.2 rev takes 210mA current during idle.  During running, it will take more power.

 

[LarrylLix]

OK I have scoped the PS. Running 9.8vdc wit 224mV of 120Hz ripple. I can't detect any spikes of glitches using a high speed scope trigger settings. The PS seems OK. A little high voltage but shouldn't be causing a prom with an open case in an A/C home. The 5v 1wire PS has a little fuzz on it but nothing significant. I enjoyed watching the 1wire comm line for a while.
 
However....
I realise that my test for reboot using a detected missed 5 sec date & time update was not a fair reboot detection system.  A missed update from the WC to the ISY could be the result of other events ie. Ethernet data collision or lost packet and with no handshake? I am still getting 6-8 date&time Tx missed per day, on a 5 second update cycle.
 
I have now switched to a semaphore system where the WC transmits a -1 value to the ISY on WC reboot. The ISY then counts it(+1) and records the date and time, in a log of the last 8 events, looking for patterns.
 
I'll be anxiously watching and probably report back here tomorrow. (beach  day? Have to get a few in before deep snow comes again :-< )

 

[CAI_Support]

Larry,
 
Thanks for sharing your measurement. One thing you may also want to consider is that the problem you saw not happening during your measurement. Sometimes the power supply can work fine with no spike on power line, or with small spike on power line.   Not all power supplies are equal. A good power supply can filter out most power like surge and spikes.  If you have a reliable old equipment, taking that power supply out from that to use may give better result.

 

[LarrylLix]

Update:
 
I think I am discovering that the WC is NOT rebooting.
The logic that     8_sec_delay_in_the_received_5_sec_heartbeat = WC_reboot     is likely incorrect.
 
I have, just now, rewritten  this logic to count an 8 second gap in heartbeat, an 8+6 second gap, a 8+6+5 second gap, and a semaphore sent by the WC  PLC code to indicate reboot.
 
Overnight I experienced 3 missed heartbeats. The time recording of one recording exactly coincided with a background homework task the ISY does at 2 AM. Most likely the ISY was CPU bound and missed the heartbeat/clock update. NO reboot semaphores were recorded since noon yesterday!!

 

[CAI_Support]

Larry,
 
It is good to hear you fixed the problem :nutz:

 

[LarrylLix]

The problem is not totally fixed but I feel better about the data being missed occasionally. I can design some tolerance into my systems for this.
 
I believe the errors have been reduced significantly by some revisions in your firmware, especially 1-wire handling and thank you for that. The 1wire system seems much more solid now.
 
Some errors are caused at my ISY end by data being ignored on busy CPU / interface times.   The rest of the data transmission problems may never be located or fixed without handshaking and retries meaning a completely new protocol.
 
You have corrected the 0.5c resolution problem experienced by some DS18B20 users, with firmware upgrades  That is great for many of us and has answered many questions.
 
I was fabricating  my weather pole stack pipe. I have now removed an old wind turbine from the location to accommodate this. I hope to post this with photos, PLC code and explanations for other users, when done.
 
 
Keep up the good work!!!

 

[LarrylLix]

The PLC firmware does not behave very well in the WC board with 1wire sensors.
 
Here is what it appears to do on  1wire comunications errors.
 
  - On the first few 1wire comm errors the WC tries again to continue, basically ignore tham and carries on.
 
  - with more errors on the 1wire bus WC attempts to re-initialise the 1wire bus to "start over". It also restarts the PLC program code unecessarily
 
  - with repeated soft reboots the WC firmware eventually hangs, becomes unresponsive via the WebControl console, and has even deleted my whole PLC program, Network setup, Notification setup and apparently cleans out the whole user space. I suspect this may be some sort of stack overrun from rebooting incorrectly. This is repeatable at a random time, every time,  if too many 1wire errors are encountered.
 
The only solution at that time is to power the WC board down and reboot cold. System parameters and user setup may have to be reprogrammed if they are cleaned out. I have had this happen twice now. This appears to be a lost cause with anything but less than a 1m cable length on the 1wire. I have varied the 1wire timing parameter up and down, replaced my power supply with a very clean 9v switching unit, tried different sensors, varied termination resistors, and scoped the 1wire bus, looking for noise. This just shouldn't be happening, noise and 1wire bus errors or not. The 1wire bus problems should not interfere with higher level PLC functions, GUI interface or running amuck erasing user area data.
 
Strangely enough the 1wire bus signals continue after the PLC hangs, stops attemping transmissions on the Ethernet port and becomes unresponsive.

 

[CAI_Support]

Larry,
 
I think that is probably due to noisy somewhere.
WC8 firmware does retry to talk to sensor, if the sensor is failed in the communication.
However, WC8 board does not "start over" by itself.  WC8 CPU has watchdog timer. If some external noise through power or any input caused the CPU not able to finish its task, the CPU watchdog timer will automatically restart the board.
 
Does your area have strong RF radiation?  You may look this article to see if you can add some resistors in each sensor to make it more reliable?
 
http://www.maximintegrated.com/en/app-notes/index.mvp/id/148
 
Another thing is to make sure the power supply providing enough power to the board. During CPU running and IO pins activity, it will demand more power than idle state.  One reason for some users experience rebooting is the power supply not providing enough current during peak running.

 

[LarrylLix]

Larry,



I think that is probably due to noisy somewhere.

WC8 firmware does retry to talk to sensor, if the sensor is failed in the communication.

However, WC8 board does not "start over" by itself. WC8 CPU has watchdog timer. If some external noise through power or any input caused the CPU not able to finish its task, the CPU watchdog timer will automatically restart the board.

Does your area have strong RF radiation? You may look this article to see if you can add some resistors in each sensor to make it more reliable?

http://www.maximinte...ndex.mvp/id/148

Another thing is to make sure the power supply providing enough power to the board. During CPU running and IO pins activity, it will demand more power than idle state. One reason for some users experience rebooting is the power supply not providing enough current during peak running.


Sorry. No luck there. the noise idea isn't doing it. The 1wire firmware is doing it.
 
I did more proof of this.
 
With exactly the same PLC code and wiring attached to the WC board with either the SWE3 module unplugged or the data wire disconnected at the sensor end or at the WC board end the WC performs almost flawlessly for days at a time. The WC was booted up with the sensors attached and as soon as they WC was initialised and sending sensor data via Ethernet, I disconnected the data line using the many methods as discussed above. There are no transmission errors, delays and the board does not reboot or crash and lockup. A combination date and time data word is sent every 5 seconds, around the clock, without errors.
 
If I connect short lead (<=1m) sensors to the WC board the WC board functions fairy normally and misses very few data transmissions in a day.
 
However, as soon as the the 1wire TDSO factor is adjusted to attempt to make the 1wire communications fail, or  sensors, with longer cables, are installed the WC board begins to reboot occasionally, eventually hangs, and cannot be accessed with the browser setup program. As I stated above, the CPU, apparently running amuck,  occasionally completely cleans out all user parameters and PLC codes. This happened, again, last night and  deleted my notification setup data. The PLC program, UROM and temperature probe setups were intact this time. That wasnt noise.  This doesnt happen with the same wiring attached and the wire data terminal disconnected at either end of the cable. This is software with badly handled communication errors.
 
So far I have tried and scoped healthy two different power supplies. one analogue 300mA and one switching.1.5 ampere.
I have tried various length of cables, replaced every one, and sensor combinations,
I have tried various terminations resistors, 10K at either end, both ends, and repeated the same combinations with 5K termination combinations.
The unit is still running on my test bench with no cable intermingling, AC or RF signals within 1m (3').
The WC board is in a metal box, all other cables disconnected except the 1wire needed for testing, with all unused conductors and chassis grounded.
 
Let me repeat this. 1wire bus communication errors should not reboot or crash the whole board and they are. After reading some of the archive posts here I see other have also given up from the same 1wire bit-banger interface  problems. This appears to be an ongoing problem that has never been resolved.

 

[CAI_Support]

We will try to set TDSO to an out of range value to see if we can re-produce the problem.  We have been testing with best TDSO value and did not test with worst TDSO value before.
 
Thanks for the reporting of this with your setup.  Although most users did not experience this, we want to make sure our code reliable to 100% users and not having this problem.
 
Larry, please let us know what is on your 1-wire bus, would the problem happen with single DS18B20, or single DS2438 chip?  Or it will happen with combination of chips?  It will help us to setup a test like you did.  The simplest way will make testing easier.

 

[LarrylLix]

This happens with with two scenarioes, a single DS2438 chip and also with a DS18B20 parallelled at the end of the DS2438. This happens very rarely with a 10-12' cable. I would have to make some wiring cludges to get only a DS18B20 at the end of a 25 foot cable.
 
I am not sure where the TDSO is matching in the signal but I have tried 1,2,3,4,5,6,8,12,20,30 usec.With shorter cables from 1-6 usec seems not bad.

 

[CAI_Support]

So this happens always having DS2438 in the picture. If no DS2438 on the bus, would it also fail?
Is that 25ft cable cat5 cable using 3 pairs or using 1 and half pair from it?