LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

'Unbundle by name' changes without verification

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.

0 Kudos
Message 11 of 23
(1,042 Views)

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. 

 

 

0 Kudos
Message 12 of 23
(1,027 Views)

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.

Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
0 Kudos
Message 13 of 23
(1,019 Views)

@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):

  • Add a variable -> no reorder!
  • Save the project
  • Deep copy the project in order to preserve the current wiring structure
  • Close the 'Element'
  • 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,...)
  • Disconnect PXI from external equipment
  • Dry run -> check output, channels and limits
  • Reconnect external equipment
  • Live run: Can I still use all the functionality before the change?
  • Hoping that this was the last change

It only gets really annoying when I cant reopen the project -> therefore the save-copy. This procedure takes ~30min with no guarantee of success. 

0 Kudos
Message 14 of 23
(1,014 Views)

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?)

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 15 of 23
(1,009 Views)

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...

0 Kudos
Message 16 of 23
(1,002 Views)

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.

0 Kudos
Message 17 of 23
(998 Views)

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.

Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
0 Kudos
Message 18 of 23
(992 Views)

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!

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 19 of 23
(987 Views)

@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...

0 Kudos
Message 20 of 23
(986 Views)