PLC editor hangs

My PLC programme editor errors out when "Sending" about every 5-10 edits and I have to reload the PLC Program page before that or the "Send" button reports an error. If I reload the PLC Program page before that I am good for about 5-10 more edits without trouble. This can be going to another page and back or just clicking the PLC Program page before doing more editing.
 
If I get errored out  I select all the programme code, copy, click the PLC Program page to reload and then paste the clipboard back in so I don't lose any of my  latest edits. Good for another 5-10 edits.
 
I am running IE 11 (Win 7 x32) and Java 8 u5.
 
Anybody else experiencing this?

PLC editor is running completely in the browser environment.  In the past, we have heard Firefox browser had certain "security" feature that caused loaded Java code not executable.  But we never heard IE browser has this problem before.
 
We are running IE 11 on 64 bit windows 7 and latest java here. We do not seem having any problem.  It might be some security setting in the browser that mistakenly blocked certain Java function.  If you could identify what was the cause, please do post here to let us know.

I'm having similar issue with Webcontrol32. When opening PLC editor it takes over a minute and come up with a script error with IE. If I select "No" to continue then the editor opens up.

When browser open the PLC window, it loads javacode and PLC program from the WC board. The browser has built-in security sometimes restrict certain byte order to load up, for it consider matching certain security rules.  If you add WC PLC screen to your browser's safe site, it may not perform such checking, then it would not have problem.
 
This is not board or firmware problem. All the javacode and data bytes are valid code and data, it is browser security too strict on this page.

yeah I have also problems with that 3.17d version at the WC8... seems CAI is pushing responsibility to the browsers...

When it hangs, you can enable browser debugger to see where it hangs.
 
When you click on the PLC, WebControl board does nothing other than sending the PLC program back to the browser.  Then it is up to browser to allow the javecode in that data stream to display the PLC code or not. If the browser has strict security, it could prevent javacode to extract the data stream and blocking javecode from execution.  Then user will see it hands. We don't have control of browser security, so that when it does not allow the perfect legitimate Javacode to run, you can enable browser debugger to see where it hangs.
 
A lot of time, simple make the WC PLC screen to be your safe site will not run into this problem, before added to safe site, you can check through debugger to see anything harmful to your computer.  We are very sure that we did not do anything wrong on our javacode, there is no secret to find out what being sent back and forth between WC board and browser.
 
If that makes anyone feels good to blast on us, go ahead. 

I don't think anybody is blasting CAI. I see that comment from Efried as CAI putting the blame on the browser running Java. I don't think he is disagreeing with your comments regarding board integrity.
 
As a user of an ISY994i, every time they upgrade their firmware version (about once per month) the Java install needs upgrading as it would act poorly if they didn't match. As well the Java cache had to be dumped each time. I blame this on the Java UI being too transient. People with ISY994i boxes mostly want Java gone (as was happening until a year ago) and UDI (ISY OEM) id working on going to HTML5.
 
Let's face it Java is flakey and finicky and very version specific. I run Java 8 on Win 7 x32 & x64.
 
Having said that my hang problem may be my PS. I have also found my CAI WC board rebooting randomly and frequently. In a few days when a new PS arrives I will report results on this.
 
Tell us more on the debugging process!

On IE browser, you can simply press F12 to bring up debugger window. But I don't want to get into details on how to debug.  In Firefox, I believe you may have to download an extension to debug. 
 
Anytime if your browser entered into debug mode, it will display every code it is running.  You don't have secret about it.  Java expert like az1324 could point out to us what to enhance by looking those code.
 
Unfortunately, if not using Java, then we have to write many different user terminal software, that will be unacceptable to many more users.  Imagine so many different user programs to maintain for different OS, that is worse nightmare.
 
I think Larry's board's problem could be electrical noise, or 1-wire bus timing little off.  1-wire timing is adjustable in General tab. In the later release, we have changed 1-wire timing to make it working in wider timing range.  However, please note the TDSO value in general tab needs to be set to 3 after firmware update, or your 1-wire sensor may not work.

CAI_Support said:

When it hangs, you can enable browser debugger to see where it hangs.

Click to expand...

 Sorry if it is not the board to blame, why V3.17d does not stall that often when uploading PLC compared to V3.17g? May be its a combination of old boards and new firmware?

Are you talking about board stall, or are you talking about browser stall?  They are two different things.
For browser stall, that is security in browser halt the JavaScript from execution.
For board stall, that could be a lot of reasons. 
We would recommend to update to the latest firmware, because a lot of board problem is due to noise on 1-wire bus or noise on power line.
Latest 3.02.18a-b firmware has changed some 1-wire timing, that can help wider timing range for sensor to respond.  Just make sure the default TDSO is 3 with the newer firmware.

I was talking about the stall of the upload as indicated in the title of the post. Both board and browser are involved in the process which you can't deny.
My problem is the complicated firmware process getting back to a productive operation, and the hidden update files. But I will update ASAP having now all the info, thanks.
I think the focus of the development should be less on adding low level functions and more on usability (software, system documentation and sensor and actor modules).

It is not hard to separate which side having problem.  simple change to another computer and/or browser, if that problem is reproducible, that is board problem. If that problem only happens on certain browser on that particular computer, then it is that browser problem.  So far, out of few thousands boards out there, less than 5 people ever told us experienced stall problem, and we have not found one board that stall on all browsers,
 
On the early days, we heard the Firefox had strict security setting by default, caused browser not able to display the PLC screen. Once they changed to IE browser, that situation is gone.  Recent couple users told us they had issue with IE browser after update to latest IE.  We believe IE strengthened its security level lately.  If you family with browser security, you can actually adjust the Java execution limit to allow the java code to run.  It is a simple fact that WC boards require Java execute permission. If your browser restricts Java execution, it will not work. 

"I think Larry's board's problem could be electrical noise, or 1-wire bus timing little off. 1-wire timing is adjustable in General tab. In the later release, we have changed 1-wire timing to make it working in wider timing range. However, please note the TDSO value in general tab needs to be set to 3 after firmware update, or your 1-wire sensor may not work."

You may have something there. Originally I found sensors not functioning properly at times so I experimented with the TDSO setting. I found they seemed reliable at about 15 usec and below so I had them set to 12 to be safe. I misunderstood what this setting was for.
 
After your comment I Investigated and experimented more. Setting the TDSO at 3usec they still worked fine. Right now I have the setting at 2usec and have noticed something strange, prompted by your comments. I have noticed  the CAI WC board has stopped rebooting at random intervals!
 
I have reinstated and tightened my ISY box to monitor at less than 1.5 times the loop interval on the WC. I have a update loop sending the clock time to my ISY board, along with weather data every five seconds. My ISY home automation system has a timer of 7 seconds in it that sends me an SMS text message. If the time gets transmitted from the CAI WC faithfully every five seconds then the timer gets cancelled before the WAIT 7 seconds instruction times out and I never get a text message telling me the "CAI Heartbeat Failed" . This hasn't happened for most of the day now. A few per hour was the previous "normal"
 
This does bring up some interesting queried though.
- Is this 1-wire interface  bit-banger style input all done in software? That would be  disappointing,
- This prerequisite for exact setting needs to be emphasised somewhere. This board may have been scrapped due to this.
- Can this setting not be somewhat self-adjusting or at least pre-set in the cold start firmware? If the pre-set is changed by the user then leave it alone???
- Mention of wire length factors need to in the manual.
- Why on earth would a bad timing setting on  interface software cause a board to reboot or hang?
 
I have not experimented with PLC code update write hang to see it this fixes that problem as well.
 
Thanks for the clues!

LarrylLix said:

- Is this 1-wire interface  bit-banger style input all done in software? That would be  disappointing,

Click to expand...

Correct, WC8 is bit-banged, the WC32 has a hardware 1-wire controller.
 
The bit-banged 1-wire interface also appears to be why WC8 is suceptable to extranious noise (lightning or powerline). My systems have been pretty stable but both the Wood heat and Greenhouse controller will ocassionally (once a year or so) hang during nearby lightning events. I had to move a dehumidifier to a different circuit because it was crashing the wood heat controller. Interesting that in most cases the web server is still running but other functions have crashed.
 
Have not played around with 1-wire timing. The defaults seem to work fine for me on fairly long buss, 100 feet or so. In my hardware I used diode clamps to Vcc and Ground in an effort to protect the WC from transients.
 
There was a post here a while ago that a user installed external ESD supression devices for an industral automation controller and that seemed to cure the problmem.
 
/tom

in an attempt to stop the who is to blame debate- my solution to the PLC upload stall was to open the system status of the WC page first- afterwards it restarted working...