Jump to content
News about the LabVIEW Wiki! Read more... ×
flarn2006

I can't be the first one to have tried this. XD

Recommended Posts

I concede, it has never crossed my mind to try this.. :-D

Share this post


Link to post
Share on other sites

attachicon.gifthick.png

 

Now the question is whether there's any practical use for such a data type?

 

Same as JKSH. Just because I can make a super-mega-prontosaurus cluster (and have seen some people do that) it would never ever come into my mind to do that myself.  :D

 

Same about C++ object hierarchies that are cascaded over umtien levels!

 

Your example simply points out that LabVIEWs datatype handling is not only highly recursive, but also able to handle that. As far as practical usage for such a beast, it ranges even lower than my super-mega-prontosaurus cluster mentioned earlier.

Share this post


Link to post
Share on other sites

Same as JKSH. Just because I can make a super-mega-prontosaurus cluster (and have seen some people do that) it would never ever come into my mind to do that myself.  :D

 

Same about C++ object hierarchies that are cascaded over umtien levels!

 

Your example simply points out that LabVIEWs datatype handling is not only highly recursive, but also able to handle that. As far as practical usage for such a beast, it ranges even lower than my super-mega-prontosaurus cluster mentioned earlier.

 

Part of the fun was figuring out that while multidimensional arrays and nested queues have caps at how thick the wires are drawn, they weren't programmed to detect each other. I.E. while a 4D array has a thicker wire than a 3D array, a 5D array wire isn't any thicker than a 4D array wire. Same with queues of queues of queues of queues. But once it's determined the thickness to give the wire based on the dimensionality of the array, it doesn't take that into account when determining the base thickness of the wire, as determined by the data type the array contains. And that data type may be a quadruple-nested queue, which has a similar means of determining thickness. And what if the data type contained in the queue is another 4D array? It's not programmed to deal with that kind of recursion as far as limiting the width of wires goes, so there doesn't seem to be any limit to how thick it can get.

In other words, I wasn't trying to point out how data types can be nested really far; I was just pointing out how LabVIEW wasn't programmed with that particular kind of combination in mind, so the wires can get infinitely thick. So thick, in fact, that it causes glitches where not enough of the screen is redrawn in certain cases because it doesn't expect the wire to go beyond a certain space.

Edited by flarn2006
  • Like 1

Share this post


Link to post
Share on other sites

 

 

 

Together with classes wires, you can make nice conveyor belt if your dataflow ever gets clogged  :D

 

attachicon.gifconveyor.gif

 

 

Is it possible to change the wire appearance of a class through scripting? If so, you could probably even animate the conveyor belt...for more efficient dataflow. That's how wires work in LabVIEW, right? :P

Share this post


Link to post
Share on other sites

Part of the fun was figuring out that while multidimensional arrays and nested queues have caps at how thick the wires are drawn, they weren't programmed to detect each other. I.E. while a 4D array has a thicker wire than a 3D array, a 5D array wire isn't any thicker than a 4D array wire. Same with queues of queues of queues of queues. But once it's determined the thickness to give the wire based on the dimensionality of the array, it doesn't take that into account when determining the base thickness of the wire, as determined by the data type the array contains. And that data type may be a quadruple-nested queue, which has a similar means of determining thickness. And what if the data type contained in the queue is another 4D array? It's not programmed to deal with that kind of recursion as far as limiting the width of wires goes, so there doesn't seem to be any limit to how thick it can get.

In other words, I wasn't trying to point out how data types can be nested really far; I was just pointing out how LabVIEW wasn't programmed with that particular kind of combination in mind, so the wires can get infinitely thick. So thick, in fact, that it causes glitches where not enough of the screen is redrawn in certain cases because it doesn't expect the wire to go beyond a certain space.

 

With your arguing about this being a failure of LabVIEW, all guns would come with a protection that they can't fire at all, so nobody can get harmed.  :D

Share this post


Link to post
Share on other sites

 

I can't be the first one to have tried this. XD

 

I expect you are. When you program for machines and instruments from the real world. Edge cases of the programming tool are pretty dull :P

Share this post


Link to post
Share on other sites
On 9/10/2014 at 4:51 AM, rolfk said:

With your arguing about this being a failure of LabVIEW, all guns would come with a protection that they can't fire at all, so nobody can get harmed.  :D

 

I'm not saying that's a failure; I'm saying it's a failure that it doesn't redraw the block diagram properly! I'd be the last person to say letting you do something dangerous is a failure of LabVIEW.

 

Also, it turns out that not only is it possible to change wire appearance through scripting (though technically the property doesn't require scripting) but you can go beyond the options given in the class preferences dialog--I was able to smoothly animate the conveyor belt moving...even if parts of it are moving the wrong way. :P Dataflow efficiency at its finest!

 

Conveyor Belt Animation.zip

 

Run "Animate Conveyor Belt.vi", and while that's running, look at the block diagram in "Test VI.vi". It even carries data!

 

EDIT: Turns out through that same property you can even give a class a wire thicker than anything seen in this thread. Also you can change the rendering mode for wires (copy, or, not copy, etc.) but for some reason LabVIEW crashes anytime it's set to anything besides Copy. I would understand if it was a private method, but it's not even marked scripting, so it was a little surprising!

EDIT2: Looks like as of LabVIEW 2018 (possibly earlier) the aforementioned crash bug has been fixed. Props to NI for fixing the bug and not just making the method private 👍 Never mind; it wasn't. But they're aware of it now at least.

Edited by flarn2006
  • Like 1

Share this post


Link to post
Share on other sites

:D

 

Too bad it doesn't transport VI's *hint*

Edited by BramJ

Share this post


Link to post
Share on other sites

while a 4D array has a thicker wire than a 3D array, a 5D array wire isn't any thicker than a 4D array wire. 

I remember a beta of one of the versions of LabVIEW had a bug where this wasn't true.  A 5D array was bigger, and a 6D array was bigger with no limit.  It was interesting to make a build array be huge and see the massive wire output like what you have here.

Share this post


Link to post
Share on other sites

How did you get a beta version of LabVIEW?

Answering this seems far too dangerous.

 

EDIT: Alright fine, just know breaking a NDA with NI is a very bad thing.  Beta sign up.

Share this post


Link to post
Share on other sites

Answering this seems far too dangerous.

 

EDIT: Alright fine, just know breaking a NDA with NI is a very bad thing.  Beta sign up.

 

Aww, there's no beta for LabVIEW right now; just other products. Thanks though.

Share this post


Link to post
Share on other sites

Aww, there's no beta for LabVIEW right now; just other products. Thanks though.

 

The LabVIEW beta normally rolls out around about January or February.

Share this post


Link to post
Share on other sites

In recent years it was always early-mid February. It's usually also announced in a few places, such as in the NI forums.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

By using this site, you agree to our Terms of Use.