Trilogi editting problems

[cdenk]

This is Trilogi 6.45 - 05, T100MD Computer is running Windows 8 Pro, with the recommendedd Java

Had been doing considerable editing of a large (113KB) file, changing DM[] to variable names after importing a DM table, and was going well. The file did recently compile, and load to the PLC with no errors and apparently running correctly.

Did a find all of"DM[" to locate last remnants to change, found first of several instances, adjusted the selected string, and started typing a new string. The entire line including cursor disappeared, and numerous empty lines below. Problem seems isolated to one custfun possibly.  Opened file on 2nd computer running XP Pro Sp3 with same results.

Reloaded Trilogi on Windows 8 with no change.  

At the moment I'm assuming the file is damaged, how can I repair it?

[support]

Try to find the backup files which are in the same folder as the last opened .PC6 file. These are named backup001.PC6 to backup004.PC6.

These should contain the most recent editions. You can try to rename them back to a normal file name and you can then edit/compare with the corrupted file.

You can try to send us the file to support@tri-plc.com and let us know which custom function have disappeared lines and we will try to see if we can see the content or do anything to recover the line.

[cdenk]

Thanks for the quick reply. The .002 backup seems OK, but that's loosing a lot of work. The computer does dual boot Ubuntu Linux, would an editor like Gedit open the file, and help in repairing. The problem seems isolated to a few lines.

[cdenk]

A little more info:
Opened file in Firefox, didn't see anything in the problem area that looked strange. Closed without saving.

Apparently it's more a display problem then an editing issue. I can select the item DM[4000], and paste the replacement "ScreenNumOld". Display loses editing line, and numerous blank line appear below after several untouched lines. Hit the "ESC" key, exiting CustFun. Reopen the Custfun, the editing is complete and displayed properly. Trying to edit other instances of the DM[4000] results in the same issue. DM[4000] is the last (or very near) instance of any DM[] that has not been replaced with a label name. But no problem editing anything else in the Custfun. Both DM[4000] and "ScreenNumOld" are in the define table, and the label is accepted, orange color.

Here is troublesome code that appears 8 times in the custfun:

IF ScreenNumOld <> ScreenNumber
ScreenNumOld = ScreenNumber
SETLCD 0,1,CHR$(1)
ENDIF

If I put the cursor at the end of the second line and hit "DEL", the line disappears and  the empty lines below appear. Then if hitting "Enter", every thing goes back to before"Del".

[support]

Try to add a comment character (') at the end of the line and see if it makes a difference.

It may have something to do with the the syntax highlighting algorithm. We need to have a repeatable example to track down the issue.  

[garysdickinson]

cdenk,

I run into the same problems with the iTriLogi editor all of the time.  It doesn't have to be a big or complex program.  It doesn't matter what version of JAVA is used.  I haven't found a way to reproduce the problem, but it is real, and it scares the bejesus out of me.

I see the same issue.  Lines of text vanish, the cursor vanishes.

I have found that once this happens you have to exit and restart iTriLogi.  I have found that if you save the program at the first instant that things go wonky that the saved file is OK and not screwed up.

I have been using a shareware editor, "Notepad++", for big complex edits.  If you export the custom functions, Notepad++ can convert the end of line first to UNIX format and then immediately convert the end of line format to DOS you will have a
"normal" text file.

I cut and paste between the NotePad++ window and the iTriLogi custom file edit window to get the edited text back into the PC6 program.  It's a bit cumbersome, but Notepad++ doesn't crash.

The auto backup versions of the PC6 files are a life saver.

Gary D

[ScarBelly]

I've seen similar problems.  A line of code keeps failing even though it is good.  Retyping on the same line won't fix it but deleting the line and entering a new line with the same instruction fixes it.  As support indicated, apparently line endings get corrupted.

[cdenk]

More experience:~(
Was able to type in new half dozen lines in new inserted lines above problem lines, then delete the problem lines, and then copy paste with minor editing (changing index numbers) for the 7 more instances of the lines. The file is usable, but still editing problems that need to fix for future.

Started with a new file, added a ladder rung with 1 relay contact and 1 Custfun. The Custfun is only a one character comment, a 1 line "=" statement, followed by another one character comment. The 2 arguments of the "=" are entered into the define table. It does compile, but try to edit the "=" line, it disappears, add or delete a line above, and it's back with the editing just done. I did open the file with a hex editor (http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm#download), and didn't find anything weird. Most items are separated with 00h, and 00A end of line where should be.  Did a little experimenting, could be my label names are too long, but there are many others that similar lengths. My previous posts looking for variable name criteria haven't yielded any good results.

See attached Zip file, it's all of 444 bytes

[support]

Thank you for posting the file. We have sent the file to the software development team to check into what caused the problem and fix it for future release.

We tried to make some edit at the line and the line did disappear. However, after closing the editor and re-opening the same custom function, the edited content re-appeared and it didn't lose any characters. So it is a display related issue.

We added a white space, or a comment character (single quote ' ) at the end of the line and the line now can be edited at will without disappearing.

'X
ScreenNumOld =  ScreenNumber  '
'Z

You may like to try that and see if it will temporarily resolve the issue.

[cdenk]

Thanks for the quick reply, slowly the picture is evolving. One big question at this time, are my label names too long?? What is allowable length and characters. I have replaced many, there are near 80 DM[]'s in the program, and the majority have now names. Before I go further, need to know to not waste time.

The comment at the end of the line is very interesting. The DM[4000] only appears in one Custfun, but numerous times. I could send the entire Custfun if would help, or even the whole program. This application was started 7 or so years ago, and has occasional additions and modifications over the years. It's just recently that I have worked at cleaning up the code and changing mainly DM[]'s to names for readability. There are many contact and Custfun names with underlines in them. Hasn't been a problem yet, but something to keep in mind with future revisions.

[support]

Software side track down the issue is caused by the very last character of the label (whether it is I/O label or #define name) ended with a 'r' or 'R' - the program tried to check if it could be a "REM" or "rem" (comments) but since the char array formed from the line ended at 'r', the next character did not exist and that caused an index out-of-range exception, which cause the repainting of the editor to stop ( and hence display blank lines from that point onward).

By adding a white space or a single quote after the last character it prevented the exception.

Software team is still checking if there are other instances that could cause the same exception. This problem should be fixed in the next release of i-TRiLOGI but for now for those label name that ends with an 'r' or 'R' you can either rename them, or on lines that use them you can add a white space or single quote after the last 'r' character so that you can edit the lines easily.

Do let us know if you discover other label name that can cause the same problem. You can post it here or write to support@tri-plc.com

Regarding labelname size, for I/O labels the limit is 16 characters. For #define name there isn't an imposed limit but it probably make sense not to make them too long.
 

[cdenk]

Good work! I had only 2 Label names that ended in "R", and only one of those was at the end of an active line, but numerous times. Adding the " " to the end of the line cured the situation. The other variable never was at the end of an active line, but "r" did occur numerous times at the end of comment lines and were not an issue.

There are numerous contact (input, relay, etc.) names ending in "R" (and including "r") that have not been a problem.

The 16 character limit is OK, I had only 1 name that was 16 characters, all the others were less.

I do still have numerous contact and label names that do have an underscore "_" not at first or last position that have not been a problem, is there any reason to remove the "_" from those instances? It would be nice if a few other characters were allowable.

[support]

The I/O label editor converts any non alphabet or numeric characters to '_'.  It should be ok to use '_' character for your label or #define name.

You are probably aware that for variables A to Z, A$ to Z$ and DM[n], you can tag a '_" character and append a descriptive comments to the variable. However, the syntax highlighting for these variable names will be lost with the '_' appendix. That may be the reason why some users did not like the '_' being added. But if '_' is used on i/o label and #define label the syntax highlighting  appear to still work.

[cdenk]

Understand, probably should have clarified, I do not have the "_" in 1st, 2nd, or last positions.

Thanks again.

[support]

i-TRiLOGI version 6.45 build 06 has been released. This should fix the editor issue as well as the issue of export of custom function and use of timer/counter labels suggested in these forum threads:

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

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