WC8 firmware 3.02.18b released

[LarrylLix]

OK. For the last few hours I have running about 35' of cat 6 cable to a DS18B20 probe without a single error. I leave the DS2438 sensor connected  until I see my PLC code flash the green LED in a particular  pattern that indicates the PLC code is running. At that point I know the WC8 board has initialised and memorised  all the sensors. Then I remove the DS2438 sensor from the end of the cable and leave just the DS18B20 probe. Works like a charm, every time. I twisted the cable through power lines in my shop,  wrapped it around dual fluorescent fixtures, through the handle of a 1200W radiant heater with the probe hanging from it and flicked the heater and lights on and off many times. I started and stopped my 2HP dust collector beside the WC8 (running of an X10 wireless with a needed 60A mercury wetted contactor) . Absolutely no problems or missed data reports for about 3-4 hours at 1sec per update.
 
Hell I even connected diodes, a cap and a termination resistor on the parallel terminal blocks of the 1wire bus back at the equipment cabinet while it was running, static zapping the connection with my bare hands on the screwdriver making the connections. Not one error at one WEBSET update every sec for 3-4 hours. No reboot, no hanging.
 
Then I plug the DS2438 sensor back in. The WC8 sends one or two scans of data from it and the board hangs, reboots repeated sometimes getting out one WEBSET from the sensor data before it hangs again.
 
Can you tell me I have a sensitive board or bad cabling here, reading this? It isn't the board being disturbed with RFI, EMI or any other excuse.  I think it has become very apparent it's the DS2438 data receiver part of the 1wire driver that is crashing with long cabling on a DS2438 sensor. With less than 10 feet it's fairly reliable and works 99.999% of the time, even with the TDSO adjusted from 1us to about 13usec.

 

[CAI_Support]

Larry,
 
Thanks for your invaluable inputs.  So that the problem is not hardware, nor DS18B20 sensors, but related to DS2438 only.
Something does not click is why cable length has any differences with this sensor, but we will continue digging into this.  Did you run the 18b2t firmware or just 18b2 firmware?  As I mentioned 18b2 version did not set error flag before.  But 18b2t does.
Please make sure the test is on the 18b2t firmware.  Thanks.

 

[rossw]

Thanks Ross.
 
What firmware version are you running on those WC8 boards and did you need any 1wire clamping/protection components?

 
 
I have a bunch of boards, some old 2.0.2 hardware, most 2.2.2. Versions almost all pre-date the field-upgradable firmware versions. I posted SOME of the versions in response to one of your other queries a couple of weeks ago, although I have quite a few different version in active use.
 
I have not found it necessary to use any clamping or protection devices on any of my installations. It's probably a good idea, but to date it's never been required.

 

[rossw]

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.

 
Good catch, and thanks for the reminder. When I got my original boards, I found running more than 3 sensors was very "hit and miss".
My solution was the same - except I hacked the boards, cut the 3.3V supply to the temp sensors and ran a link from the 5V rail to power them directly.
I never had a problem again.

 

[LarrylLix]

Did you run the 18b2t firmware or just 18b2 firmware? As I mentioned 18b2 version did not set error flag before. But 18b2t does.

Please make sure the test is on the 18b2t firmware. Thanks


Confirmed. I am running the ...b2t version of the firmware.
 
Thank you for your persistence and everybody's input! This is irritating when some say wonderful and others say junk for the same item. There has to be a difference somewhere. If the DS2438 driver has a problem with too many errors somehow it could fit most report differences...maybe.  Perhaps a way to simulate would be to put the TDSO at a flakey point so some succeed and some fail??
 
Another clue that is puzzling it that unplugging the DS2438 after initialisation does not cause it with no return data. I think I can see the poll on the scope of the 1wire with no response and other polls with response all spaced every second.

 

[CAI_Support]

Larry,
 
Thanks for your confirmation.
We are very confident that with 3.02.18b2 firmware, all DS18B20 sensors will work reliably, like you have tested.  Anyone said junk before should try to update to this firmware.
 
DS2438 is a new sensor support added since 3.02.18 firmware.  This sensor command sequences are much complex than DS18B20. It converts faster with more functions, it also requires more than twice 1-wire bus commands to do things.  We will focused on finding problem for this sensor for you.Those situations you reported will help us to find the cause and fix it for you.
 
Buying WebControl is different from buying a board only thing, we have a team of engineers working on your behave. We will find the problem and fix it for you, it may take some time for a complex situation to be fixed, but we do not drop the ball and leave you alone.

 

[CAI_Support]

Larry,  I loaded with this latest 18b2t firmware and put DS2438 on the end of 50ft cat5 cable, with two DS18B20.
When I adjust TDSO to 10, one of the DS18B20 failed, so I made TDSO to 8.  All 3 temp sensors running okay.
I then manually set VAR1 to 9999 through PLC code.  After seeing VAR1 changed to 9999, I delete the PLC line for setting VAR1.
In this way, if board ever reboot, VAR1 will be zero.
 
This board has been running all morning so far with VAR1 displaying 9999 all the time. 
Larry, Have you tried the latest 18b2t firmware?  Do you experience any difference?

 

[LarrylLix]

I loaded the update firmware "update-PLC3-2-18b2t" firmware showing on screen as "03.02.18.b3". Complete disaster.
 
I cannot access the control console after power cycling the board about 50% of the time. The PLC code runs mostly for a few seconds then hangs. Various setup screens will not load into the browser taking turns hanging on loading.
 
I managed to try TDSO of 2,3 & 4 and then power cycle each time but none work for more than 30 seconds before the board gets crazy.  At times I can access the system status screen and my counter input was counting including  WEBSETting the counter data externally while the 1wire inputs are all showing 0. Sometimes the temperature setup screen shows the probes disconnected and the board needs to be power cycled to get them back. Other times the PLC will not run at all for more than a few seconds or WEBSET updates.
 
I will try disconnecting the DS2438 probe to get control of the board and try reflashing the same version again.

 

[CAI_Support]

Larry,
 
We don't think PLC would hang, because if anything hang for longer than half second, watchgod timer will reboot the board. The fact you did not see the board reboot every second -- when you thought the PLC hang, it is actually running inside.  If you have TTL output turn on and off with little LEDs, you will see PLC turning them on and off while you thought PLC hang,  The network operation requires enough RAM being allocated.  When browser busy sending and receiving from HTTP port during restart, WEBSET call may not get through, because is depending on the same RAM to do the WEBSET call.
 
The problem you are seeing is the browser from computer keeps sending and receiving from browser memory. If you close browser, then delete old cache and start browser again, you will see everything running smoothly.  During board rebooting, browser cached a lot of refresh calls trying to get through.  When those cached calls not exist, the WC8 memory will be able to handle all the normal calls.  Even you don't do anything, after sometimes, the HTTP buffer cleared over the time, WC8 will be able to send out WEBSET normally.
 
We did made a little change in the 18b3 firmware to change the behavior of the DS18b20 getting back to 9 bit.  The update firmware can be downloaded from here:
 

http://www.cainetworks.com/support/download/wc8plc030218b3-update.zip

we also added gui update file, in the gui change, it will now allow both '#' and ';' being used as comment denotation

 

[LarrylLix]

We did made a little change in the 18b3 firmware to change the behavior of the DS18b20 getting back to 9 bit.

I installed the updated version but the DS18B20 sensors, after two power cycles, still only report 0.5 degree resolution. Was your comment "discontinuing" the 12 bit reporting or "fixing it"?
 
I had to disconnect the DS2438 sensor on the 30' cable to update the firmware as the WC8 board would not stay running without hanging continuously and rebooting every 5-10 seconds.
 
It now hangs and reboots about once per hour with the DS2438 on a 5' cable, with whatever changed. The WEBSET functions stop for about 10 seconds and then the board reboots (or the PLC programme restarts).
 
It still seems most other board functions stop once DS2438 errors happen on the 1wire interface.

 

[CAI_Support]

Larry,
 
What is your firmware build date, please let us know from /api/status.xml
We are running this firmware with both DS18B20 that reprogrammed to 12 bit resolution, as well as DS2438, on a 50ft long cable.
We do not see any problem at all.
 
When you say reboot, do you see the bootloader actually turn off green led then only NIC socket has LEDs blinking?  I know your PLC code actually turn off green LED most the time.  PLC program only being stopped when upload new PLC program automatically. During other time, PLC program can not be stopped.  You may want to have LED on TTL output and turning it on and off to see PLC execute those commands all the time during board running.

 

[LarrylLix]

<?xml version="1.0"?>
-<response>
<firmware>v03.02.18b3</firmware>
<op1>0</op1>
<op2>0</op2>
<op3>0</op3>
<op4>0</op4>
<op5>0</op5>
<op6>0</op6>
<op7>0</op7>
<op8>0</op8>
<ophex>0x00</ophex>
<var1>904150125</var1>
<var2>255</var2>
<var3>255</var3>
<var4>255</var4>
<var5>661</var5>
<var6>212</var6>
<var7>327</var7>
<var8>450</var8>
<ip1>0</ip1>
<ip2>0</ip2>
<ip3>0</ip3>
<ip4>0</ip4>
<ip5>0</ip5>
<ip6>0</ip6>
<ip7>0</ip7>
<ip8>0</ip8>
<ts1>25.5 C</ts1>
<ts2>unbound</ts2>
<ts3>unbound</ts3>
<ts4>unbound</ts4>
<ts5>21.3 C</ts5>
<ts6>unbound</ts6>
<ts7>unbound</ts7>
<ts8>unbound</ts8>
<tstat1>ok</tstat1>
<tstat2>unbound</tstat2>
<tstat3>unbound</tstat3>
<tstat4>unbound</tstat4>
<tstat5>ok</tstat5>
<tstat6>unbound</tstat6>
<tstat7>unbound</tstat7>
<tstat8>unbound</tstat8>
<romcode1>26470B8F0100</romcode1>
<romcode2>281471D30500</romcode2>
<romcode3>000000000000</romcode3>
<romcode4>000000000000</romcode4>
<romcode5>000000000000</romcode5>
<romcode6>000000000000</romcode6>
<romcode7>000000000000</romcode7>
<romcode8>000000000000</romcode8>
<boundromcode1>281471D30500</boundromcode1>
<boundromcode2>000000000000</boundromcode2>
<boundromcode3>000000000000</boundromcode3>
<boundromcode4>000000000000</boundromcode4>
<boundromcode5>26470B8F0100</boundromcode5>
<boundromcode6>000000000000</boundromcode6>
<boundromcode7>000000000000</boundromcode7>
<boundromcode8>000000000000</boundromcode8>
<hs1>0 %</hs1>
<aip1>0</aip1>
<aip2>0</aip2>
<aip3>0</aip3>
<aip4>0</aip4>
<aip5>312</aip5>
<aip6>0</aip6>
<aip7>0</aip7>
<aip8>0</aip8>
<urom1>5</urom1>
<urom2>3</urom2>
<urom3>212</urom3>
<urom4>15</urom4>
<tdso>3</tdso>
<counter>232794</counter>
<fcounter>0</fcounter>
<date>09/04/2014</date>
<time>15:01:30</time>
<datetime>09/04/2014 15:01:30</datetime>
<ipaddr>192.168.x.xxx</ipaddr>
<macaddr>00:22:12:02:07:2F</macaddr>
<name>WEBCONTROL </name>
<builddate>Sep 01 2014, 21:11:30</builddate>
</response>


Again
 
The board hangs and then reboots.
 
The PLC programme stops running all code  for about 10 seconds.
Next my PLC code sends a semaphore flag to indicate the first line of code.
Next my PLC programme flashes the green LED in a pattern  I can recognise as a restart.
Sometimes a few lines of code will run and sometimes the process will repeat before any further PLC code is executed.
If I remove the sensor from the long cable and plug it in with a shorter length the code runs fine.
 
Again
The 1wire interface should not hang or cause the PLC code to reboot repeatedly. They should be independent, short of the firmware running away.
 
You can play the semantic card all you want. When the board won't respond and stops running it's code, then it's hung
 
Based on the questions here and other users experiences with the same thing I strongly suspect  the 1wire driver  firmware has serious error handling problems.

 

[CAI_Support]

Larry,
 
We went through our source code, the 1-wire bus and PLC on on scheduler, they assigned time slot and sequences.  It is impossible only run 1-wire and not run PLC code. It is not like PC or MAC that each process are totally separate process.  In WC, there is one process, if CPU does not run this part of code, it will not get to another part of code.  Only WEBSET and email that when there is no RAM, it will skip till RAM is available.  Any other IO activity can not be skipped.
 
If board is rebooting, it must go through bootloader, then start up the scheduler for all the sub systems.

 

[LarrylLix]

In WC, there is one process, if CPU does not run this part of code, it will not get to another part of code.

So then the 1wire communication error problem can never be resolved with this board.
 
In short, if there are more 1wire communication errors than the error recovery process can handle the WC can only reboot to reinitialise all processes, I/O and restart the PLC code.
 
Some of the firmware runaways have deleted my user setups, PLC programme, network setup and notifications.

 

[CAI_Support]

We ran 50ft cat5 cable with same DS2438 sensors on the tip.  We can not duplicate the problem, that was running over 48 hours.
I don't know if we could ask you to send your board, wire, power supply, etc to us, so that we can test it out in our lab for you.
We are committed to help our customers.  But if our engineers can not see the problem, we can only guess, 
From our experience, only external noise or power supply can cause the kind problem you described. But your tests excluded those possibilities.  So we pull our hairs and bang our head against wall could not see what you saw.