Sparkette

I have a bunch of serial devices on a Raspberry Pi, and I'd like to be able to access them as VISA devices in LabVIEW. What's the best way to share a serial device on Raspbian in a way that VISA can connect to? I know if nothing else I can just use socat and do it as a raw TCP/IP connection, but I'm wondering if there's a better way.

I think I know what the problem is; I hadn't thought of it until now. I'm pretty sure the specific internal command I used that method to call is only in LabVIEW 2015. Might be in 2014, but I don't think so. It should work if you uncheck "Load as XML" though, but that won't work in the Easy XML Editor VI though. I'll add a toggle in the next version that should fix that. It might work if you click Continue on the error box however. Of course, if you do that, you'll need to enable XML saving manually. To do that, just open the Ned menu (your post indicates you know how) and look for the "heap save format" option. Click that until it says XML. Then save your VI and open it with the resource editor. Don't forget to set it back to Binary2 afterwards! If anyone else sees this post and doesn't know how to open the Ned menu (Cloedu72's post indicates he knows how), you need to open LabVIEW.ini and add the line "LVdebugKeys=true" (without quotes) and restart LabVIEW if it's running. Then you type "DN" while holding down Control and Shift.

I thought the XNode properties and methods could be created without having the XNode license installed, as long as you have scripting and SSPSS turned on.

Looks like someone beat me to it! Oh well, I already exported it (also for 2009, incidentally) so I'll post it here in case it'd be more convenient to use a regular VI file. 0 to -4096.vi

If I don't have it up by tomorrow then remind me okay?

I used scripting and low-level VI editing to generate a VI with every single decoration object in LabVIEW, at least those with ID's 0 to -4096. There may be some out of that range (and many in that range don't have a valid image associated with them) but this range contains a lot of them. 0 to -4096.vi

Don't worry; the default palette is 100% organic.

Correct! More specifically, I switched the "bounds" properties of the two input terminals.

It's clearly not a compound arithmetic node. Is there a way to make one look like a regular subtract node or something? And you don't win anything; I'm just curious if anyone will figure it out.

I have a challenge for you: looking at this VI snippet, it appears that this loop should stop after 11 iterations. However, when you click Run Once, it doesn't stop. See if you can figure out why it doesn't stop. Hint (if it really is much of a hint): it uses a trick I sincerely doubt you've ever seen before! If you don't have LabVIEW 2015 (or don't feel like loading it from a VI snippet), here's a version that should work on versions as far back as 2009: LV2009.vi

Huh, it looks like this can edit the .rsc files in the "resource" folder. I wonder what kinds of things you could do with that.

What do you mean you need to stop talking? Are you under some kind of NDA or something? Also yeah, I think I get what you mean. In fact I could actually just leave the second hash unchanged if it's only the block diagram that was modified. Thanks.

Thanks for your feedback! Here's some specific points that I think are worth mentioning: Yep, it appears I didn't. I actually thought I tried it the way you suggested before but it didn't work; I guess I was mistaken. Oh wow you're right; I forgot to connect that terminal! *facepalm* I guess that's what I get for not testing it with any VI's that actually had terminals.Also I wasn't aware that it includes values in clusters, etc. Thanks for letting me know so it doesn't confuse me later. I thought about brute forcing it like that, but I was thinking it would take too long because in order to check it each time it would need to save the VI with the new checksum and attempt to open it. Do you know a better way to test it? Or does it not take as long as I'm thinking even with a maximum of 8,000 attempts? I was not aware of that; I'm pretty sure one of the checksums is calculated partially from the library data though, but I may be wrong. Oh wow you're right (edit: I just realized this is the second time I said that); I was thinking I needed a numeric constant that shows up as a string, but I guess I could also make "find resource by type" a polymorphic VI so it can accept a number or a string. I'll do that. I have it trying to find BDHX, BDHc, BDHb, and BDHP, the first one being for XML, the others being what I saw on the VI Explorer page. Are there more I'm forgetting?EDIT: Oh, I see what you mean. *facepalm* I made the subVI to find the right one once I realized that it could be named something different, but I forgot to actually use that subVI. Yeah, I forgot about that. When I post the next version I'll save it for 2014, and then if anyone needs an older version they can ask.Thanks again! EDIT: One more thing, how did you fix those relinking issues you found before? I want to know so I can make sure it's not an issue when I post the next version.

Okay, now I have something a bit lot better for you. I made a GUI that lets you edit resources. Plus it can automatically load VI's as XML. And you know what else? It even fixes that checksum. (Turns out Thomas Zeugner, the VI Explorer guy, already figured it out, and posted a description on his website.) I've posted it here.

One thing I've always wanted (and have asked about here before) was a way to edit the data inside VI files at a low level. Well I finally figured that out. I have here a tool that will let you open a VI, look at the individual blocks of data stored within, and make changes. Plus, with the power of private methods and internal settings, it can also convert VI's to a format where the front panel and block diagram are XML-based, so you can easily edit the raw representations of objects. Here you go. Run "Resource Editor.vi", select a VI (make sure you make a backup first if you care about it), and click Load to load its resources. Click "Load as XML" if you want to edit the front panel and diagram as XML. If you've edited the block diagram at all, make sure to click Fix VI Checksums. Then just click Save once you've made the changes you want. EDIT: Second version is posted; this one should work in LabVIEW 2014, and fixes some bugs. I also added copy/paste buttons for the front panel and block diagram resources, since LabVIEW's built-in copy/paste function didn't seem to work for some reason. Note that if you edit the front panel or block diagram in the VI without using copy/paste (and the size is different), you need to update the size (first 4 bytes) as well. You can do this by clicking Copy and then Paste. Now this may not be too useful for you, considering it's not something you should use in production code or anything you don't want to break. (I say that a lot in my posts, don't I?) But if you're curious about how VI's work internally, it's perfect. This requires OpenG. Also, special thanks goes out to Thomas Zeugner for making VI Explorer. You know, that tool for cracking VI passwords. Turns out he figured out how the VI checksum (in the BDPW block) is calculated, which helped me greatly. Oh, one more thing, I do plan on improving it. I was just excited to share what I had. So keep in mind there may be bugs. Latest version: The latest version is posted on the tool's home page, here: http://flarn2006.dyndns.org/llvim/ Older versions: Low-Level VI Manipulation rev2.zip Low-Level VI Manipulation.zip

I'm curious how the wires are able to ignore structure boundaries and loop around without feedback nodes. What confuses me is that the channel readers/writers are plain old subVI's, and the channel terminals appear to just be strictly-typed VI refnums.

Warning: This shouldn't come as a surprise given the title of the thread (as well as who's posting it) but this is NOT officially supported by NI. Don't use this for anything you don't want to break! I ran a VI that recursively opened every VI in the LabVIEW installation directory and scanned it for Call Library nodes, then saved anything it found to a spreadsheet. And guess what it found in the palette API? Functions that open and save "resource" files, which happen to be the way VI files are internally stored, as well as some other LabVIEW files. It lets you manipulate the internal resources as an array of clusters. Now in case you didn't already know, the front panel and block diagram are stored as binary resources (known as "heaps") in this file, and these functions can't parse that format. So it's not too useful, right? Wrong. Does this dialog look familiar to anyone? That's the hidden internal settings dialog, known for some reason as Ned. To access it, add LVdebugKeys=True to your LabVIEW.ini file and restart LabVIEW if it's already running. Now hold Control+Shift and press D, N. You have to press the keys relatively quickly for it to work. (You can press D, H instead to open Heap Peek, which lets you view the internal representation of objects, as well as their exact location in memory--think about how the latter might be useful!) Now do you see that option I have selected? "Heap Save Format (Binary2)". Click that a few times, and you'll see one of the options is XML. Yep, it turns out LabVIEW has a hidden XML-based VI format. It even opens just fine with the heap save format set to the default. Keep in mind only the heaps are saved in this format; the rest of the file is still binary. But that format can be parsed by those library functions I found. Unfortunately, it seems the block diagram has some sort of checksum and the VI won't load if that's wrong. I know this because after making a simple change to the XML (changing the block diagram's background color) it didn't load, and there was a a 16-byte section in the file that was changed with seemingly-random data. I suspect that this is MD5, considering that seems to be the standard LabVIEW uses, but I tried calculating the MD5 hash of certain parts of the file and it didn't seem to match. Here's two VI's that you can use to turn resource files (like VI files) into resource cluster arrays, and vice versa. Load Resource File.vi Save Resource File.vi And here's a VI that will automatically set the heap save format to XML (using the private method "Application.Call Internal Command"), save a VI (from a refnum), and then put the heap save format back to what it was before. So it basically just saves a VI in the XML format. Save VI with XML Heaps.vi

Why exactly do you need this to be an XNode? Why can't you just use a subVI?

I was wondering what that "GenericLabVIEW" XNode was for. Interestingly it seems like you're supposed to also be able to select a background texture for the node when "show icon" is turned off (i.e. "express VI"-like display mode.) But the image files are missing, so it doesn't work. But I don't think .vim stands for VI Macro. I think it just means it's an improved VI. /s Interestingly, the code for generic VI's is actually still in LabVIEW, even 2015. Even the hidden option that I assume Aristos used to create the example one he posted. (Add "GenericsAreGo=True" to the ini, right-click a control/indicator and there's a new "Generic" toggle in the menu--don't use it in anything you care if it breaks of course!)

I thought the PPF let you create new types of items that can appear in projects too.