I have tested these boards with many different temp sensor cable configurations at my desk, with no resistors and no capacitors and they work great with very long cable lengths. However when I bring the same length cable with everything else identical into the environment I had intended it for, the sensors will not be found. These boards are great, and the community here is also an invaluable asset to using them. There are plenty of very expensive boards out there that give you what you are paying for, support. IMHO these are intended for the installer that has barely been able to get dressed in the morning, let alone troubleshoot why their sensors aren't working. If you want extensive documentation and that 'big corporate' feeling of security, go ahead and pay for it. The rest of us will continue to be content with the exchange we can freely be involved in here, or on community forums elsewhere.rossw said:
PLC code lost
- Thread starter nbright
- Start date
CAI_Support
Senior Member
What version of firmware did you run when PLC code lost? We always suggest to first update the firmware to the latest, since it has a lot of improvement in performance, reliability, and feature sets.
In last few versions of firmware, 1-wire bus timing has changed to have much bigger tolerance. That reason alone is worthy updating the board firmware.
In last few versions of firmware, 1-wire bus timing has changed to have much bigger tolerance. That reason alone is worthy updating the board firmware.
CAI_Support
Senior Member
Thanks for letting us know you have update your firmware. Please keep us posted on your result after firmware update.
Efried
Active Member
CAI_Support said:
what is the succus of the whole thread? one sensor per board reduced problems, but long term stability could not achieved. I think we should have some metrics for 24/7 operation, what is the MTBF? I personally do not understand the connection between 1-wire problems andpLC erasure. Only Cai may tell. my experience shows that boards with different update history behave differently, also the more sensors, the more sensor failures. The new reset function will greatly contribute to solving the problem. and others too, if one receiving WC blocks the sending master WC...
CAI_Support
Senior Member
Older firmware had bug that has fixed in later firmware, so that update firmware will make problem solved. That is why we always encourage customers to get latest firmware, so that user can have both new feature as well as fixes for any previous bug, That has nothing to do with MTBF. We don't think reset fixed problem, it merely worked around problem. We believe out latest firmware is bug free now.
CAI_Support
Senior Member
If that lost again, it could be EEPROM worn out. If you know how to replace chip, that is the 8 pin chip next to the network socket.
Is the PLC code lost, but all other configuration not lost, correct? That is a rare case.
Is the PLC code lost, but all other configuration not lost, correct? That is a rare case.
I really have never had these boards functioning in my environment so that they have been reliable. For mission critical applications I am beginning to think I need something better. Although a bit more pricey, I have some experience with Ubiquiti mFi line of products and for a little more cash I can have something almost bulletproof that has been proven and is meant for machine control networks. Sure they need to have a controller running on a server locally, but I would be doing that anyways for my OpenRemote controller.CAI_Support said:
Anybody interested in buying 8 wc8's I could sell temp sensors and some humidity sensors as well? I have found I no longer have much time to try to maybe one day possibly get this stuff to function as I once thought it easily could.
PS the community support is great though!
Efried
Active Member
nbright said:
that is a very sad story. Either You got a bunch of defective boards or there is systematic error. Did you test, with and without sensors, and different power supplies? What is the failure rate in the share of boards?
Regarding the ubiquity system, I can't see an open ecotope of interfaces, hardware and software wise.
I think cainetworks has some time left improving their offer, because the business models are so different.
CAI_Support
Senior Member
We offered to you send the board back for us to test for you. In the past, we have saw people complained problem and turned out power supply problem. Without seeing those boards and seeing what you are doing, any conclusion would just guess. If you have really not used them and just power on then lost PLC code, it is likely the power supply is marginal, so that in certain brown out voltage board reset itself.
But without seeing board, nothing can be concluded.
But without seeing board, nothing can be concluded.
Efried
Active Member
Now I had the same experience, but it was my fault.
Having had a voltage of 2-12 V with the WC32, caused by a capacitor test, trying to reduce analog input measurements by stabilising the power source, the code and network settings were erased, but not the notification, email, and textvariable settings.
After this I tried to update the WC32, but failed because of windows blocking to copy the mpfs21.exe and also some problems with the rar file....
In total, that is very frustrating. I really wish:
that 192.168.0 is used instead of 192.168.1 as default IP
the update procedure happens with a mouse click conveniently.
thanks
PS: the AD converter could be a better one for a 100 USD board, and we need some averaging function, because running averages do not work with integer math!
Having had a voltage of 2-12 V with the WC32, caused by a capacitor test, trying to reduce analog input measurements by stabilising the power source, the code and network settings were erased, but not the notification, email, and textvariable settings.
After this I tried to update the WC32, but failed because of windows blocking to copy the mpfs21.exe and also some problems with the rar file....
In total, that is very frustrating. I really wish:
that 192.168.0 is used instead of 192.168.1 as default IP
the update procedure happens with a mouse click conveniently.
thanks
PS: the AD converter could be a better one for a 100 USD board, and we need some averaging function, because running averages do not work with integer math!
Efried said:
In what material way is 192.168.0.0/24 any different to 192.168.1.0/24 (or 10.10.10.0/24) ??
Efried said:
Define "better".
I agree, 14, 16, 18 bit would be "better". Heck, I'd love 22 bit inputs.
But none of the processor chips that have all the other features needed have 22 bit sigma-delta ADCs. (not that I've seen, anyway)
For "most people" and "most uses", 10-bit seems to be "adequate". Heck, lots of people are happy with 8-bit conversions.
What are you doing that needs a "better" ADC? (oversampling a 10-bit ADC into a 32-bit register leaves plenty of scope for averaging even without floating point math)
