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

[Sparkette]

 

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

Edited September 9, 2014 by flarn2006

[JKSH]

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

[Rolf Kalbermatter]

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

 

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.

[Sparkette]

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. 

 

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 September 10, 2014 by flarn2006

[PiDi]

 

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

 

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

 

[Sparkette]

 

 

 

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

 

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

[Rolf Kalbermatter]

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. 

[ShaunR]

 

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

[Sparkette]

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. 

 

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. 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 January 30, 2019 by flarn2006

[BramJ]

 

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

Edited September 10, 2014 by BramJ

[hooovahh]

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.

[Sparkette]

How did you get a beta version of LabVIEW?

[hooovahh]

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.

[Sparkette]

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.

[Neil Pate]

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.

[Yair]

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