PLC editor hangs

Efried,  If you have several boards with different firmware, your browser could cache a copy of different Java script and feed back to board from cache.  That can cause problem, too.  Just hit referesh on the browser, that will force browser to read from board all the contents and java program again.  That will fix the problem for you.
 
Larry, Tom, We calibrated our timing with Maxium's hardware 1-wire controller, so that whatever their chip does, our code does too. However, in 1-wire device, it could have its respond as short as 1uS, or as long as 15uS, in a total time 60-120uS range.  If not captured, it will cause our logic received a checksum failure.
 
In our 3.0218b (or 3.02.18a02) code, we increase capture logic many times more to make sure that even slave devices not consistent, we could still capture its response.  If you updated to that version firmware, set TDSO to 3uS, that is probably okay for most situations.  Increase the value only when sensor is  far from WC8 board  on the bus.
 
CAI_Support said:
 We calibrated our timing with Maxium's hardware 1-wire controller, so that whatever their chip does, our code does too.
I don't think there is a functional problem with your firmware implementation. As I've posted even with a "long" 1-wire bus the WC default timing works fine. What I think is going on is if there is a nonstandard 1-wire response caused by noise at a critical time the WC FW code crashes or hangs.
 
I'm using earlier software 3.02.17b and .17d that does not support the spiffy new boot loader so can't play around with later versions of the code.
 
/tom
 
Tom,  sorry for hearing your boards does not have bootloader.  Maybe some point you could send it in for update.  All current shipping boards are with bootloader. 
 
I really believe the newer firmware do better than previous, because sensors are located at different distance from WC board, and that will reach to the CPU at different time.  Theoretically, if sensors on 1-wire bus did not respond (or lost response somehow due to noise or timing), it should only mark that sensor as failed.  However, in reality, it might have different result.  There are some 1-wire bus analyzer out there that can capture all 1-wire signals and analyze them, like USBee made bus analyzer, could help find the problem.
 
Timing wise, I would change the TSDO timing to different values on both extreme where WC8 is barely able to recognize all the sensors, then pick a value in the middle.
 
CAI_Support said:
Timing wise, I would change the TSDO timing to different values on both extreme where WC8 is barely able to recognize all the sensors, then pick a value in the middle.
The good news is .17x FW has the ability to adjust 1-wire timing, forget which version added that feature I randomly selected a few values around the default when I first placed them into service but have never swept through the entire timing range to find the sweet spot. I'll add that to my to-do list.
 
/tom
 
Ok I have done some experimentation on two other computers now to investigate this problem further and it hangs on each one. Each computer is running a different windows version.
 
Win 7 x32 IE 11 with Java 8 via Wi-Fi -> router -> CAI WC
Win 7 x64 IE 11 with Java 8 CAT6 --> router hub -> CAI WC
Win XP IE 9 with  Java 7 -> switch ->hub -> CAI WC
 
After editing the PLC code by hand typing edits several times the code upload always errors out.
 
I have tried cutting and pasting the whole PLC code, moving pieces of code back and forth inside the programme, and saving the code out to the WC over a dozen times for each trial method, each without errors. It seems that deleting lines and hand typing them, or typing new lines creates the scenario where the saving process comes back with an error message.
 
This only happens after multiple edits  without reloading from the WC board each time.
If the PLC code is reloaded after each 3-4 edits no error is ever incurred.
When an  error during saving is incurred copying all the code, reloading the code by clicking on PLC Program, and then pasting the code into the editor again always makes saving the code successful  until after  several more edits.
 
This appears to be a Java code problem in the  that somehow interferes with the saving process. Perhaps some extraneous characters get inserted somehow.
 
 
As far as the random PLC rebooting problem, by setting the TDSO setting down to 1usec (my lead length is only on my desk with 1-2m cables each) I can reduce the rebooting frequency down to a few occurrences per day instead of one reboot per every 2-30 minutes I had with longer TDSO times.
 
If your PLC code gave error, please let us know what kind of error. There are possible real PLC syntax error, not the browser error.  Sometimes during editing, it is possible to have non-display character being paste into, or missing linefeed/new line character.
Microsoft word and some editor could introduce some formatting character that is not visible to human eyes.
 
If you have multiple boards with different version firmware, please make sure always refresh the browser when login into each different board.
 
Back
Top