10-25-2013 09:58 AM
Dave,
Yes
10-25-2013 10:20 AM
Hi Dave,
You can also tear down your clusters on the FPGA, organize them in nice decorations with grouping of controls/indicators, and change their name so that the "Cluseter" name is before each individual item with a period "." separating the cluster name and sub-element item's name. This would allow the individual items to be accessed from these tools, and also still make the items to show up in the same menu structure when accessing from the native standard interface. The only downfall is that you can't write/read to all the items with a single write/read.
Background: Adding the period in the name (i.e. "cluster.item1", "cluster.item2", etc.) will group the items together in the menu when using a Read/Write node on your native host API even if the items are not in a cluster together. I don't remember if the items had to be "grouped" or not though.
Regards,
Mike
10-28-2013 11:39 AM
Hi Mike and Stephen,
I found a bug in Get FIFO Offsets by Name and Data Type. Basically it has to do with the order of the FIFO list as it is read out from the bitfile. If a "higher" data type is before a "lower" data type in the list, then it prevents the later FIFOs from being detected because the index gets stuck on 0 as the while loop terminates, looking for a higher data type.
I fixed the problem by simply iterating on all elements for every data type, even if they've already been found in a previous data type. I've got the fixed file if you want it, can't seem to attach to the post
10-28-2013 11:47 AM
Nice catch!
Thank you for the fix.
You can attach here if you click use advanced editor in top right
10-29-2013 10:01 AM
Hey Stephen,
That may be an Admin tool, I dont see that option.
I have another question though. Do you have any advice on how to close open RIO sessions after an abnormal termination? I get errors from FIFOs saying that they are in use by another session, but the FPGA DVR gets lost when the code stops. I dont have anyway of closing the session.
10-29-2013 10:59 AM
You dont have this button?
No I don't have a suggestion on that... other than avoid the abnormal termination entirely. How is it happening?
10-29-2013 11:08 AM
Ah on the reply screen, not the main page. Got it. Here is the file.
About the abnormal terminations - either a LabVIEW crash or inadvertantly programming in a hang somewhere such that you need to abort. Resetting the FPGA doesn't appear to release open sessions. Only a full reboot clears it.
11-08-2013 08:22 AM
I've picked up using this again for another project - what I'm doing is having a really nice reconfigurable data logger that uses DAQmx (amongst other things) and now I need to log data from a 9148 with some modules in it.
One of the things that's really cool is that I can read the list of available controls/indicators from the bitfile and use this to show the user which signals are available and which ones they are interested in. The really useful part, I hope, is that later down the line I can develop other FPGA VIs for different module configurations and load them onto the 9148.
The only problem though, which is where I come unstuck is the fact that I cannot pass fixed point numbers.
I don't *fully* understand how the integer->FXP functions work but what I have done in my previous project was to do FXP to Integer on the FPGA and then Integer to FXP (using the same FXP representation as the I/O node on the FPGA). The problem is that different modules have different FXP representations (in my current FPGA VI I have <+/-,24,-4>;<+/-,24,-2>;<+,18,3>;<+16,3>) which when converted to Integers produce different formats - e.g. I32, U16, U32 and these become my controls/indicators on the front panel of the FPGA VI.
Do I need to know the fixed point representation for each control/indicator on both sides (FPGA & PC)? In an ideal situation I would want to look at the indicator type information (e.g. U32) and then use the I/O node name (e.g. AI0, AI1 etc.) to indicate that I need to convert to an FXP on the windows side.
The other question I guess is, will FXP's (and I guess SGL...as that's now available in LV FPGA if I remember correctly) ever be supported natively with this toolkit?
11-08-2013 10:09 AM
Unfortunatley FXP is painful with this API for your use case. If you know the types ahead of time just FXP/Integer cast back and forth but if you don't.... there isn't a good solution.
For SGL... the underlying dll the API calls doesn't support SGL yet.
Ideally when this graduates to a shipping product we will have some better answers.
11-08-2013 11:14 AM
Thanks for the update - it sounds like I was correct in that that you have to know in advance the FXP representation on both sides (if you are writing to controls as well as reading from indicators). At the moment, I think I will either add some FXP type information to my FPGA code that I can read on initialisation or do something on the host side with the information of the supported bitfiles.