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!