Sparkette

I'm not wondering why it is what it is; I'm just curious if other people see it the same way I do. So I'm asking, just for fun.

This is my first XNode. You can place it on the block diagram, resize it, and it displays its size in pixels. If you double-click on it, it also shows the local coordinates of your double-click. It can be useful if you need some help visualizing coordinates when writing code for things like scripting front panel editing and image manipulation.

Coordinate Helper XNode.zip

I think your proposed fix is not a fix but just a change of the bug. With the fix as proposed by you you end up with an index in the range -1 to n-1 instead of 0 to n. So you replace the invalid index at the end of the range with one before the range. The -1 should be better placed after the Array Size function.

Oh yes, that makes sense. And Index Array works the same on an empty array regardless of what index is given, right? Even a negative number? It just gives the default value for the array?

Here is a jing clip of the Heartbeat Exhibit.

http://screencast.com/t/owijhiujxEi

Oh, so are you not allowed to post the VI?

That's interesting! I designed that exhibit about 6 years ago along with a LabVIEW controlled Laser Harp which used to also be at that museum.

Wow, really? Care to post the VI's? It's a museum after all; I doubt you'd be under an NDA.

And I thought that laser harp was still there; at least it was in 2009.

I saw this at the Maryland Science Center in Baltimore and I just had to take a picture of it. I only thought to post it just now.

Aristos Queue mentioned to me that Generic VI's will no longer work in LV2012. It's a shame they couldn't have changed it so it was more stable, but I guess since it's unreleased they don't really have any obligation to.

But as consolation (actually just for fun), here's another Generic VI I made that takes a random choice from an array.

Random Choice from Array.vi

EDIT: Actually that has a glitch where it will sometimes give the default value. This is no fault of the generic VI system; I simply forgot to add a on the blue wire between the and the . But when I tried it afterwards, LabVIEW crashed, which shouldn't come as much of a surprise. But it's a simple enough fix.

Not a special compiled version, just a certain way we can configure the UI to make controls generic.

Could you post a screenshot of the menu or whatever else it is you use to customize that? It's not like it would give us access to any features NI doesn't want us to have, just satisfy my curiosity about that kind of thing.

An excellent tool, but why put that link in a new post? I know you knew about it before then, as I believe you got that link from me.

Try the following:

1. Open LabVIEW and create a new VI
   
2. Double-click on the front panel and type some text
   
3. Save the VI
   
4. Open the saved VI in a hex editor
   
5. Search for the text you typed
   

For some reason, the text doesn't appear. Any idea why? Are VI files compressed? If so, can I save it without compression or decompress it?

Any SuperSecretPrivateSpecialStuff that can help?

I don't get what you're trying to say. But it did make me think of another reason NI intended it as the second pattern: because of the way the vertical wires look.

Also, I just realized, I posted the wrong image at the top of my first post. I meant to put the single string wire there, not the array. But we all know what it looks like anyway.

As we all know, string wires look like this:

Path and picture wires look the same, only teal and blue respectively.

I'm just curious what all of you think; I know it doesn't matter, but what pattern do you see that wire as? I've always seen it like this:

You know, as a line with many bends in it.

NI probably intended it as something more like this:

I know this because arrays of strings look like this:

which is the same pattern extended another row.

What do you see it as?

Well how do you think did they do the first controls of a new data type? Probably something like handcoding with specially compiled LabVIEW that has special tools included. And about how the compiler gets confused, I'm sure you will never hear a detailed info. For one thing this is NI internal, and for another thing unless you understand a project like LLVM from ground up, it would make no sense to you if they would give you a more technical explanation. Go study LLVM and once you understand it, you may be qualified to understand at least in parts what all might go wrong there.

I'd love it if someone from NI could post a few screenshots of that specially-compiled version, just out of curiosity.

Any function to do the reverse? Maybe you could do some interesting things by editing that code.

Over the past few years, I have advocated that several private properties/methods that could be useful to the wider LabVIEW audience be made public/scripting. I have been largely successful. Please let me know (on this thread, or with PMs, or whatever) if y'all come across private entries that you think would be useful, and I'll see what I can do to make them official in a future LabVIEW version.

Well, I just took a quick look and noticed a couple, like App.Get Shell Icon of File and App.License.Get Licensed Version.

Also, are there any other "security levels" of properties and methods? Right now I have access to public, scripting, and private, but are there any others? I ask because for the XNodeLib type (returned by App.XNode.Create) there are no properties or methods.

That's certainly a shame. As I'm sure you know, I think it would be great if the LabVIEW community had access to all the same tools as NI, but I doubt that's going to happen. Sorry if I did anything you or NI didn't like (like the Generic VI thing I posted last night, which I imagine inspired this post) but I really wanted to share my findings with the community. Don't take it personally, not that I think you do; I would have done the same no matter who released it. I wish NI would share more things with the community, even if they aren't fully tested. After all, that's what alpha releases are for.

One thing I'm still curious about is how NI makes generic VI's. Obviously the controls have to come from somewhere, so how do you make them? Is it like some kind of low-level VI editor that edits the individual data structures in the file? Also, how exactly does the compiler get confused?

Yes, I'm aware of that. That doesn't make it any less fun to mess with though, as long as I'm not doing anything high-risk.

Oh, okay, that makes sense. Thanks for explaining. They still could have used a nicer color for the property/invoke nodes, though. Like #80FF80 (this color).

And what is there some trick to?

EDIT: I am unable to edit my first post, but I have made .ctl files for this that can be easily added to your palette.

Generic Controls.zip

WARNING! As Aristos Queue stated, this is VERY experimental. I am not an employee of NI and am not responsible for anything bad that happens if you use this. Basically, it's just for experimentation.

Just drop that VI snippet into a VI, and it will work with any array type. I copied it from Randomize 1D Array. If you don't know what a generic VI is, click that link.

Here's a sample I created that takes a 1D array of any type, and outputs an array which is basically that array concatenated to itself. For example, {1, 2, 3} becomes {1, 2, 3, 1, 2, 3}. Not too useful, but it works as a proof-of-concept. And in case the VI snippet isn't working, you can copy the control and indicator from there.

Download link: Duplicate 1D Array.vi

Another thing that might work (though I haven't tried it) is to take the DBL out of the array and see if that works with any type as well (not just any array). I can still think of a few uses for this, such as if the value is just going to be typecasted anyway. Like, say, something that converts any data into a hex string.

EDIT: Yep, it works, and here you go. Data to Hex String.vi

EDIT2: There is actually a much easier way to do this, which is likely how Aristos made the generic controls in the first place. All you have to do is open LabVIEW.ini, add the line "GenericsAreGo=True" somewhere, and you'll be able to right-click a control and select "Generic" to make it generic.

EDIT3: Out of curiosity, I tried putting a generic control in a Malleable VI to see what would happen, since Malleable VI's basically do the same thing. Guess what? Crash. Not immediate, but it happened after I moved the subVI on the diagram. Fix your code, NI! (just kidding!)

The only posts I can find about this LabVIEW.ini key are from more than five years ago. Open LabVIEW.ini, and add "SuperSecretPrivateSpecialStuff=true" and then place a VI property node. Tons more properties appear, and if you select the new ones, it becomes this dark tan color, similar to scripting with the cyan color.

Interesting...too bad it's read-only.

So what exactly would make something qualify to only be enabled by this and not the scripting toggle? And Aristos, does IsGeneric indeed mean what I think it does?

Every time LabVIEW crashes for me, it gives me several disk errors beforehand. Each of these has "Cancel", "Try Again", and "Continue" as buttons. I've always just clicked Continue, so I'm not sure about what happens if you click a different one. Here's the sequence of errors: (not sure if it's the same every time)

There is no disk in the drive. Please insert a disk into drive \Device\Harddisk2\DR3.

There is no disk in the drive. Please insert a disk into drive \Device\Harddisk2\DR2.

There is no disk in the drive. Please insert a disk into drive \Device\Harddisk2\DR2.

There is no disk in the drive. Please insert a disk into drive \Device\Harddisk2\DR2.

There is no disk in the drive. Please insert a disk into drive \Device\Harddisk2\DR3.

There is no disk in the drive. Please insert a disk into drive \Device\Harddisk2\DR3.

There is no disk in the drive. Please insert a disk into drive \Device\Harddisk2\DR3.

There is no disk in the drive. Please insert a disk into drive \Device\Harddisk2\DR3.

There is no disk in the drive. Please insert a disk into drive \Device\Harddisk2\DR3.

I do have a RAID setup, so that may have something to do with it. It's just annoying, sort of adding insult to injury whenever LV crashes, which unfortunately isn't as seldom as I'd hope.

Yes. A new VI takes a few minutes to develop. A new node takes a few days at a bare minimum for the simplest node: type propogation, compiling, marking which inputs are in place to others, adding documentation, potentially marking which versions it's available in, enumerating each of the terminals, potentially adding properties and methods, maybe making it support different types (do you have any idea how many numeric nodes support clusters of numerics?), building the intermediate representation for the compiler, building the compiler code for it, etc. Plus all the time it takes to actually compile LabVIEW. Plus time to check for type-safety bugs (e.g. dereferencing null), save for previous, etc. LabVIEW takes care of all of these things for VIs.

We have a document for creating new primitive functions that is 12 pages long because there are so many different things you need to worry about. Creating nodes (which are more complex than primitives) is much harder.

I'm curious about that document. Any chance I (and the rest of the community, of course) can see it?

Also, hooovahh, I saw your post, and I don't feel like a "leet haxor" just because of something small like that. Don't jump to conclusions.

Oh, okay. In case you're wondering, it was in a password-protected VI, so that makes sense. Hmilch's VI Explorer is awesome.