We encountered a nasty problem last week when we tried to move a few variables around and it was only after we started digging deeply that we realized the actual variables in our program had been changed because the variables were moved to different registers. We only found it because the size of the program changed when we loaded it and attempted to resave it.
If the T3000 software had a cut and paste function to move these variables then a warning could be raised or the issue could be handled directly. This took a while to resolve and represents a landmine when people are attempting to write code.
I can understand what is happening behind the scenes but it definitely shouldn’t be hidden in the way that it is at this time.
When there’s something we can do to make our system more robust you can be we will do it.
I think what you are saying is you moved some variables from say, VAR1 was moved to VAR10 or something along those lines and in the process your program got messed up.
I know if you use your own ‘Label’, the 8 char shortcut name for vars, that moving or renaming these can cause problems. If I notice something going on like this I will temporaroly fall back to using the VAR1, VAR10 naming convention in the program, once the program is sending and reloading correctly I will re-introduce the custom labels like ‘AHU1SET’ for example.
Let me know if I am on the right track and how you envision the cut & paste feature would work. Click and drag of individual VARS in the table view would be great.
That is exactly the problem but the side effects are very subtle because the program is changed from what a person writes and a person won’t learn that unless they happen to look at the program.
Unfortunately, if the program has any length to it, switching back and forth between the alias and the actual variable name is likely to inject errors of its own.
Just for background info:
When T3000 sends a program to a T3 controller, the T3000 application will encode the user’s 8 character label as VAR10 internally. When T3000 reads a program from the T3 controller it will see VAR10 and switch it to the corresponding user label.
This is not related but just mentioning that when there are two PC’s operating on the program and naming of IO, vars and such they will definitely be out of sync from each other. The system operates on the ‘whoever wrote last wins’ principle.
The issues you mentioned about renaming and moving will take some coordination with our T3 firmware developer, we will work something out and report back shortly.
We aren’t doing any editing between different computers. This issue is strictly the result of moving variables positions around while the program is running.
In one example, we realized some inputs were switched and tried to swap their names. This broke the variable references as well the PID setup on those inputs.
In another example, we tried to reorganize some variables that had been renamed to better allow them to be found in the list and created problems from it.
When you have multiple windows open for inputs, outputs, pids while simultaneosly editing a program, then changing a label, I can see how T3000 could get confused. I will spend time to solve this problem. Thank you very much!
I think that’s the case with the variables moved that you described. In Figure 1, the Label of VAR1 is defined as V1, and program V1 = 1 is written. Then the second step, as shown in Figure 2, moves V1 of the VAR1 Label to the VAR2 Label, and it will appear that V1 or VAR1 or a label name similar to OLD_V1 in Figure 4 is still used in program.
The reason for these phenomena is that when we say program is written to the device, VAR1 is actually written instead of V1’s name, and program always performs VAR1 = 1 operation.
If you want the position of V1 to change, the corresponding program must change with it. According to what you mean, program needs to automatically change to VAR2 = 1, which requires our firmware engineers and T3000 to make some changes for this special operation. These operations may also affect the programs of many customers. We need to evaluate the feasibility of such operations and make them compatible. Thank you very much!
I think what Fandu is saying there is the program is written to operate on VAR1, regardless of what you have named it in the user name column. If you want the program to now operate on VAR2 becuase of some renaming you have done, you will need to check through all the programs and also move them there. Same goes for elements in the graphics screens, in the trend logs and so on.
This is understood. The problem is that it is extremely brittle when you have anything other than a very simple program and means that a simple code reformatting exercise can wreak havoc. This was why I said it might be easier simply to implement row cut and paste functionality in the T3000 software along with a popup disclaimer that indicates that a move action might compromise a program on the unit.
That would at least make it clear that damage is being done instead of it being hidden in the weeds.
I agree with you and I am also talking to another developer to improve the situation. My idea is that when the customer moves the Label V1 of VAR1 to something else, such as move to VAR3. In the future, the T3000 will pop up to prompt the user whether to change VAR1 and VAR3 in all programs. Either way, this is risky because the developer cannot guarantee the complexity of the client’s application. Thank you for your understanding and support.
I used to program buildings for a living myself and managed to work my way around it. One thing I can recall doing was to rename the item as XXXXXX and wherever you see that you know you need to make it point to the new object.
That said, a MOVE POINT function could be useful. The T3000 could then search for occurances of that item in the VARS, INS, OUTS, GRAPHICS, TREND LOGS and so on and help you to move items around. We have a small team and the todo list is long but we’ll add it there Jason. If there are some developers listening out there I will gladly sponsor this project.
