The documentation stated:“There are 26 local variables available to each program. These variables can assume any floating point value. The current value of a local variable can be determined by using the PRINT command (i.e.: PRINT A). Local variables are unique to each program and cannot be used anywhere else in the system. The symbols used for local variables are the characters of the alphabet (i.e.: A,B,C…Z).”
when PRINT A - the program reports an error. Show how to initialize a local variable? how to use the program further? for example: 10 PRINT A = 45.5 20 A = A + 1.25
Thanks.
Sorry to report here Zamild, the local variables are documented from an earlier incarnation of this product but not yet working in the current version. We’ll get the work ported over shortly. This is a high priority item for us, you can expect something in a week or two.
Update: Local variables are implemented, they show up in a special color which you can adjust, the default is grey. As you type the text will change color if there’s a match with any other item in the database. This helps while programming, any items in your program which don’t line up with the database will be grayed out making it easy to see them at a glance.
Is there a prohibition on having the same variable name on multiple T3’s on a network? I think there might be. I tried that and one or the other T3 seems to change itself to a blank variable name.
It’s logical that I might be shooting myself in the foot by using the same name. So just to be on the safe side, I will always make them a little different.
1 Like
Yes, all the names should be unique for all controllers in a given system.
1 Like
This is a key bit of info, that if forgotten will really mess up customers that have multiple T3’s on their network. In other words, all variables across all T3’s in a network must be unique. And BTW, does the same rule apply to input and output labels?? I thought I saw something in a post that once a variable is defined (a label established) it is automatically available to all T3’s on the same network. Is that true? This could be the reason I have so much trouble getting some T3’s to communicate. If it is true, it’s a wonderful and somewhat “unsung” feature of the T3’s.
1 Like
Yes each input, output, variable and so on, all the user names should be unique. This way you can refer to ‘OAT’ for the outside temperature in any program on any controller. They will sort out which controller and which input that is.
1 Like
Wow!! If it works, that is a HUGE salient feature. That oughta be plastered all over your marketing materials. I have already made a half-hearted effort to make sure every variable is unique on every LB. But I will double back and check inputs and outputs too. Ironically, it’s OAT that has given me the biggest problem over the years I have been using T3’s.
1 Like
T3000 maints a cache on your hard disk for all the user names in a given building, as you type new names it does its best to prevent you from creating duplicates. The system can get out of sync with devices being added, deleted and renumbered. There’s room for improvement as our system transitions to the db powered backend, instead of separate prog files for each device as we use now.
1 Like