Sparkette

Neat idea using LabVIEW for game programming

Thanks for your help.

As it turns out though, I'm actually just going to keep running my code on that Raspberry Pi and use LabVIEW only for an additional component. There's another serial connection I'd need to share with LabVIEW, but it's an RS-485 adapter, and as it turns out, the sbRIO-9636 I'm using has an RS-485 connection built in, so I can just use that instead.

One alternative I thought of is running an LXI server on the Raspberry Pi. That could work, right?

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.

Hi flarn2006

 

I always receive an error when executing this very interresting tool. The Message look like that (Calling :

Error 53 occured at Invoke Node in Save VI with XML Heaps.vi

possible reason:

Labview: Manager call not supported

Method Name: Call Internal Command

 

Enabled: LVdebugKeys=true and changed the Settings in the NED Menu.

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

Could You save in LV 2014?

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

Please ensure that your genetically-modified nodes don't escape into the wild! 

 

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

I'm guessing h

 

 

I'm guessing he used his backdoor VI editor (https://lavag.org/topic/19178-low-level-vi-data-editor-warning-not-for-production-use/) to create a mutant subtract nod

 

Correct!

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

+ and - primitives use the compound arithmetic node, IIRC. I expect you set the first terminal to invert?

 

What do we win if we get it right?

 

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.

At some point I need to stop talking and we are pretty much there.  What I do feel comfortable saying (because it doesn't relate to LabVIEW in particular) is you have an equation similar to this (but not this exactly):

 

MD5(SomeData +  Salt + MoreData) = Hash

 

In this equation you can read the SomeData, MoreData, and the Hash from the contents of the file.  So plug those into your equation and all you are missing is the salt.  Put in a value of 0 for the Salt and see if the two sides of the equation are equal.  If they are you have your salt, if they aren't try another number.  Eventually you'll get it.  And knowing your salt is made up of three numbers, of which each is relatively low number, makes this test a pretty quick when it works.  When it doesn't work then usually what you thought was the value for one of your variables like SomeData was the wrong data, so the two sides will never be equal.

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:

It looks like you might just not know the right way to make UI's with the event structure. Generally you move the control into the case that is handling it, so that its value is read when you enter. Buttons being latch when released causes them to bounce back, so they are only true for that first time, then go back to false. This means when you enter the event structure it will always have a value of true and you don't need to check it.

Polling the timeout case with 0ms isn't necessary. The code does nothing until you press a button or interact with the UI so remove it.

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.

Now lets talk about this fix MD5 business you have going on. You prompt to ask how many Numerics, Strings, and Paths are on your connector pane, but you never use this data to calculate your salt. But even if you did you need to be aware that this includes going into other controls. If you have a single cluster with two numerics in it on the connector pane, and a scalar numerc also on the connector pane then you have 3. So this needs to include things like numerics and strings in error controls.

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.

A more robust method is to calculate the salt by reversing the equation and guessing what the salt is. I've done this in the past by assuming something like, there will be no more than 20 numerics, strings, or path controls on the connector pane. This could be increased of course. But with a known good VI you have the MD5 output, and the data going into the MD5 you just are missing the salt. An equation with just one missing variable. So if you keep guessing the salt, making the assumption that there will be no more than 20, then it doesn't take too long to go through each possible combination finding the one that makes the equation MD5 = Data + Salt. If you want you can remove the limit of 20 setting it to 255, but it would take a decent amount of time to go through all 255*255*255 possible combinations, where 20*20*20 is more realistic.

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?

You also aren't fixing some issues when VIs are part of a library, I believe there are other checksums that need to be updated but don't remember what they were exactly.

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 and was the XNode necessary? Could you just perform the search on the string name "LIBN" instead of taking LIBN then looking up the type as a number?

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.

And I know this won't work for all versions of LabVIEW. You know how Ned lets you save in multiple binary modes? That's because older LabVIEW versions used the older binary methods, which might have different named blocks, so BDHX I think is some times BDHA or BDHB.

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.

And 2015 is really new, most people aren't going to have it, an older version might have been a better choice.

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.

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.

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.

The first post I made created the XNode and abilities using scripting.  It would create the XNode, which is a library, then invoke the Add Ability where you specify the ability to add.  Both the Create XNode, and the Add Ability don't work if you don't have a XNode license.  Additionally List Members which usually tells you what items are in a library also doesn't work without a license.

 

So I'm not sure what other scripting functions you could try from the project window.  Just like with adding a VI to a project, you can't invoke a Create VI on a project using scripting.  You first create the VI, then use the Add Item.  And at this point we can't create the item, but we could probably add it if one was made.

 

The only other hope I had was to see if the Project Provider Framework was used to implement the XNode creation in the project window.  It wasn't, that would have been too easy.

 

Just so I'm not completely defeated I figured I could at least post a XNode which has all the abilities on it for a version of LabVIEW.  So if you want a 2013 XNode attached is one that has every ability.  If you don't like the name, you can open the XNode in LabVIEW, and perform a rename which will resave all the members.  That part does work without a license.  To remove an Ability delete the VI, then open the XNode in a text editor, and remove the Item section for that ability.  There are plenty of deprecated abilities that I probably should have included.  Like how Build Menu has 4 older versions when you should probably just use the newest.

 

Maybe you could use the Project Provider Framework for your tool. Does T3C5K7W9SBNRJLX2 ring a bell?

 

(Yes, I do have that memorized.)