Strange numbers and symbols in wc8 gui, partial reboot?

[CAI_Support]

Tim,
 
You probably running an older version firmware. Please try the latest 18B3 firmware.  It should work well for you.
 
Thanks.

 

[TJF1960]

Although I haven't seen the weird graphic displays any longer I am still having trouble with random reboots. I am positive it has to do with either the different lengths of cable for each temp sensor or noise. I have isolated the wiring so I don't believe it is noise.
 
Question. If I go into the temp sensor setup in the gui and select 000000000 for each temp sensor then reboot they all specify unbound. If there is a problem with the different lengths of cable causing the rebooting will doing this step stop it from happening? or do I have to physically disconnect all the sensors?
 
Thanks,
Tim

 

[CAI_Support]

Hi Tim,
 
Which version firmware this board running?   What is the TDSO value in general tab?

 

[TJF1960]

Yes.

 

[CAI_Support]

Hi Tim,
 
Is that 3.02.18B3 or 3.02.18B4 firmware running on the board? 

 

[TJF1960]

Hi, Sorry...
 
3.02.18B4 and TDSO I have set at 8 which was giving me less temp sensor errors than 3-7 setting was.

 

[LarrylLix]

Question. If I go into the temp sensor setup in the gui and select 000000000 for each temp sensor then reboot they all specify unbound. If there is a problem with the different lengths of cable causing the rebooting will doing this step stop it from happening? or do I have to physically disconnect all the sensors?

Thanks,
Tim


Putting 0000000000 in the sensor setup stops the firmware from polling the sensors. As long as 1Wire sensor polling is happening and there are errors happening repeatedly the WC8 reboots occasionally. This seems to be associated with the WEBSET command sharing memory with the 1Wire bit-banger driver. A successful solution has never been worked out.
 
The only thing I have found, as a workaround, is not to have any initialisation code that will upset sensor results (since rebooting is going to happen) and/or not have any downstream functions that depend on the WC8 sensors (monitoring and observational interest only).
 
Many have reported to just avoid bit-banger 1Wire interfaces. It seems none of the manufacturers of boards using this technique can make it work reliably. Manufacturers using a hardware interface are reported by many users as completely reliable without these constant problems. Eg. Raspberry Pi with RPI2, and possibly WC32. There are a few others.
 
Have you tried putting 5-10K termination resistors at every sensor and the WC8 board? Some report better success with lowering the impedance of the transmission line thus avoiding some of the ringing and noise on the signals.

 

[CAI_Support]

Tim,
 
When WC board powering up, it will initialize the 1 wire bus by pulling every possible device on the bus.  At that time, it will build an internal table for detected device.  Another time doing that is when save network configuration or issue sreboot command in PLC.
 
When user assigned 1-wire devices with temp sensor number, another table is filled with device ID in the assigned sensor slot.
 
From 3.02.18B3, we have changed 1-wire logic to read multiple times from sensor, similar to Dallas hardware 1-wire controller. 
 
It is possible the watchdog timer marginal, so that when reading from 1-wire bus taking longer time, it triggered watchdog timer to think the CPU locked up thus reboot itself.   Maybe we could generate a special version for you to try with longer watchdog timer value. Could you please confirm if changed TDSO to 3 then got more errors from sensors but not rebooting? 
 
Also, how many temp sensors do you have on the bus?  We want to analyze the timing to see where could be the logic caused watchdog timer time out.

 

[TJF1960]

I have 8 sensors on one board. The length of wire (cat5) does vary from 1 inch to 25 feet. I ran it all long before I read that it should be the same lengths.

TDSO is set to 8 which gave me less sensor trouble emails from the Plc code I added to monitor sensor status.

I am willing to try different fir,ware if you like.

Thanks, Tim

 

[CAI_Support]

We will make a special firmware for you to try in next day or so. 
We think that might have something to do with all those tasks and devices made slightly longer time to reset watchdog timer.

 

[TJF1960]

Larry brought up some good things I should probably mention. The board does webset a lot to my ISY. Sometimes as much as every 2 seconds other times every 15 seconds or so.
I have tried the termination resistors in the past but didn't seem to change anything.

I will be happy to try any new firmware.

Thanks again,
Tim

 

[CAI_Support]

Tim,
 
Please try this firmware at:
http://www.cainetworks.com/support/download/wc8plc030218b5-update.zip
You only need to update the base firmware, no need to update gui, since there is no change in gui.
Please let us know if this helps.,
 
Thanks for letting us know your feedback.

 

[LarrylLix]

Installed and running for about 16 hours now and this is the count report generated by my ISY from a 6 seconds heartbeat cycle on the WC8.
 
000010117
 
The count figure is a combined count of four figures using two digits each 00,00,01,01,17
 
1,000,000 counts = PLC codes restarts = 00
  10,000 counts = number of  WEBSET heartbeats not received for more than 21 seconds = 01
    100 counts = number of WEBSET heartbeats not received for more than 15 seconds = 01
      1 counts = number of heartbeats not received for more than 9 seconds = 17
 
Keep in mind that the least significant digit counts include the longer gap counts so that the ones missing for longer than 9 seconds (=17)  also include 1 longer than 15 seconds and 1 longer than 21 seconds.
 
This looks promising that initialisation PLC code can be used again without having it run randomly. Missing updates randomly can be dealt with and could be due to some Ethernet congestion or blockade. Without the clear reception of a semaphore indicating an event it is hard to pin the problem on any particular device. For non-real-time reporting this should not present any problem I can see. Temperature/humidity changes not updated for even 60 seconds should not be a big deal.
 
I am not aware of, but have not closely monitored, any out-of-range values being transmitted. That would indicate the PLC code timing was pausing also while my hardware input counter continued for my anemometer pulse input. If the PLC code paused for 21 seconds I should have integrated an extremely high wind speed and I should have received a text message telling me we are experiencing a hurricane. With the privisos; the hardware counter wasn't reset in the process, and we were experiencing enough wind to accumulate that high of a pulse count in three integration periods.  I doubt this is happening (PLC code hiccup gap) but I can set up a monitor on my ISY to watch for radical changes in values.
 
This looks promising.

 

[TJF1960]

CAI_Support,
 
I installed the firmware last night in 2 WC8 that have been giving me trouble. The WC8 that has 8 temp sensors has been running fine and TDSO is still set for 8.
The WC8 that has 2 temp sensors (one mounted on the temp sensor connector and 1 on 6 feet of cat5) rebooted 30 minutes after installation. The TDSO was set for 2. I changed it to 3 and has run all night long.
 
It may take 2-3 weeks before I can have an answer as to whether this firmware update is better or not for my installation.
 
Thanks very much for the effort.
 
Larry,
I am hopeful your results continue to be promising. Thanks for your help as well!
 
Tim

 

[CAI_Support]

Tim, Larry,
 
Thanks for the testing report.  What changed was that watchdog timer now will reboot if TCP connection can not be established after 4 seconds.
Due to TCP/IP collision recovery protocol, if WC sent connection request but did not receive reply, TCP will re-try, in lower level double its time at every failure.
If the is no congestion or collision, TCP connection will be connected instantly, thus no wait time.  However, if there is a congestion or collision in lower level, it will automatically retry.  By increasing watchdog timer value, it will allow TCP lower layer to stuck for longer time.
 
In the 18b4 firmware, the timeout value was long enough to connect to any server on the world.  We have tested the connection from here in California to Ross' server in Australia without any problem.  By increasing watchdog timer value, it reduced the reboot, that indicates either some congestion in your network, or the server on the receiving end is slow to respond.  We can make the timeout value even longer, so that it will not reboot at all.  But network congestion will slow down other process, like Larry indicated, some realtime processing will not be able to process, or in more rough time chunks.