WC8 firmware 3.02.18b released

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?


One and a half pairs. IIRC the ground and data use the centre pair and 5v using  random lone conductor. They were chosen by others using RJ45 jacks for 1wire.   
 
I understand the DS2438 has a very fast A/D turnaround unlike the DS18B20.
 
If reread my post bck  few the 1wire inteface seems to retry many tiems then the board reboots and then eventully hangs and won't service the Ethernet stuff. This is what makes me think of a stack overrun...maybe too many sub calls without a ret/rts on reboot (programmer's "too many errors giveup").
 
The other conductors, especially the other half of the pair containing the data conductor, are all connected to the designated ground wire at one end, right?
 
I was trained professionally in equi-potential grounding techniques for logic systems and later for power transmission grid systems and associated controls and they were used here. Data conductor? Read my previous post.
 
Regardless of interference, the PLC programme  should not continually reboot and eventually hang the PLC program, and all Ethernet functions cease, when encountering 1wire comm errors, and work fine when not communicating, using the same wiring connections, in a predicable and repeatable fashion.
 
Just checked today again. With 8 Websets being updted every 5 seconds for the last 24 hours, not one missed heartbeat/update. The weather data is being created by the WC analogue input as bad and frozen to their last readings and th clock is dynamic.
 
Thanks.
 
Larry, 
 
We tested with a DS2438 and two DS18B20, set TDSO to 30, all 3 sensors reported failed.  We have run that way for two hours and have not seen rebooting.  We will keep testing till the problem happened.
 
At the mean time, we made a test firmware for you to test to see how this change impact on your setup.
Please download that from

http://www.cainetworks.com/support/download/update-PLC3-2-18b2t.zip

 
Please use the regular update method and utility to update your board, to see if that works better for you.
We will continue work with you till we find solution for you.  
Thanks again for your detailed report.
 
Larry,
 
I loaded up this 18b2t version firmware above, and set TDSO to 3, and all 2 DS18B20 showing fine and DS2438 showing fine. they properly work.
I then set TDSO to 31, which is for sure fails any 1-wire communication, since 1-wire bus can never be that long, like more than 500ft.  All 3 sensors showed failed.
 
I kept that running for four hours so far, the board does not seems rebooting at all.  The reason I am saying the board is not rebooting is that I can go to temp sensor screen still see 3 sensors' ID there.  If I set TDSO to 31 and reboot the board, temp sensor screen shows no sensor detected.
 
Please try this version and let me know if your board working better.  Thanks.
 
I loaded the test version and connected up a short cable and it seemed to run fine for a few minutes. Then I installed a 25 foot long extension and the board not only reboots almost continuously, it crashes and will not respond to Ethernet  access to the setup or any other browser screen after about ten sconds of running every time. It wiped out user setups and the PLC program again and for the third time caued my ISY994i to reboot somehow. I didn't know that was possible through the REST interface on a completely remote network.
 
I changed the PLC program to a very simple read and WEBSET the values on simple loop without much logic and the same thing happens as long as I have a longer cable on the WC8 board 1wire interface. I went back to the shorter 4-5' cable and it runs but reboots about 10-20 times per hour.
 
Whatever the test firmware did, the 1wire interface interfering with the other WC8 board functions  seems worse than the previous   versions .
 
Thanks.
 
Larry, 
 
Then it is not firmware at all. The 1-wire bus on wC8 directly connected to a CPU pin.  If there is any noise, it can directly send the noise to CPU, cause it running unreliably.  The other SEW3 testing thing you were using working fine, because it uses an 1-wire bus controller which having additional transistor and RC circuit inside to prevent any noise reaching to the CPU.
 
I would recommend to add little RC circuit and maybe a 5V clamping diode to prevent any spike pulses going into CPU.  I wish we have similar environment so that we can test out and find a best filter circuit for you.    It is not 1-wire bus error caused problem, otherwise, shorter cable could generate errors.  We have long cable here with timing set to wrong, so that it will fail all the measurement, but it does not reboot.  It is a long wire that becoming antenna picking up maybe from cell phone tower or some other RF radiation.
 
Another thing to try is to use a WC32 board.  WC32 has a dedicate 1-wire bus controller similar to SEW3.
 
I assume you mean SWE3 sensor as I don't know what an SEW3 is.
 
I have tried diode clamping the 1 wire bus with three diodes and termination resistors. Scoping the data line shows fairly clean data except for expected ramping pullup slopes.
 
This board has just been moved to my workshop building into it's metal case, electrically ground bolted inside an industrial  metal electrical enclosure in a an all metal sheilded wall and roofed building that no radio can even receive a signal inside, with no power devices running and the lighting circuit off at the panel. No appliances or electrical equipment ever  run when i am not there as the electrical panel is shut down. The only source of electrical noise would be through a 18 x 36 inch window from a house over 40 feet away across my lawn.  I find it very hard to believe there is any RFI or EMI affecting it.
 
I have  also proven, with no change in wiring or environment, the WC8 works when no data is being exchanged but doesn't when the 1wire polling is functioning so I am not buying that anymore.
 
What was the change you made in the test version of the firmware that made the 1wire interface hang the WC8 more that the previous version or will the Engineers not let you disclose that either?
 
 
Many people, here, and other forums, are now telling me the 1wire bit-banger interface on the WC8 doesn't work more than 10-15 feet cables using any methods they have tried on their boards, either.
 
I would be happy to hear from people that have made this 1wire interface work with longer sensor cables and what methods they have employed to make them work.
 
LarrylLix said:
Many people, here, and other forums, are now telling me the 1wire bit-banger interface on the WC8 doesn't work more than 10-15 feet cables using any methods they have tried on their boards, either.

 
I would be happy to hear from people that have made this 1wire interface work with longer sensor cables and what methods they have employed to make them work.
 
PERSONALLY:
I have a slew of them around my house, each with 24 *METRES* (78 feet) of cable on the 1-wire bus.
I have a bunch of them installed inside racks in datacentres. There is a HUGE amount of RFI/EMI in there. They are a mix of 24 metres (78 feet) and 5m (15 feet) cable on the 1-wire bus.
I have a few installed at solar hot water sites with a mix 1-wire lengths, most around 25 metres, one has 55 metres (180 feet!)
 
I will grant you that the very long one DID have some problems. I added an extra 4K7 pullup at the end of its longest run and it was ok, but would not always detect all the 1-wire devices. We shortened the cable 20 metres and it's been fine ever since.
 
I don't think *ANY* of my devices have as short as 10' cables, and I do not see your behaviour.
 
LarrylLix said:
I would be happy to hear from people that have made this 1wire interface work with longer sensor cables and what methods they have employed to make them work.
I agree the bit-banged WC8 1-wire interface is somewhat sensitive to noise but at least in my case I have found it to work reliably over long cables. The greenhouse controller uses 7-sensors on about 40M and woodheat controller has 3 sensors and 15M of cable. Most of the cable is salvaged 20AWG 4-conductor non-twisted pair.
 
Both systems are wired as a bus with short stubs (<2M) per the Dallas app note. CAI recommends far end pullup. I could not find any reference to that in Dallas/Maxim app notes but it makes sense to "stiffen" the data line. Did not see any difference with or without the far end pullup. Both systems clamp 1-wire data line to Vcc and Gnd with 1N4148 diodes. I was reluctant to use a series resistor for fear of degrading noise immunity. System digital ground is bonded to the case which is connected to safety ground.  I'm using default 1-wire timing. These are older systems running 3.02.17d and 3.02.17b, just missed the upgrade to downloadable FW.
 
/tom
 
Thanks Ross.
 
What firmware version are you running on those WC8 boards and did you need any 1wire clamping/protection components?
 
Thanks Tschmidt
 
 
This seems like there are two different versions of this board out there. Some that work with the 1wire and many that don't work. Most report about 3m as the limit. I am finding the same.
 
I guess if I installed an earlier version of the firmware there would be no going back to recent updates as the f/w loader would disappear. This should not be a problem as the board is headed for the trash anyway.
 
Larry,
 
All the firmware running 3.02.xx are using rev 2.2.2 board. The last 3.02.18b2t firmware changed that when DS2438 failed, it will display that under temp sensor as failed and retain the last valid ADC value from DS2438.  Before, DS2438 failed was not displayed and its ADC value was zeroed out. 
 
Previously, you mentioned the problem you experienced was when 1-wire device failed.  So we focused testing that by changing the TDSO to 30-31.  That made sure 1-wire communication would fail.  But our tests showing with constant failure over 1-wire bus, WC8 did not reboot.  We agree with you that 1-wire bus communication failed, WC should not reboot. It looks like rebooting is not caused by 1-wire communication failure in our tests.
 
However, your tests showed the problem does related to longer 1-wire bus.  That lead us thinking the problem is longer bus wire picked up more RF noise. Our office located in a city that having minimum cell phone signal, even VZW and ATT cell phones can not reliably work. We have whole spool of cat 5 cable connected to 1-wire bus and not rebooting.  However, a lot of places do have strong RF noises.
 
Recently I noticed a new invention was to use 1ft wire picking up RF signals to power a tiny microcontroller.  I am sure 20ft wire would be able to do some real interruption in that place.  If the environment has strong noise, it is best to have Tom did with two diodes, one clamp to 5V, another one to the ground, so that positive pulse being clamped to 5V and negative pulses can also be discharged through that ground diode.  Please refer to the picture below for the diodes orientations:

http://www.maximintegrated.com/en/images/appnotes/244/2082Fig01.gif

 

diodes in the picture are BAT54:
http://www.ebay.com/itm/180874606536


Larry, we really wants to find out what kind of problem that is, so that in our next generation board we could incorporate any filtering circuit into the board.  We did not want to use dedicate 1-wire bus controller for saving money for the customers, we believe having some of the proper filtering, it will be able to get rid the problem.
 
LarrylLix said:
This seems like there are two different versions of this board out there. Some that work with the 1wire and many that don't work. Most report about 3m as the limit. I am finding the same.
Since you were able to update the FW I assume you are using the 2.2.2 hardware revision.
 
But just in case there is an earlier hardware version (several years ago) 2.0.2 had a UART in what is now bare board but more important for this discussion ran the 1-wire bus off 3.3 rather then 5V. If you have that old hardware you can move the 1-wire Vcc lead over to the humidity sensor and run the 1-wire buss at 5V. See it that has any effect.
 
/tom
 
Since you were able to update the FW I assume you are using the 2.2.2 hardware revision.

Yes. I am running 2.2.2
 
 I have tried caps and diodes and term resistors on both ends of the comm. cables. If I disconnect the 1wire device at the far end of the cable the board after the initialisation lock in of the devices in the WC8, rebooting and hanging stops and runs just fine for 24 hour tests, at a time, updating 8 parameters every 5 seconds with not one error. The board runaway only happens when the WC8 is receiving data from the 1wire IC on the end of the cable. There is no static or noise difference involved in the two scenarios, only the data response from the sensor at the end.
 
If I hadn't heard the same thing  from several other users I would just think my board was defective.
 
I suspect the 1wire drivers do not get updated with the firmware versions.
 
Thanks!
 
LarrylLix said:
The board runaway only happens when the WC8 is receiving data from the 1wire IC on the end of the cable.
Curious, I assume you have tried multiple versions of that last 1-wire device just as a sanity check to make sure it is not the device itself.
 
Since the 1-wire bus is a pretty ugly transmission line (lots of reflections) have you tried adding/removing a few meters of cable at the last device?
 
/tom
 
Back
Top