Jump to content

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


Sparkette

Recommended Posts

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.

Link to comment

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
Link to comment

 

 

 

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

Link to comment

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

Link to comment
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
Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

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