09-22-2020 03:05 AM
On a side node, I never use type defs since I started OO.
Type def clusters are just a way to make 'objects'. Either an object should be a class, or just a control.
Out of 3000+ VIs, I have 4 type defs, all enums.
09-22-2020 05:50 AM
I like the functionality of typedefs, especially when in development. I do not want to follow every caller VI when I change the control. From another suggestion (crashing when changing strict-typedefs [LINK]) I stopped using strict-typedefs altogether.
@GerdW: I can give a cluster unique names but not the elements it holds. When I use the cluster multiple times LV sometimes decide to change the wiring to another cluster (with the same datatypes) or to another variable. I am unsure how I can track theses changes when I can not detect a pattern.
09-22-2020 05:58 AM
In my experience, everything goes ok if I apply one change (rename or reorder) at a time: make one change, then save the typedef and update ALL calling vi's, as already stated by GerdW. Of course, this is more time consuming.
09-22-2020 06:15 AM
@pincpanter wrote:
In my experience, everything goes ok if I apply one change (rename or reorder) at a time: make one change, then save the typedef and update ALL calling vi's, as already stated by GerdW. Of course, this is more time consuming.
I applied this method after my developer course (2015), but apparently every few months this problem shows up. My current method when changing a element (typedef):
It only gets really annoying when I cant reopen the project -> therefore the save-copy. This procedure takes ~30min with no guarantee of success.
09-22-2020 06:20 AM - edited 09-22-2020 06:21 AM
Hi sh,
@s.h._tech wrote:
My current method when changing a element (typedef):
- Add a variable -> no reorder!
- Save the project
- Deep copy the project in order to preserve the current wiring structure
- Close the 'Element'
When you add a "variable": do you add new elements to clusters?
What is a "deep copy"?
Which "Element" do you "close"?
@s.h._tech wrote:
- Wait ~1-5min for LV to Update
- If LV crashes (~75% of the time): try reopen the current project and manually rewire the suspect connections
- If LV does not crash: Check important wires (digital pins to power supplies, analog outputs,...)
It only gets really annoying when I cant reopen the project -> therefore the save-copy.
With all the experience you got by now: do you use any SCC tool to keep a history of your code?
(When the answer is "No!": why don't you use a SCC tool?)
09-22-2020 07:07 AM
The trick only works if all callers of the type def are in memory.
For normal (non-class) VIs, they are only loaded if they are called. So if you have a main that contains all VIs in the project, it will work, but only if it is open.
If you don't have all callers in memory when making edits, you will be in trouble...
09-22-2020 07:10 AM
When you add a "variable": do you add new elements to clusters?
Yes
What is a "deep copy"?
Strg+C , Strg + V and then a zip. I had the experience that the save management of LV is still not reliable. I can only recover the project with its correct VIs when I zip it. When I dont zip it, some VIs try to link to the current (broken) project.
Which "Element" do you "close"?
The modified <Test>.ctl (in there is a cluster with variables of different datatypes)
With all the experience you got by now: do you use any SCC tool to keep a history of your code?
(When the answer is "No!": why don't you use a SCC tool?)
No. I honestly do not have an answer to that. I use version control for almost all other software development.
I will try to implement such a tool before the next project, maybe I can reduce the rewiring time.
09-22-2020 07:14 AM
wiebe@CARYA ha scritto:
The trick only works if all callers of the type def are in memory.
For normal (non-class) VIs, they are only loaded if they are called. So if you have a main that contains all VIs in the project, it will work, but only if it is open.
If you don't have all callers in memory when making edits, you will be in trouble...
That's the reason why I capitalized ALL in my answer.
But this is may not be your case, if there are no dynamically loaded vi's.
09-22-2020 07:24 AM
Hi sh,
@s.h._tech wrote:
I will try to implement such a tool before the next project, maybe I can reduce the rewiring time.
In SVN it's just a right-click and selecting "Revert…" to go back in history!
09-22-2020 07:24 AM
@pincpanter wrote:
wiebe@CARYA ha scritto:
The trick only works if all callers of the type def are in memory.
For normal (non-class) VIs, they are only loaded if they are called. So if you have a main that contains all VIs in the project, it will work, but only if it is open.
If you don't have all callers in memory when making edits, you will be in trouble...
That's the reason why I capitalized ALL in my answer.
But this is may not be your case, if there are no dynamically loaded vi's.
Or if you have multiple main VIs. Or VIs that are part of a library, but that are not used... Or if you forgot to open the main.
Not sure how I did this without SCC...