Archives > Archived FAQs

Program download stopped halfway

(1/3) > >>

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.

Navigation

[0] Message Index

[#] Next page