LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Only one Vi Debugging with LVOOP


wiebe@CARYA wrote:

I can't get it working either. At least not with XML.

 

I'm pretty sure it's something in LabVIEW preventing this.

 

Flattened data seems to work. I have only tried this with copy-paring data, so not with automated string manipulation. However, copy-paste flattened data works, while copy-pasting XML doesn't.


My guess is that they did that to prevent code from violating private scope; and that the fact that flattening/unflattening works is probably an oversight, which they might "fix".

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 21 of 29
(336 Views)

@paul_cardinale wrote:

wiebe@CARYA wrote:

I can't get it working either. At least not with XML.

 

I'm pretty sure it's something in LabVIEW preventing this.

 

Flattened data seems to work. I have only tried this with copy-paring data, so not with automated string manipulation. However, copy-paste flattened data works, while copy-pasting XML doesn't.


My guess is that they did that to prevent code from violating private scope; and that the fact that flattening/unflattening works is probably an oversight, which they might "fix".


It doesn't give that much problem in the normal context. The hole point of From\To XML\JSON is for getting\setting (class) data.

0 Kudos
Message 22 of 29
(332 Views)

wiebe@CARYA wrote:

@paul_cardinale wrote:

wiebe@CARYA wrote:

I can't get it working either. At least not with XML.

 

I'm pretty sure it's something in LabVIEW preventing this.

 

Flattened data seems to work. I have only tried this with copy-paring data, so not with automated string manipulation. However, copy-paste flattened data works, while copy-pasting XML doesn't.


My guess is that they did that to prevent code from violating private scope; and that the fact that flattening/unflattening works is probably an oversight, which they might "fix".


It doesn't give that much problem in the normal context. The hole point of From\To XML\JSON is for getting\setting (class) data.


Flatten to JSON won't take a class.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 23 of 29
(325 Views)

@paul_cardinale wrote:

wiebe@CARYA wrote:

@paul_cardinale wrote:

wiebe@CARYA wrote:

I can't get it working either. At least not with XML.

 

I'm pretty sure it's something in LabVIEW preventing this.

 

Flattened data seems to work. I have only tried this with copy-paring data, so not with automated string manipulation. However, copy-paste flattened data works, while copy-pasting XML doesn't.


My guess is that they did that to prevent code from violating private scope; and that the fact that flattening/unflattening works is probably an oversight, which they might "fix".


It doesn't give that much problem in the normal context. The hole point of From\To XML\JSON is for getting\setting (class) data.


Flatten to JSON won't take a class.


Just XML then.

0 Kudos
Message 24 of 29
(314 Views)

@MaddinDorn wrote:

Hello,

 

I've tried LVOOP and found that it's more cumbersome to debug small Vi. The nice thing about LabView is,
that you can debug each Vi individually by setting the parameters on the front panel. But in LVOOP the data in the
Clusters are stored by the object and I can't toggle them from the front panel. Therefore I would have to create a new Vi and parameterize the cluster to the respective data and then start my desired vi afterwards. This is very cumbersome, is there a simple solution?


I've been thinking about this, and one solution is to make more private functions that don't use the class wire for data, but unbundle it outside, so it's more akin to 'classic' functions.

So instead of unbundling class data and calculate it as one function, you have a private function that works on an array and a wrapper that unbundles and calls this function.

Would that work?

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 25 of 29
(310 Views)

@Yamaeda wrote:

@MaddinDorn wrote:

Hello,

 

I've tried LVOOP and found that it's more cumbersome to debug small Vi. The nice thing about LabView is,
that you can debug each Vi individually by setting the parameters on the front panel. But in LVOOP the data in the
Clusters are stored by the object and I can't toggle them from the front panel. Therefore I would have to create a new Vi and parameterize the cluster to the respective data and then start my desired vi afterwards. This is very cumbersome, is there a simple solution?


I've been thinking about this, and one solution is to make more private functions that don't use the class wire for data, but unbundle it outside, so it's more akin to 'classic' functions.

So instead of unbundling class data and calculate it as one function, you have a private function that works on an array and a wrapper that unbundles and calls this function.

Would that work?


That's way too kludgy, even for me.

"If you weren't supposed to push it, it wouldn't be a button."
Message 26 of 29
(298 Views)

@paul_cardinale wrote:


That's way too kludgy, even for me.


It would be even more VI's, yes. 😕 The biggest problem with lots of VIs is coming up with decent names. 🙂

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 27 of 29
(289 Views)

@Yamaeda wrote:

@MaddinDorn wrote:

Hello,

 

I've tried LVOOP and found that it's more cumbersome to debug small Vi. The nice thing about LabView is,
that you can debug each Vi individually by setting the parameters on the front panel. But in LVOOP the data in the
Clusters are stored by the object and I can't toggle them from the front panel. Therefore I would have to create a new Vi and parameterize the cluster to the respective data and then start my desired vi afterwards. This is very cumbersome, is there a simple solution?


I've been thinking about this, and one solution is to make more private functions that don't use the class wire for data, but unbundle it outside, so it's more akin to 'classic' functions.

So instead of unbundling class data and calculate it as one function, you have a private function that works on an array and a wrapper that unbundles and calls this function.

Would that work?


I'm not sure I understand that last part.

 

You mean like making a private 'super accessor' for all data?

 

That wouldn't work outside the class (because it's private). Making it public would be a serious encapsulation breach.

 

Another problem is that such a function wouldn't update automatically when the private data is updated.(if a cluster is used). So maintenance is high and errors are very likely.

0 Kudos
Message 28 of 29
(283 Views)

I'll throw together an example of my thoughts when i get home.

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 29 of 29
(275 Views)