can the Scripting add and configure CLIP-s/IPIN-s ?

[Jerzy Tarasiuk]

Hello everyone!

When a large IP with many connections is added to a LabVIEW project (CLIP Declaration, and instance), or VI (IPIN), it is easy to make a mistake in its configuration, and it would be nice if the configuration could be set programmatically.

Is it possible to use Scripting for the task? Starting from VHDL top-level file (and possibly other files needed by it), create a CLIP Declaration file, add it to FPGA target properties, and then add CLIP instance to the target?

I tried it, but I could only produce an incorrect CLIP instances. The AddItem function on the FPGA Target has 3 inputs only: Name, Path, and Type; the Type (it is a String) has to be "FPGA Component Level IP" in order to add a CLIP instance; I don't know what is it to be to add a CLIP declaration; the Path seems to be ignored, but maybe the function may produce better results when a correct Path is specified?

In IDE, the CLIP Declaration is added in FPGA Target Properties menu (Component-Level IP there), and I must pass through several screens and modify some entries in them in order to create CLIP Declaration file and add it to the target.

Thanks in advance for any hint.

[Jerzy Tarasiuk]

The CLIP instance configuration of a signal includes ArbitrationForOutputData and NumberOfSyncRegistersForOutputData or NumberOfSyncRegistersForReadInProject, depending on the signal direction. If a signal is to be synchronized with the CLIP clock, these sync register numbers are important, as they introduce delays by one or more clock cycles. I would like to set their values programmatically, not manually, to avoid mistakes.

However, I am unable to find a programmatic interface for these numbers. In the LabVIEW project file, they can be found in many places: the CLIP instance <Item Name="CLIP-name" Type="FPGA Component Level IP"> contains an Item for each signal, with a <Property Name="eioAttrBag" Type="Xml"> containing the signal settings as Attribute-s. This is relatively simple. But these settings are also in "FPGA Target" properties "configString.guid" and "configString.name", which are very long strings, and I don't understand these string structures - it seems to me that some extra data is necessary to parse them correctly, maybe some offsets to items contained within the string.

These "configString.*" properties are not limited to targets: FPGA VI-s have them as well.

Edited January 25 by Jerzy Tarasiuk

[Jerzy Tarasiuk]

I have just made a test: started from an almost empty project (cRIO + FPGA Target defined), added a sample CLIP declaration, and an instance of the CLIP; then saved the project, closed it and edited the .lvproj file to change *SyncRegister* values in CLIP signal items to 0; opened the project again, and then LabVIEW signalled the project was changed and should be saved. When I save the project and examined the .lvproj file, these configString.* long strings contained 0-s as *SyncRegister* values. This means the LabVIEW adapted these long strings to values that I had put into CLIP signal items properties, and these settings can be changed by just editing the .lvproj as an XML file.

I used a plain text editor to make changes to the .lvproj file - this was still manual job, prone to errors, I plan to write a program that will use an XML parsing library and make similar changes semi-automatically. An important finding from the test is that I don't need to modify these strings which I don't know how to parse.

[Jerzy Tarasiuk]

Hello. These VI-s mentioned below all are in: [LabVIEW]\vi.lib\rvi\ClientSDK\Core\Script\Clip\Public

Need XML file containing CLIP declaration, to add it to an FPGA target use niFpgaClipApi_ValidateXmlAndAddDeclaration.vi which needs arguments: FPGA target reference, the XML file path, a string "User Defined"; the VI returns "CLIP declaration data" cluster, consisting of: Declaration Category = "User Defined", Declaration Name (from the XML file, probably must match the file name), Valid?, Syntax Errors.

To add a CLIP Instance to an FPGA target use niFpgaClipApi_CreateUserDefinedClipInstance.vi which needs arguments: FPGA target reference, the instance name (generated if unwired); the VI returns "CLIP project item" for niFpgaClipApi_SetClipDeclaration.vi which needs the item, Declaration Name and Declaration Category obtained when adding the CLIP declaration to the FPGA target.

Before the entire action one must open the LabVIEW project (using Invoke Node for This Application constant, and the project path), use project Propert Node to get its targets and choose a proper one.

After the action I closed the "CLIP project item" (I'm not sure it this is necessary), saved the project using Invoke Node "Save" on its reference, and finally closed the project reference.

Well, now I need a way to create the CLIP declaration XML file, and it would be nice to find something to modify CLIP signals without going to the low-level LabVIEW project XML file access.

[Jerzy Tarasiuk]

Using Scripting to get help on Scripting

Looking at all functions in vi.lib that potentially are useful 
for Scripting is time consuming - one may get such a function
into a VI, look at help info shown, manually write down the
info - but something can be done using the VI Scripting.

I have selected directories in vi.lib containing items related
to CLIP and IPIN. And I used VI Scripting to put every VI from
them into my VI, and get terminals of the library VI.

As the final result I have two text files listing these VI-s
and their terminals, with some information on data types.

Now when I am looking at a VI, I can quickly locate VI-s that
can use outputs from the VI, or can provide data for it.
Previously I spent a lot of time trying to find which function
may produce a signal that I need to use another function.

The program consists of 3 VI-s:
* get_terms3.vi
  inputs: "Node Refnum" and "error in"
  outputs: "TerminalsInfo" and "error out"
  The "Node Refnum" must get the function to be examined, and
  the "TerminalsInfo" will be an array of strings describing
  its terminals (one string for each terminal).
* dc2fc3.vi  (directory contents to function comments)
  i: "VI Directory Path" (the directory to look for VI-s)
  o: "OK", "TargetName", "VI Count", "new VI path", "log path";
  The target is of the VI itself; new VI and log are temporary.
  The VI processes all VI-s in the directory (but without its
  subdirectories, if there are any), creates a temporary VI
  (tmp.vi calling VI-s found) and a temporary log (tmp.log);
  the log contains the directory name in its first line, and
  then VI names followed by information on their terminals.
* mdc2fc3.vi  (multiple directory contents to ...)
  input: "Input commands path"
  output: "Output directory path"
  The input should be a file containing lines:
        nick = directory to process
  (no extra blanks/tabs/etc. allowed after directory name,
   blanks are allowed around the '='; nicks must ne unique).
  The previous VI is called for each directory, and these
  tmp.vi and tmp.log will be saved to the output directory
  as nick.vi and nick.log; additionally, _master_.log file
  will contain processed lines from the input.
 

The attached GetFuncInfo1.zip contains these 3 VI-s (for LabVIEW 2018), 2 text files produced with help of the program, and a Tcl script used to join many files into one (to use the script need enter the directory where the program saved its outputs, and run the script redirecting its output; additionally, I used an editor to replace C:\Program Files (x86)\National Instruments\LabVIEW 2018\vi.lib with [vi.lib]).

Looking at these results I have seen a data type of "Refnum: LVObjUnknown" is quite frequent, and I found at least some its occurrences are LabVIEW project items - seems the function (from Variant palette) I used to identify the data type doesn't know project items.

GetFuncInfo1.zip