Sparkette

I'm looking at the XNodes included in the FPGA toolkit, for instance vi.lib\eio\EIONode\EIONode.xnode, and I notice there's only a few abilities, and many important ones are missing. Like the GetImage ability. How are these XNodes drawing graphics, etc. without these abilities? I do see some VI's in the same folder that would draw the image, but they don't seem to be referenced by the XNode. So how does this work? Similarly, the "function block" XNodes in the RT module respond to a "CONFIG" message to open the properties dialog. However, if I create my own XNode with a Message ability, it doesn't even receive those messages. Why is that? (Topic mentions both FPGA and XNodes; no telling who will post here! )

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

Yeah I figured that, but I was wondering if maybe there was an easier way I could enable that NI used to debug xnodes.

Good explanation, thanks! And you mentioned tools to avoid paying for LabVIEW, the difference is that that's illegal. Maybe that's why there's still no way to get the raw VHDL code...perhaps if I get an fpga I'll try to fix that Do you happen to know if the BASYS is compatible with that driver? It uses the Spartan 3E.

I don't have a Spartan 3E, but I'm just wondering: why does NI say people are only allowed to use the Spartan 3E driver for educational use? Don't they want their FPGA module to be usable on as much hardware as possible, so more companies would have a reason to buy it? Why would they introduce an arbitrary restriction like that? (Also, why doesn't Xilinx create their own driver without such a restriction?) Also, with that driver, would I be able to program a Digilent BASYS Spartan 3E board? I'd like an answer quickly, because I found one on eBay that's Buy It Now, but I'm afraid someone will bid before I know it'll work.

I saw something in the GenerateCode ability VI for one of NI's XNodes that says to open the VI in the NI.LV.XNode context. Would this let me do that?

Well with the password cracking thing, I can understand not wanting it to be posted here, as that can actually theoretically cause harm to companies that rely on the password protection to hide code. My opinion on the matter is that they were asking for it by relying on such an insecure system, but I understand if some people don't share my opinion. Same with the thread about enabling native XNode development that I posted with the admin's permission (and later changed my mind about and had removed after seeing what a negative response it was getting) just because of the kind of program you use to perform the hack. As for this, however, it's not really stuff that could in any way hurt the reputation of the forums, or harm NI or anyone else. I'm just trying to find and expose stuff that NI didn't see fit to release for one reason or another, but that advanced users might like to play around with outside of important work. For science. (You monster.)

I just found the Wikipedia article about CPU shielding, which seems like exactly what I'm asking about. A quick Google search doesn't reveal anything about doing this in LabVIEW though.

For anyone watching this thread, I've found another one's purpose. (ShowHiddenLibraryItems.) Unfortunately I don't think it's one of those super-secret ones AQ was talking about, as IIRC it gets checked on startup. But hopefully I'll find those soon! I've added this to the OP, but it basically shows a bunch of extra stuff when editing statechart libraries.

Thanks for the counter tip, I'll take a look at that when I get a chance. If that doesn't work, I'll just keep using the serial out on my Arduino. Also, I looked up the myRIO, but on NI's website it doesn't even list the price, and says to contact my NI representative! Can't find one on eBay (where I got the myDAQ) either. But seriously, why wouldn't they list prices? If they did wouldn't they get more business, because it would be easier to buy it? (Humorously, when I searched for "ni myrio" on eBay, it autocorrected to "ni mario"!)

Don't have one. EDIT: In case anybody's interested, I actually ordered a RIO evaluation kit on eBay today. (Not for this though.) Just thought I'd update this post.

Now if only LabVIEW was open source...

I always just keep them enabled. I don't have to worry about accidentally using one without realizing it's private, as the nodes will turn brown.

Disclaimer: This technique makes use of multiple private properties/methods (one of which is optional), as well as some private menu options accessible through the INI key "enableSecretPopups=True". I believe this use of them is safe (in fact I'm pretty sure RestrictLRGrowMove is being used for its specific intended purpose!) but as I don't work for NI, I can't make any guarantees. I know that many of LabVIEW's dialogs are implemented as VI's, and I was curious if the statechart module's state configuration dialog was implemented in this way as well. Sure enough, it was, which meant it was possible to create an editable block diagram as part of a VI's front panel. It didn't take long to figure out that the input/output nodes on the left and right were really unbundle/bundle by name nodes, as it was literally as easy as putting the mouse over one and looking at the context menu! I didn't at first know how it prevented them from moving left and right or being copied to another VI, however. I realized it had something to do with the object's flags through experimenting in Heap Peek. Then I found the private property called "RestrictLRGrowMove", which had this exact effect. So yeah, this is basically just a VI I created as a demonstration of this technique. It's possible to put a block diagram in a subpanel through a scripting method, and it's also possible to enable editing in that subpanel through a private property or hidden menu item. Of course, the latter means this isn't officially supported by NI, but it's still an interesting technique. Perhaps someday it will have official support. And if you're wondering why the unbundle/bundle nodes only show the text, it's actually very simple: there is no way to scroll in the subpanel unless scroll bars are enabled, and the rest of it is simply out of the viewable portion! The subVI that generates the embedded VI is kind of messy, but I put a step-by-step explanation of how it's generated on its block diagram as well for that reason. Subpanel Diagram Example.zip

I want to use a MyDAQ to communicate with a serial LCD I got at RadioShack. However, it is my understanding that the MyDAQ doesn't have built-in hardware timing for digital I/O. I know I could use one of the analog outputs as a digital line, but I'd rather use an actual digital output if possible. My computer has a 6-core processor, so I was wondering if maybe I could use one of those processor cores for the same purpose one would use a real-time OS. Is there any way I could install something that would run at kernel level and make Windows temporarily behave as if there were only five cores, giving my VI exclusive control of the remaining core to use for timing? (or would other USB devices, or the USB controller itself, add too much latency?) Or is there some other way I haven't thought of to output a 9600-baud serial output from a MyDAQ digital line? EDIT: Thank you, whichever moderator clarified the title for me as I requested!

Here's some more that may or may not have been in the initial Pastebin dump, found by doing random things in LabVIEW with the script running. Are any of these what you were talking about, Aristos? None of them seem too secret (with the exception of the misspelled "PaletteHidden..." ones, which are actually just lists of categories to hide), but you never know.

I don't see what's wrong with the term "subVI". Yeah, any VI can be used in another VI as a subVI, but once that happens, it's no longer a top-level VI, so the term will apply.

If they are read by the same internal "CfgGetDefault" function, my script can find them. The only way they wouldn't be in that Pastebin dump I linked is if they are read by a different function or if they aren't read as soon as LabVIEW opens. If the former case, it'll take more work. If the latter, it's just a matter of running LabVIEW through Cheat Engine (with the Lua script running) and trying different things until it checks for that token. But I accept your challenge, provided you're not just trolling.

Did you mean to add "penalty" or something there? Also, I decided to give this a try myself. Here's an XNode I made that's basically the type cast function, only it implements the behavior described in the thread. (I actually got the idea to do this in an XNode before I noticed hooovahh's post; maybe he hadn't posted it yet.) A couple warnings though: one, I haven't tested it that much, and two, it uses a private method in the GenerateCode ability to create a constant of a given type. No idea why this method is private; I don't see any problems using it can cause, but I'm warning you because I imagine it's marked private for a reason. Also, if you right-click it, there's an option to replace it with a regular typecast node along with a constant of the proper type. Auto Typecast.zip

Okay, thank you! Actually, come to think of it, how were those decorations initially placed on the Silver controls? The ones that aren't in the palette, I mean.

It works with a void array constant as well, not just Initialize Array.

Easy to reproduce; just follow these steps: Place an Initialize Array node in the block diagram Make it a large number of dimensions (really anything more than 1 will work, but do more for full effect) Do not connect anything to the Initialize Array, so it remains void Right-click the output terminal, and go to Create->Indicator Look at the index displays on the front panel. When the array indicator is created, it's supposed to set aside memory to store the selected indices for however many dimensions are needed. But apparently, if the type is void, it only sets aside room for one dimension, leaving the additional index displays pointing to addresses that are supposed to be used for other things. I searched for the values that appeared using Cheat Engine, and sure enough, it cuts into a section of memory that looks like it's being used for something else. On a side note, just for fun I changed the values on all the index displays, and one of the index displays changed to show garbage characters. Then when I closed the VI, LabVIEW crashed. So yeah, it looks like a buffer overflow. This is in 2014 btw.

Good advice for future reference. I didn't know that was possible. But he has helped me out before. Here's a list of all the keys and what they do.

Oh in that case I would guess it's okay. I didn't pick up on that part. Though there's still no guarantees. And you wouldn't want to use one like Genericity.

That's weird; that first VI you posted closes as soon as I open it. And the second one points to a directory that doesn't exist.