Internet PLC Forum

I'm using Tri 6.4.1 on XP pro on this Dell precision M90 laptop.

This is more of a reporting of a percieved bug than a cry for help since I have a workaround. The workaround is never open the text editor to full screen mode and all is well.

Just to summarize, and I have tried this in both version 1.4.2_06 and 1.4.2_19 JRE, scrolling the text window of the function editor while it is in full screen mode causes "javaw.exe" resource usage to go through  the roof per task managers "Processes" monitoring tab on my machine. Also there is an accompanying condition of a painfully slow und seemingly unpredictable scrolling of the text window while this is going on. Once this mode has been entered I haven't found a way back out other than closing out then restarting my tri session.

If I were to guess I'd say it looks like it may be some issue with the directx graphics handling but of course it is only a wild a** guess. It looks to me like all graphics acceeration is disabled in this combination of conditions.

Then again I've seen errors with this machine you all couldn't seem to replicate so maybe this is another flaw of this particular laptop.

Is it possible?

One of the other programmers here left one of our Nanos in some unknown state with an unknown IP address. I'm not really set up to do 485 with my machine right now.

I'm wondering if tere is some simple method of defaulting everything (including IP address) like setting a power up jumper like on a PC or something similar to that.

I am having zero luck at guessing the IP.

Sorry if this is covered. I tried a search with no useful hits on the subject with the terms I searched with.

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.

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!

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.

Indeed. I see it clearly now. Thanks for the insight.

Perhaps, though I didn't know it at the time I first made this thread, my question should have been: What is the proper technique for stripping 32 bit values for storage in a 16 bit location once the 32 bit math is done?

Edit: Wait a minute! Where is my calculation exceeding 2^31-1? My biggest value is 122071 *4096 = 500002816 which is within the limits. Every step from there it just gets smaller with divides or subtractions. Is the divide causing it to go over 2^31-1?

Ah that would be a good way to round. Simple yet effective. Clever, thank you. After I posted I found a similar method to truncate, ie: A =(A/10)*10.

Unfortunately, I think my number must be too big or something as it is exploding when I try these types of things. Even when splitting up into seperate lines and/or variables, it still explodes. I should have mentioned in my first post that this number is an 9 digit 32 bit number.

Even this wont do it (500002816 is just a random example I made up), it still explodes:

A = 500002816
B = A/10
C = A * 10

I did this which is working but sure feels like a hack.

A = 500002816
B$ = STR$(A,9)
C$ = MID$(B$,1,8)
D = VAL(C$)

It's working but there must be a better way??? At this point rounding would be stupendous but a clean method of truncating would be a start.