Program download stopped halfway

[K.Newton]

Important Notes from Moderator

We recently received several reports that program transfer is often aborted half-way or require multiple attempts to transfer program to the PLC. This happens whether the program transfer is via TLServer or the Ethernet.

It appears these problems only surface after user has upgraded to JRE 1.6.0 (especially 1.6.0_24).  So far in all cases the problem was resolved after the users uninstalled JRE 1.6.0 and re-install JRE 1.4.2.  Therefore we strongly recommend that you keep your JRE 1.4.2 even if you must upgrade to JRE 1.6.0.

The following posts discussed the problem and the solutions.

************************************************************************
[Question posted by K.Newton]


I am often experiencing apparent lockups or stalls while downloading code to the PLC through the ethernet port via Tri 6.4 ctrl+T.

Quite often it will stall part way through the download sequence and the only option seems to be an abort followed by a retry. No amount of waiting seems to allow these stalled conditions to clear themselves and so the abort option is the only thing I've found to pull the system out of this "stalled" state. Quite often I will get several instances of this happening before I can finally download to the entire set of code to completion.

I am wondering what I am doing wrong or what I can try to improve reliability of downloading the software to the PLC. It is taking up quite a bit of my time just trying to get my various code versions to "stick" and I'd rather be writing code.

[support]

Do you experience problem with program transfer only? Do you experience frequent drop out in communication when performing online monitoring? We never experience problem transferring program to the PLC via Ethernet in our own tests. And we can leave online monitoring connected to the PLC for days without dropping out. In fact we routinely transfer test program larger than 10K words without any issues.

Some other customers did experience similar problem as you described when running under Windows 7 with JRE 1.6, we suggested trying the earlier version of Java (JRE 1.4.2) as we suspect it may have something to do with the interaction between the O/S, Java JRE or TriLOGI version or even a particular PC brand.

Since you mentioned 6.4 you already have the (currently) latest version of iTRiLOGI . So what version of Java JRE are you using and what O/S version?  What PC brand and model?

Note: In our own setup we have Windows XP, vista, Windows 7 running different version of JRE and they all work fine, but apparently W7 is giving more trouble to some users than the plain old XP. Do you have a different laptop running Windows XP with older JRE 1.4.2 that you can try? If you are running Windows 7 professional you can try to launch the virtual Windows XP from W7 and configure the virtual XP to run older JRE 1.4.2 and you may have different experience.

[K.Newton]

I have only noticed it during during program transfers. Online monitoring has appeared to be flawless to my eyes.

I am running JRE 1.6.0_22. I'm on XP 2003 sp3. It's a DEll Precision M90 laptop wth Intel core 2 @2GHz and 3.25GB of RAM.

I don't have another laptop I can use but could potentially roll back to JRE 1.4.2 if that is easy to accomplish. Also, it seems there is another JRE update waiting for me this morning and so I might try that first.

[K.Newton]

Well there it is. I tried the latest JRE with similar non joyous results.

I uninstalled all JRE's then reinstalled the one that came on the CD that came with my kit. Perfect!

One more data point for your programmers where 1.4.2 is the solution.

Thanks!

[support]

Thank you for sharing your experience. We are glad that JRE 1.4.2 solves your problem. The computer that I am testing is also a Windows XP SP3 and I am running JRE 1.6.0_24-b07 but never had any problem transferring program to the PLC. So again this is inexplicable - maybe it has to do with how the JRE interacts with the Wi-Fi or Ethernet driver on your PC? Somehow JRE 1.6 seems to introduce some problems that were never there in JRE 1.4.2.  The reason I am running JRE 1.6.0 on my PC is because we wanted to see if we would encounter any new or reported problems using the latest JRE 1.6.0. Unfortunately we couldn't replicate the problems and therefore could not address them.

Note:
If you need to install JRE 1.6 (because other applications need it) but want to continue to run i-TRiLOGI on JRE 1.4.2, you can refer to the following thread:

http://www.tri-plc.com/yabbse/index.php?board=2;action=display;threadid=1459

We explain how you can keep both JRE version on the same computer but only run the i-TRiLOGI using JRE 1.4.2.

[K.Newton]

You're welcome.

After playing with this for a couple days I have another question.

The version on the disk V1.4.2_06 (build bo3) is crashing on me occasionally taking out i-Trilogi in the process. Not a huge deal since it's fairly rare. However, it is concerning and I'd rather avoid the situation.

I've noted that Sun had later versions of 1.4.2 all the way up to _19. Is 1.4.2_19 a more stable than version 1.4.2_06? If so, do you know if I could upgrade to 1.4.2_19 and still maintain the benefits of the smooth downloading 1.4.2_06 has allowed for me?

[support]

We are not aware the 1.4.2_06 crash often. i-TRiLOGI may hang if you unplug the serial adapter or Ethernet connection while active comm is going on. Other than that 1.4.6_06 has been pretty stable for us. We have also tried JRE 1.4.2_19 (very last revision of 1.4.2 ) and have no trouble with it, but we don't know if it is more "stable" than JRE 1.4.2_06 if the reason for its crash is due to something else (conflict with some O/S software?)

[K.Newton]

Whatever the crash is, it's a situation which causes an error/crash report popup request which is asking to send a report to microsoft for analysis. When I direct the error report popup sequence to go ahead and contact microsoft about the problem, microsofts site comes back with the suggested resolution being a link which leads to Suns download site for the newest version of JRE.

If you want it, and if you can tell me how, I could possibly get the error report for you.

I'll try 1.4.2_19 tomorrow and see what happens.

[M.Wysong]

I've also had this issue on my Hp laptop running XP SP3. I thought it was because of the 485 so I switched to ethernet. The problem continued. I've also tried switching off my wireless and it did not make a difference. I will have to see what jre I am running and try the other one out to see if it fixes my problem. Online monitoring is unaffected. It sounds like I am having the same exact problem though.

[K.Newton]

In case this is of use to others who read this....

It's been a few days now nd I've been pounding on 1.4.2_11 without it crashing yet. For me the _11 fixed the stability issue and is allowing for 100% download reliability so far. I seem to have found the plc programming nirvana state for this laptop.

Edit: I accidentaly said 1.4.2_11 and meant 1.4.2_19. 1.4.2_19 is the one that fixed my problems. Sorry about that!

[M.Wysong]

I downgraded to 1.4.2 and so far downloading has been much easier. Thanks!

[support]

We have just released i-TRiLOGI 6.41 with TLServer 3.16. Besides adding some new features to the programming editor, we have also addressed the issue that JRE 1.4.2_19 appears to work better with i-TRiLOGI.

What we do is to encourage the user to install the JRE 1.4.2_19 regardless of any other JRE version that is already on the PC. We have developed the TL6launcher.exe program such that it will check for the existence of the JRE 1.4.2_19 in either the C:\Program Files\Java folder or the "C:\Program Files (x86)\Java" folder (used by W7 64-bit version).

If JRE 1.4.2_19 is found the TL6Launcher.exe program will automatically invoke it to run the TL64.jar java program. However, if JRE 1.4.2_19 is not found then it will invoke whatever default JRE in the user PC to run i-TRiLOGI.

With this scheme, the user is free to install any other JRE versions needed to run other Java programs but i-TRiLOGI will ignore them and continue to use only the JRE 1.4.2_19.