Variable name limitations

[cdenk]

Using the new # Define table, and can't find the limitations on variable names, number of characters, special characters, etc. I'm sure it's in the manuals somewhere, but just haven't been able to put my eyes on it. In the examples, I see 11 characters, and have a problem of not finding a name that has been good, but there is in the table a couple of names with "/" and "@" that probably I have to eliminate.

If someone can point me in the right direction, that would be appreciated.

[garysdickinson]

Cdenk,

TriLog hasn't documented the "rules" on the #define mechanism.

I've been using #define a lot. These are my recommendations:

Characters set to use: a..z and 0..1.  Upper and lower case characters can be used, but the iTrilogi software consider "ABCD" and "abcd" as the same symbol.

Character set to avoid: everything else.  Don't use the dash, "_" as this character really screws up Trilog's syntax highlighter.  They used the "_" character for the stupid "variable comment" idea.  In fact don't use a "_" for naming RELAYS, TIMERS and the alike because of the messy implementation of the "variable comment stuff.

I have not tested the maximum length a #Define symbol can be before it breaks their software, but I have used symbols as long as 16 characters.

You can use the #define to define a new symbol from symbols that were previously defined.  As an example:

#   Label Name          Variable
1  FifoBase                 100
2   FifoSize                 10
3  LastEntry                FifoBase + FifoSize


I use the #define to create easy to understand variables out of the DM[] memory:

#   Label Name          Variable
1  EnqIndx                 DM[1]
2  DeqIndx                 DM[2]
3  FifoCnt                 DM[3]


This allows me to create variables that are sort of "local" to a custom function.

Best of luck,

Gary d

[cdenk]

Thanks for the reply. I think I'm in trouble I have used the underscore "_" pretty heavily to separate the names into 2 or more words for readability. Has been working pretty good, but there have been times that compiling with what looks like good code, doesn't compile, and even when commenting out what is pointed out as offending. And yes, I'm aware that another error can make something else look bad. When entering into the table, the square brackets are changed to "_", but when exporting they are interpreted right in Excel. Would be nice to have something to break the words apart.

I don't know if you caught it, but Libre Calc (Open Office) will take in the exported file, but won't save the file in usable format.

Is there anyway to edit (find/replace) a *.PC6 file in a word processor or something?

Hopefully Tri-PLC will come up with a set of variable rules.

[garysdickinson]

I haven't found a great answer for editing PC6 files.

The exported custom functions are exported using what I'd call UNIX end of line format. I have found editors that can cope with the end of line problems.  Simple windows editors like NotePad can't deal with the exported format.

To get the edited text back into the PC6 program I cut and paste between my text editor window and the iTriLog custom function editor window.

I also use the "find" and "find all" stuff in the custom function editor as a crude search and replace mechanism.

I wish I had a better answer,

Gary d

[cdenk]

My computers dual boot Ubuntu 12.04 Linux. I should be able to use GEDIT to edit. Not super convenient, not being able to run Trilogi under Ubuntu. But, I heard of possible under Wine. Would be good to have a native Linux version of Trilogi along with going to a recent Java version. Maybe the 2 tasks could be combined.

[cdenk]

Still looking for some guidance on what the variable name allowances and restrictions are: Length, forbidden characters.

[cdenk]

Did a little research (don't take this for gospel, it's just a start), entering label names into the Define Variable names table, and then looking at the *.PC.6 file with a hexadecimal editor. Found the following:

1: Trying to enter special characters 2nd character or further to right (shifted top row of the keyboard), the only symbol accepted was "#", all other characters appeared as an underscore "_", but when looking at them in the hex editor, they appeared as 00h.

2: Maximum number of characters for a label name is at least 32, I didn't try more. The name "A234567890123456789012345678912" was accepted, Simulate compiled and seemed to work in a small program OK.  

As I said, this is a start, not to be relied upon at all. The only thing I kind of learned. There are no characters available to use a word separators for readability, which means the "_" I have been using is not good, and have a lot of editing to do.

[garysdickinson]

Cdenk,

Excellent work.  32 characters is pretty useful.

As you are figuring out the character set that you can use with the #define is fairly limited. This is as expected.  TBASIC does not use white space as exclusively as a symbol delimiter.

The following are equivalent:

A = b + c / e
A=b+c/e

This says makes +,*,<,>,=,^,|,-,",',$,(,),: definitely off limits.  All of the TBASIC function and statement names are off limits.

Anything that starts with a..z and the second character is a _ will will screw up the TBASIC parser.  This is a result of the "variable commenting" silliness.

/*  */  C comments will screw up stuff.

About all you have to make things readable is mixing upper and lower case such as FifoBaseAddress.  However, TBASIC, doesn't make any distintion with upper and Lowe case.  FIFOBASEADDRESS is the same as FifoBaseAddress.

You also must not create things with the #define mechanism that uses the same text pattern that you have used to define anything in the I/O Table.  Fortunately, you will get error messages for this.

Gary d