Sparkette

Okay, going into the build specification and changing the Design Strategy (in the Xilinx Options section) to Minimum Compilation Time seems to fix it.

I guess it came with my FPGA? It's a RIO Evaluation Kit from eBay.

Actually, it's more likely that it was installed when I installed the Xilinx FPGA compile tool, because LV said I needed it.

It's just some text in the Xilinx Log section of the compile progress window.

### Generate Xilinx IP (Generate Xilinx IP) ###

### Estimate Resources - PlanAhead (Estimate Resources - PlanAhead) ###

****** PlanAhead v14.7 (64-bit)
  **** Build 321239 by xbuild on Fri Sep 27 19:29:51 MDT 2013
    ** Copyright 1986-1999, 2001-2013 Xilinx, Inc. All Rights Reserved.

INFO: [Common 17-78] Attempting to get a license: PlanAhead
INFO: [Common 17-290] Got license for PlanAhead
INFO: [Common 17-86] Your PlanAhead license expires in -10 day(s)
INFO: [Device 21-36] Loading parts and site information from D:/NIFPGA/programs/Xilinx14_7/PlanAhead/data/parts/arch.xml

Now it's been stuck on Mapping; compile time is 00:25:37 and counting. It said something about a PlanAhead license expiring in -8 days; is this something that was speeding it up and now that it's expired it's taking longer? If so, can anyone recommend a good free alternative I can replace it with?

The last two times I tried to compile an FPGA VI it took a significantly longer time than it used to, and it never ended up compiling. I forgot what stage it got to the first time, but the second time it just stayed frozen on "Placing and routing" for a half an hour, so I cancelled it, because I figured something was wrong. It was a simple VI; similar VI's compiled in like 5 minutes or less. I hadn't compiled any FPGA VI's for a week or two in between, so I don't know what I could have done in that time that broke it.

Has anyone else had a problem like this / know how to fix it? Thanks.

I have this type of setup too; my C drive is a 160GB SSD, and my D drive is a 2TB HDD. Understandably, I store the vast majority of my files on drive D. And for me, the NIFPGA folder appeared on drive D without me having to do anything. I did install LabVIEW on that drive; did anyone here install it on their SSD?

Yeah, LabVIEW is, VIs are not. LabVIEW is because it has to, otherwise you would need a "Save for future version" in your old LabVIEW. And VIs are not because every save VI would have to contain a specific block diagram (or parts thereof) for every previous version.

 

Long story short: Would you mind hitting the Save for previous version button on the XNode and exchange the original attachment? Probably save for 2009 or so? That way you would not only do me a favor but you could also reach more users in general.

 

Thanks, S.

 

 

PS:

 

 

I do the same in my XNodes. Real hackers don't read the generated code anyways, they read the generator

Although I find the concept of optionally cleaning up the code via a constant or using templates worth investigating.

Done; check the OP.

Huh. All this time I thought VI's were backward-compatible. Sorry about that.

If you're interested in the generated code though, here's an example:

Well actually that's after doing a block diagram cleanup; the raw code as it's generated is practically unreadable since everything is placed at (0, 0), and it doesn't programmatically do a cleanup because there's no real reason to.

EDIT: I just realized that the VI snippet will only work in 2014 as well. At least you can see what it looks like.

I needed to sort an array by using a different array's sorted order, but I couldn't find a function to do that. The easiest way I could find was to use Index & Bundle Cluster Array with the sorting array first, sort the cluster array, and then unbundle the original values from the array in a For loop. I decided to create an XNode to make this process easier! Since it's an XNode, it can work with any type of array.

Example usage and download:

LabVIEW 2014 version:

Sort Using Other Array.zip

LabVIEW 2009 version, uploaded by request:

Sort Using Other Array.zip

Forgive me if I'm missing something, but wouldn't simply closing and re-opening the VI also do the trick? Or is the undo history actually saved in the VI file unlike most programs' behavior?

Why should someone post a working ini file verbatim in a power presentation? The person creating this presentation remembered that PPFs are some restricted feature and simply changed a few characters.

Wouldn't be very useful without the VI's. But I guess there's always a chance that whoever changed it didn't know that.

Also, right now I'm working on a tool that automatically generates the interface VI's using scripting. That is, the VI's that output those huge clusters full of paths. I already finished all the scripting code (those diagrams can get quite complicated!) and now I'm going to create the actual interface for it.

EDIT: Finished; check the OP.

Sorry, I wouldn't know where to begin with that. Maybe someone else can once we know more about the framework.

This PowerPoint presentation is pretty much the only official documentation about the API by the way, and I noticed something kind of weird with it. On slide 25, it shows an example INI file, and it mentions how a signature is required. The signature shown in the sample INI file is "J7W9927AAAAAA5TBNTSSTTKWR29CNT9X". The six A's in a row caught my eye, and then I realized that 'A' isn't even a valid character in a signature! The correct signature would be "J7W9927KW29BR5TBNTSSTTKWR29CNT9X". Strange.

I tried it on the file: GOOP_Library.ini and it didn't work.

[Provider]
SupportedType={ABC740D6-F254-4BBC-5675-8858F35B820E}
IsPrimary=0
ItemInterfaceVI=..\Open_GDS\GOOP_Library_Item_Interface.vi
LicenseName=None
InterfaceVersion=1.0
Signature=N2JJ9X329XL9TBJR7XT9J2XRXBW7XCSN

The Value string is:

{ABC740D6-F254-4BBC-5675-8858F35B820E}0..\Open_GDS\GOOP_Library_Item_Interface.viNone1.0

But the Signature became: KXCB229B7CKCK9BRC5BC5SR7CC3J259R

Remember, only include strings, not numbers or Booleans. You put the 0 from IsActive in there, which is why the hash is different. I checked without that 0 in the string and the signature is correct.

EDIT: Wait, you're one of the developers of OpenGDS, so don't you already know how the signature is generated? Or does NI just give you a program that signs it for you?

Oh, I don't know. I think we appreciate it here but condemn most of these things because NI will do something about it now they know for sure it's been compromised

Well there's other, similar things they haven't done anything about.

Locals are WiFi, Globals are Cellular Data. If you want performance, wired is always the fastest and safest 

 

What about shared variables?

Wireless technology. It's about time we caught up.

No, private nodes are yellow LabVIEW nodes that are not available in the standard palette (but can be generated with your "Generate VI Object method"). The idea is that your external shared library somehow creates an object reference somehow (usually a pointer to whatever your shared library finds suitable to manage your object) and then this object reference needs to be assigned to the user tag reference. This can be either done on the LabVIEW diagram with such a node after the call to the shared library function to create the object reference or inside the shared library itself by calling undocumented LabVIEW manager functions.

 

Consequently there are matching LabVIEW diagram nodes or manager API calls to deregister an object reference from a user tag.

 

But again unless you intend to start writing shared libraries (C/C++ programming) to allow access to some sort of device, or other functionality, this really isn't interesting at all to you.

 

 

Generate VI Object? You mean like through scripting, right? I mainly just want to see what's hidden in LabVIEW, as I believe I've made pretty obvious in my other posts.

I have seen some interesting stuff in the Style list. Like who's Simon, and why does he have his own gauge? And there's this thing called "User Item" that appears as an I32 indicator, but it's just a box that says "38x38" and can crash LabVIEW. Also there's an "Array Interface Control" which looks like an empty array control, but it's kind of slow, and when I put a control in there it turns yellow. Yes, I know I'm kind of getting off-topic; I'll stop now

It's a generic user tag refnum. The functionality behind it is relying on information found in the resource/objmgr directory inside LabVIEW. Basically the rc files in there can define an object hierarchy and for each object type you can define methods, properties and events that map to specific exported functions from a shared library.

 

Once the generic tag refnum has been selected to represent a specific object type from one of the object hierarchies it is not generic anymore and you can not select other object types anymore from other object hierarchies. Also flags in the object type inside the rc allow to specify if the user is allowed to even select any other object type within the object hierarchy. It's all pretty involved and complicated (a single error in the rc file usually makes it completely useless and you can go and start guessing were the error is.

 

To interface in a shared library to a LabVIEW VI user tag refnum you also either need to use some private diagram nodes to register the session handle returned from your shared library to a user tag refnum and also one to deallocate it, or use internal LabVIEW manager functions to do that.

 

But unless you write drivers for some kind of interface in external shared libraries, the user tag refnum has no practical meaning for you at all. And it requires your shared library to be explicitly written to work with LabVIEW, it's not a means to interface LabVIEW to standard shared libraries at all.

 

By "private diagram nodes" do you mean private methods and properties? As in the brown property/invoke nodes? Is there a tutorial for this anywhere?

I tried turning on "View as Icon" on its terminal, and it shows up like a normal I/O name control would, only it says "TAG" instead of, say, "RIO".

I used scripting to create a constant from a "RIO Device" type descriptor, using Flattened String to Variant. But now it's giving me some kind of I/O name control I've never seen before. The down-arrow on the right is disabled, and when I right-click it, there's a new menu item that says "Select User Defined Tag Type". I googled it and didn't find anything. That menu contains "crioRefnumTag", "Data Exchange", "Variable", several FPGA-related items, "RIO Resource", and "System Config". When I select one, it seems to change into an I/O name control of that type, and the menu goes away. Has anyone seen this behavior? I've attached a control that has that menu on it in case anyone else wants to mess with it.

 

TagType.ctl

EDIT 1/26/22: Here's a VI containing the user-defined refnum/tag controls, as well as four private nodes that look relevant.

Useful Objects.vi

Resource Editor.zip

Need to add plugins of resource tag names "New Plugin.vi"

 

That looks interesting. Does it let you actually edit the data or just view it?

Also, here's a tip: if you need to call a function in LabVIEW.exe using a Call Library node, just type "LabVIEW" in the path box without quotes. That's what NI does, and that way it doesn't rely on a specific installation path (so you don't need to use the path input) plus AFAIK it's platform-independent. Though I doubt calling functions in LabVIEW.exe (except through VI's provided by NI) is at all supported by NI, in case that's not obvious. (All of the VI's in vi.lib that I've seen using that method were password-protected.)

 

Also rolfk, when you mentioned disks being unreliable, at first I thought you typed another, similar word that means something completely different.

I don't have that exact same eval kit, but yes, you can remove the daughter board without a problem.  If you have the 50 pin connectors you can easily use ribbon cables to connect to each pin.  Otherwise jumper wires are useful for individual connections.  They likely only exposed some of the channels in the daughter board to keep the size down.  The manual will list which channels are routed to which pins in the connectors.  

 

What confuses me is why they put the male connector on the main board. If they had put it on the daughter board instead (disregarding the irony of having a "male" connector on a "daughter" board, because that's a bad excuse) I could connect components and jumper wires directly to the holes like on a breadboard. I'm gonna email Adafruit and suggest they make their own boards for the sbRIO-9636, kind of like shields for the Arduino. It seems like something they would make. Only thing is it's kind of expensive for the average hobbyist; I only bought one because I found a good deal on eBay.

I generally have my palettes set up like so: for the front panel, a single palette generally kept in the Modern category, and for the block diagram, one palette for Numeric and a second palette for whatever category I tend to be using the most at the moment. All three are in Icons view. Now sometimes these palettes switch to Category (Icons and Text) on their own, usually when switching between writing normal VI's and RT/FPGA VI's. It's also a minor pain to put them back and set them all back to Icons every time the palettes are automatically closed, like when I install a VIPM package. However, if I set the default palette style to Icons (which I assume will fix this) the right-click menu becomes less useful, as it doesn't have the Programming category open by default with the others on the bottom. Is there a way I can tell LabVIEW that I generally prefer palettes in Icons view, but to use "Category (Icons and Text)" when and only when I open the right-click menu?

Thanks. I wouldn't create a whole thread just to ask that one question by the way; the main purpose of the thread was originally to figure out why it wasn't working, and then later on to tell people how I got it to work.

 

But I do have a couple more questions: the evaluation kit is basically an sbRIO-9636 with an additional board on top, right? If that's the case, then what's connected to analog inputs 8-15, and analog outputs 2-3? Both LabVIEW and NI's page about the sbRIO-9636 say they exist, but I can't find any terminals for them, or anything that says what they're connected to. Was there not enough room for the terminals? Is the only way to access them by removing the top board, which would also free the DIO 4-27 and AI 6-7? The same questions apply to the three COM ports listed in MAX as well. I don't think I would really have a need to, at least not any time soon, but in case it comes up, the top board can be removed without damaging either board, and I could later put it back, right?