Bind FPGA host reference to type definition in labVIEW 2012 crashes labVIEW

Hi,
I am using FPGA target device 5641R and labview FPGA 2012 with 5640R ver 1.7.
On the configure window of open FPGA VI reference function, choosing the dynmaic mode shows broken arrow when wired to the 5640R configuration VIs (i.e. Configure timebase, Configure ADC default, Configure ADC NCO functions). So i tried the other option which is binding the FPGA host reference to type definition and choose the control from path C:\Program Files\National Instruments\LabVIEW 2012\instr.lib\ni5640R\Configuration\NI-5640R VIs\ni5640R FPGA VI Reference.ctl. But after that when i try to save the VI on which open FPGA VI reference function is placed, labVIEW crashes. I am unable to figure out the reason. Earlier I was working with labVIEW 2011 and it was working fine there. Any suggestions would be highly appretiated.
Please see the attached images for more details.
Thanks
Attachments:
1.png ‏33 KB
2.png ‏71 KB
3.png ‏40 KB

Check out this thread. It looks like someone else ran into a similar issue and made changes that fixed their application.
http://forums.ni.com/t5/IF-RIO/correct-5640r-template-use-recommendation/td-p/1331918
Jeff B.
Applications Engineer
National Instruments

Similar Messages

Error Master Type definition could not be found : FPGA

I am having similar/exact error condition as in the below post..
http://forums.ni.com/t5/LabVIEW/Error-Master-Copy-for-Type-Definition-Could-Not-Be-Found/m-p/1496866...
The *.lvbit file i am using was compiled in Labview 8.2.1 and I am now using 2009 version of Labview. Unlike the suggested solution, recompilation of *.lvbit file is ruled out due to lack of source code access.
Any help towards troubleshooting is appreciated...

Because I am a bad scientist, I do not know exactly what fixed my problem because I changed more than one variable at once.
Here's what I did:
Removed auto-populating folder from project (doubt this mattered, still broken after this)
Changed my open FPGA VI reference from using a bitfile to using a VI, selected my FPGA VI, NO MORE BROKEN RUN ARROW! YAY.
The above finding led me to go look at my FPGA bitfiles on disk -- I had two of them (weird). Usually a compilation just overwrites the older file.
Just in case the names give any insight, they are:
Older: NASATTRControlCo_FPGATarget_FPGAMain_25B3817B.lvbitx
Newer: NASATTRControlCo_FPGATarget_FPGAMain_25AF817B.lvbitx
I went back to my open FPGA VI reference, and selected the most recent bitfile that I compile this morning -- No more broken run arrow.
I have a feeling this may be due to selecting an old bitfile, but usually if the bitfile doesn't include the control, it won't show up in the read/write control node. If anyone from NI would like to comment on this I'd appreciate the insight on what may have happened.
I am wondering if it's because I installed 2010 SP 1? Who knows but it's fixed now.
CLA, LabVIEW Versions 2010-2013

Passing a reference to a type definition to a SubVI

I have created a type definition that I would like to use across my application. This particular type definition is also the front panel control to my top level VI. I wanted to pass a reference to this control to my SubVi's so that they could dereference as needed and in very rare cases update the values on the front panel. However, as I built the application I noticed that I was breaking the control reference as I updated the type definition. This implies that they type of the reference changes as I change the type definition.
How do I go about building the reference I need or is there some other way to do this that works just as well. Even if I can't make a reference to the control that is tied to the type definition, I'm willing to pass in a variant who can house the reference as long as I can build the data type (the reference) inside my SubVis.
Solved!
Go to Solution.

Okay, so I tried all three approaches in a SubVI, here's what happened.
My approach was simply to create a Type Def control, right-click and create a Reference. Then create a control from that reference by right-clicking the output of the reference and selecting the Create Control option. I then pasted this 'cluster' reference into my SubVi, made it an input and then wired up the reference in the parent to the control in the SubVi.
Result: This breaks when you update the Type Definition.
Next, Ben's approach (or my best effort at doing what he suggested). I created a control from reference to the type def. I cut it from the parent VI and pasted it into a new type def. I then put the type def in the SubVI and set it as an input.
Result: This breaks when you update the Type Definition (but it actually takes a bit longer for the error to propogate).
Finally, Christian's solution (or my best effort). I took the type def reference and put it through a To More Generic Class guy, casting it to a Control Refnum. I put a Control Refnum on the front panel of my SubVI and wired it to a To More Specific Class guy. I created a control of the type def in the subvi, hid it, and created a reference. I wired the reference to the more specific guy and verified I was getting the right data.
Result: It works!
It's possible I just didn't understand how to make the reference type def you were referring to Ben. I would prefer a method with less verbage. I pass this refnum into a class which holds it. Since I can't replicate the type exactly prior to run time (i.e. create a control that is exactly a reference to the type definition of my front panel), I have to save the reference as a Control Refnum and cast it every time I need it (i.e. create a control from the typedef, create a reference frome the type def, etc). More verbage than optimal, but still good!
Thanks for the help.

Determine if a control reference is a strict type definition

If a VI is passed a control reference it can determine the VI Server Class using the ClassName property but how can it determine if the control reference is from a control which is based on a strict type definition?

That a pretty neat little VI you've found, Darren. Kudos!
The solution that Darren presents, however, will not tell the difference between a typedef and a strict typedef (unless I'm missing something). If you have VI Scripting enabled (see attachment for where to enable this in the Options menu), you can expose the Is Typedef? property.
This returns an enum with the following values (as pictured)
not a typedef
typedef
strict typedef
class private data
Although this property is not settable in a VI at run-time, it should be readable.
Below is a picture of the Options menu where you can enable VI scripting
Mitch
Attachments:
VIScripting.PNG ‏33 KB

Type definition and reference

Hello,
when I look at the "Usage" column in the Types view, am I right to assume that the first location given for a type is where the type is defined, all others where it is referenced?
Example:
Name Type Version Usage
OMS_StdQueueInput Container, Type Definition 0.0.0.4 OMS_Types.ini; OMS_LocalTypes.ini; OMSStart.seq No comment
So here I would assume, that the type OMS_StdQueueInput is defined in OMS_Types.ini and used/referenced in OMS_LocalTypes.ini and OMSStart.seq. Is that correct?
Regards,
Peter
Solved!
Go to Solution.

By INI file do you mean a TestStand Type Palette File?
A new feature was added to TestStand (in 4.1 I think so you should have it) that allows you to control when automatic conflict resolution (choosing the highest version of a type silently) occurs. The setting is located on the File tab of the Station Options dialog and is called "Allow Automatic Type Conflict Resolution". In general, I recommend changing it to the slightly more restrictive setting of "Only If a Type Palette File has the Higher Version" because this will get rid of the possibility of automatic conflict resolution when opening two sequence files with different versions of a type when the type does not exist in a type palette file. But if your type will always be in a type palette file then the default setting is fine.
First, some background information.
Automatic Type Conflict Resolution - This occurs when a file is opened whose type is different from the version already loaded into memory, and the criteria for automatic resolution is met (i.e. the station option setting allows it, neither verison of the type is marked as modified, and the different versions of the type have different version numbers). When automatic resolution occurs TestStand automatically chooses the version of the type with the highest version number.
Let me know if you want me to explain other terms.
What I'd recommend for type management:
1) Create a type palette file for your standard types. Make sure all deployed and development systems are using/loading this type palette file. If you need more details on how to do this please let us know.
2) Control updates to these types using a source code control system to control updating of the type palette file(s). Ideally, only one person should be editing a type palette file at a time. Source code control systems can be used to enforce this.
3) Let your developers know that they should only edit types in the type palette files and not in individual sequence files.
4) Try to make all changes to your types and substep code backwards compatible so that old sequences will continue to work with newer versions of the types. If you have to break backwards compatibility, consider creating a new type instead and use the new type from now on, but leave the old type there for backwards compatibility (you can use flags to hide the old version of the types from the insert menu if needed).
If you use a type palette file in this way I think you will get something close to what you are asking for. With the default setting for "Allow Automatic Type Conflict Resolution", if all of your TestStand systems are loading your standard type palette files then you will either get the version in the type palette file or your will get a type conflict dialog if the version in the sequence file is newer. There will be no possibility of silently using a version other than the one in the type palette file. Is this sufficient for your needs or are you looking for something different. If you are looking for something different please let us know the specific behavior you require.
Hope this helps,
-Doug

Use of "Open FPGA VI Reference" function --- Build Specification vs VI vs Bitfile

When using the "Open FPGA VI Reference" function in a LV2012 cRIO application, there are 3 options: Build Specification, VI, or Bitfile. What would be the reasons for selecting one over the others? Does it affect the resulting startup.rtexe when the cRIO application is built? I searched through the help and in these forums, but I don't see criteria for selecting one over the others; maybe I missed it.

Hello Chris,
Apologies in advance for a long reply.
The reference method won't change the functionality of your rtexe.exe. They all end up dropping a bitstream, based on a bitfile, onto the cRIO's FPGA.
To a degree, the method used to reference the FPGA code is a matter of taste, but there are situations where one method is better suited than the others.
Reference by VI:
Setting the configuration options to open reference by VI is helpful during development when you are making changes to an FPGA VI often and building/testing using the same spec. When this option is used, a bitfile is selected based on the default build specification for the project. A project may have only one default build specification. You can make any build the default by checking the option under the Source Files category in the build properties. The default build is indicated in the project explorer by the green box around the builds icon.
Reference by Bitfile:
This option references a bitfile directly. Through the configuration window, you can select one specific bitfile to open a reference to (this is not dynamic and does not change unless you physically go make a change to that path). If you're using this method, it helps to give your bitfiles more meaningful names than the ones that are automatically generated by LabVIEW. When you run subsequent compilations off of the same build specification and do not change the bitfile nname or path in the build configuration, the old bitfile is overwritten and replaced with the new one. When you are using this option, it is critical that you keep up with which bitfile is the one you want to be using. There is an option now that will help alleviate any problems referencing by bitfile through the Open FPGA VI Reference function. There is a new VI called Open Dynamic Bitfile Reference. It is typically used when you want to chose a specific bitfile to load depending on something in your host code (a configuration option etc) - but it allows you to dynamically reference a bitfile on the block diagram by path.
Referency by Build Specification:
This option is good for when you want to always use a bitfile that is associated with/compiled with the same build configuration. Say you have two options for top level FPGA VIs in your project (each with its own build spec). Both of these VIs have the same interface (read/write controls, DMA) but they run different algorithms or something. This is nice because you can easily switch your host application between them by picking the build spec associated with the FPGA VI you want to use. In this type of sutation, referencing by VI is no good because you can only have on default build spec.
cheers.
Matthew H.
Applications Engineer
National Instruments

JAXB compiler error : Complex Type Definition Representation Error

Hi,
I have a problem when I try to generate Java classes for the XML Digital Signature schema along with the XAdES extension. Apparently, we got an XML validation issue when the XAdES schema is parsed.
Here is the xjc tool ouput :
[ERROR] src-ct.1: Complex Type Definition Representation Error for type 'IdentifierType'. When complexContent is used, the base type must be a complexType.
line 33 of XAdES.xsd
[ERROR] src-ct.1: Complex Type Definition Representation Error for type 'EncapsulatedPKIDataType'. When complexContent is used, the base type must be a complexType.
line 57 of XAdES.xsdNow these are the schema lines from XAdES.xsd that cause the problem :
<xsd:complexType name="IdentifierType">
<xsd:complexContent>
    <xsd:extension base="xsd:anyURI">
      <xsd:attribute name="Qualifier" type="QualifierType" use="optional"/>
    </xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="EncapsulatedPKIDataType">
<xsd:complexContent>
    <xsd:extension base="xsd:base64Binary">
      <xsd:attribute name="Id" type="xsd:ID" use="optional"/>
    </xsd:extension>
</xsd:complexContent>
</xsd:complexType>The most disturbing thing is that those two schemas I used (e.g. xmldsig-core-schema.xsd and XAdES.xsd) come directly from the W3C, so they should be fully compliant to the XML schema spec, shouldn't they ?
Moreover, I tried to validate these two schemas with XML Spy 4.3 and the problem occurs in slightly different way. In fact, the <xsd:complexContent> tags are replaced silently by XML Spy with <xsd:simpleContent> tags in order to validate the schema. So XML Spy seems to have a problem too with these complex type definitions. Besides, if I replace the <xsd:complexContent> tags the same way as XML Spy does, and if I run again the JAXB compiler, it works fine...
Does anyone have any knowledge about this issue ? I'd like very much to hear about anyone who has experienced or better solved the same kind of issue.
By the way, here is the version of JAXB that I use :
xjc version "1.0.2-b15-fcs"
JavaTM Architecture for XML Binding(JAXB) Reference Implementation, (build 1.0.2-b15-fcs)Any help appreciated.
Thanks,
Gregory

<xsd:extension base="xsd:anyURI">
<xsd:extension base="xsd:base64Binary">
The base attribute of the xs:extension elements shoule refer to a complexType.
For example,
<xs:complexType name="complexTypeA">
</xs:complexType>
<xsd:complexType name="IdentifierType">
<xsd:complexContent>
<xsd:extension base="complexTypeA">
<xsd:attribute name="Qualifier" type="QualifierType" use="optional"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

Problem with deploying FPGA host VIs using TestStand deployment utility

I am using a PCI-7831R FPGA to control an automated test fixture. I have several host VI's that I am calling from TestStand (4.2.1) in order to control the 7831R. The host VI's that TestStand calls are setup as sub-VI's and are used for various things such as opening an FPGA reference (which is bound to a strict type def), downloading and executing the files on the 7831R, reading writing to controls, and finally closing the reference. In the sequence file, I am passing the reference values as a file global so that the host sub-VI's can communicate correctly. I have all functionality working correctly in TestStand on my development PC. When I go to deploy this to a production PC, I get errors when the sequence file trys to load the first host VI. The error basically states that the VI is broken - try to open and run it (which I can't because I have no development license on the production PC). I am currently trying to deploy this to another development PC to see if I can track down where the VI might be breaking.
I have included the lvbitx and strict type def control that the host subVI's reference in my deployment files. I can't think of anything that I might be missing. Is there any good documentation on exactly which files I need to include in the deployment when using FPGA Host VIs (the TestStand reference manual is pretty vague at best)? It seems that any documentation that I read says the TestStand deployment utility will analyze all VI dependencies (other than shared variables). On a side question, is the strict type def considered a shared variable?
Has anyone successfully deployed a sequence that calls host VI's? Any help would be greatly appreciated. If any of the above needs further clarification please ask away and I will be happy to give more details.
Thanks,
Mike

Hi hawkstringer
Do you encounter this problem using a deployed version of your code? Note that the subject of this topic is about deploying an FPGA application.
I forgot I posted here, in the mean time I've managed to deploy my application. I think my problem was solved when I included all necessary drivers and components (but I'm not absolutely sure). I included the following:
NI IVI Compliance Package
NI FlexRIO
NI PXI Platform Services Configuration Support
NI R Series Multifunction RIO
NI DAQmx Core Runtime
NI DAQmx MAX Configuration Support
NI RIO
Good luck!

Host reference in workflow cannot be resolved.

Hi,
I am authoring a SNMP MP for my devices and I am finding difficulty in creating Perf View. I have all the discovery working and but in my performance view, I am getting data in micro seconds but I want to display it in milli seconds so I am using:
<DataSource ID="DS" TypeID="NetworkMonitoring!System.NetworkManagement.ComputedPerfProvider.Division">
in my Rule but I am getting following error in Event View and my workflow gets unloaded everytime:
Host reference in workflow "MyCluster.NetworkDevice.ClusterLatency.Rule", running for instance "QTFCE522600663-1" with id:"{82890687-8C36-D008-0CED-329BBBE7091E}" cannot be resolved. Workflow will not be loaded. Management group
"SCOMLAB01"
I have also tried with "System.NetworkManagement.ComputedPerfProvider" but result remains the same. I am referring these links:
http://msdn.microsoft.com/en-us/library/jj130485.aspx
http://msdn.microsoft.com/en-us/library/jj129798.aspx
My rule definition:
<Rule ID="Cluster.NetworkDevice.StoragePoolLatency.Rule" Target=".NetworkDevice.StoragePool" Enabled="true" ConfirmDelivery="false" Remotable="true" Priority="Normal" DiscardLevel="100">
<Category>PerformanceCollection</Category>
<DataSources>
<DataSource ID="DS" TypeID="NetworkMonitoring!System.NetworkManagement.ComputedPerfProvider.Division">
<Interval>300</Interval>
<NoOfRetries>3</NoOfRetries>
<Timeout>500</Timeout>
<SnmpVarBinds>
<SnmpVarBind>
<OID>.1.3.6.1.4.1.41263.7.1.7.$Target/Property[Type='SNL!System.NetworkManagement.LogicalDevice']/Index$</OID>
<Syntax>0</Syntax>
<Value VariantType="8" />
</SnmpVarBind>
</SnmpVarBinds>
<Numerator>
<XPathQuery Type="Double">SnmpVarBinds/SnmpVarBind[OID=".1.3.6.1.4.1.41263.7.1.7.$Target/Property[Type='SNL!System.NetworkManagement.LogicalDevice']/Index$"]/Value</XPathQuery>
</Numerator>
<Denominator>
<Value>1000</Value>
</Denominator>
<DefaultValue>0.0</DefaultValue>
<ObjectName>$Target/Property[Type='.NetworkDevice.StoragePool']/StoragePoolName$</ObjectName>
<CounterName>Storage Pool Latency-$Target/Property[Type="SNL!System.NetworkManagement.LogicalDevice"]/Index$</CounterName>
</DataSource>
</DataSources>
<ConditionDetection ID="CD" TypeID="Perf!System.Performance.OptimizedCollectionFilter">
<Tolerance>10</Tolerance>
<ToleranceType>Percentage</ToleranceType>
<MaximumSampleSeparation>6</MaximumSampleSeparation>
<SamplingPeriodInSeconds>300</SamplingPeriodInSeconds>
</ConditionDetection>
<WriteActions>
<WriteAction ID="CollectToDB" TypeID="SC!Microsoft.SystemCenter.CollectPerformanceData" />
<WriteAction ID="CollectToDW" TypeID="MSDL!Microsoft.SystemCenter.DataWarehouse.PublishPerformanceData" />
</WriteActions>
</Rule>
Any suggestions?
Regards,
Ravi

Hi,
The custom rule created may have issues with a target either a wrong or typo
in the target . Check the blog which talks about the error you are seeing.
http://blogs.msdn.com/b/davidlai/archive/2008/08/27/host-or-property-references.aspx
Regards,
Yan Li
Regards, Yan Li

"JCA Binding execute of Reference operation 'Write' failed due to: Translation Error.

Hi, i am trying to read a comma delimited file using an inbound file adapter, i have used a mediator to route records to the outbound file adapter.My input.txt file contains 10 records as Fname,Lname.I have used native format builder to generate xsd. To achieve transformation,in the mediator i have mapped only the Fname from source to traget using a for-each loop.I am trying to publish records in the batches of 2 so i have configured inbound file adapter accordingly.My inbound file adapter reads the first two records and the same is visible at the em console mediator instance(payload), i am even able to see the first two records being transformed in the transformed payload in the mediator instance detail but at the outbound file adapter i get an error saying :
Error during invoking 1-way operation "Write" on target service "writeFile"
Exception occured when binding was invoked. Exception occured during invocation of JCA binding: "JCA Binding execute of Reference operation 'Write' failed due to: Translation Error. Translation Error. Error while translating message to native format. Please make sure that the payload for the outbound interaction conforms to the schema. ". The invoked JCA adapter raised a resource exception. Please examine the above error message carefully to determine a resolution.
When i map both the Fname and Lname in the xsl map file i get the output.But i only need one field at the outfile i:e either the Fname or the Lname.
Given below are the details of the interface:
My Interface Flow:       InboundFileAdapter--------ReadsFile------->Medaitor------Transformation----->OutboundFileAdapter-----writesFile
Input Payload(comma delimited text file) as,
Brad,Pitt
Keanu,Reaves
Martin,Lawrance
Johnny,Depp
etc
etc
Schema definition for payload:
<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
            xmlns:tns="http://TargetNamespace.com/readFile"
            targetNamespace="http://TargetNamespace.com/readFile"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified"
            nxsd:version="NXSD"
            nxsd:stream="chars"
            nxsd:encoding="US-ASCII">
<xsd:element name="Root-Element">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="Employee" minOccurs="1" maxOccurs="unbounded">
          <xsd:complexType>
            <xsd:sequence>
              <xsd:element name="Fname" type="xsd:string" nxsd:style="terminated" nxsd:terminatedBy="," nxsd:quotedBy=""" />
              <xsd:element name="Lname" type="xsd:string" nxsd:style="terminated" nxsd:terminatedBy="${eol}" nxsd:quotedBy=""" />
            </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
      </xsd:sequence>
    </xsd:complexType>
</xsd:element>
</xsd:schema>
XSL Map:
<xsl:template match="/">
    <imp1:Root-Element>
      <xsl:for-each select="/imp1:Root-Element/imp1:Employee">
        <imp1:Employee>
          <imp1:Lname>
            <xsl:value-of select="imp1:Lname"/>
          </imp1:Lname>
        </imp1:Employee>
      </xsl:for-each>
    </imp1:Root-Element>
</xsl:template>
</xsl:stylesheet>
Please help me with the above mentioned error and if above transformation is possible using a mediator instead of BPEL
Regards,
Saif

Hi Saif, Are you using the same xsd for the outbound (write) file adapter as well? In that case, you may need to map both the names (Fname and Lname) but leave the name which you do not want to be written to the file as an empty text. For example, if you would need to map only the Lname, but not the Fname, the xsl will be like,
<xsl:template match="/">
    <imp1:Root-Element>
      <xsl:for-each select="/imp1:Root-Element/imp1:Employee">
        <imp1:Employee>
          <imp1:Fname>
          <xsl:text disable-output-escaping="no"></xsl:text>
          </imp1:Fname>
          <imp1:Lname>
            <xsl:value-of select="imp1:Lname"/>
          </imp1:Lname>
        </imp1:Employee>
      </xsl:for-each>
    </imp1:Root-Element>
</xsl:template>
</xsl:stylesheet>
Another option is to have a separate xsd with only one element (Fname or Lname) for the outbound file adapter, in which case you would need to map only one field.

Control Value:Set [Variant] Method - how can i use this with strict type definitions?

I want to pass default values to a strict type definition from a mainVI to a subVI, but I'm not allowed to use the "Control Valueet [Variant] Method" invoke node to do it. How else can I achieve this?
thanks,
Z

Hi Z,
If you use strict type defintion references you can use Call by reference Node. Depending on the connector pane for the subvi which is referenced you just wire your data to the corresponding terminals. I attach an easy example which dynamically opens and writes to an arbitary number of a template.
Hope it helps
Pelle S
District Sales Manager
National Instruments Sweden
Attachments:
Call by reference node.zip ‏20 KB

Default billing type for delivery without reference (Delivery Type LO)

Hi,
We have copied delivery type LO to ZLO, so by default Copy control got maintained in VTFL.
But when we do billing for this delivery in VF01 the system is picking F2 as billing type automatically.
The system is not picking the defined billing type (ZF2- copy of F2) for which we have maintained copy control in VTFL
The system is accepting ZLO->F2 but not accepting ZLO->ZF2
Rgs,
Vipin

Hi,
When you have a delivery document created without reference to a sales order, the system uses a defualt order type. Check that in the delivery document type definition ( LO ), the default order type is DL. If you look at the definition of DL in VOV8, the billing document type defined in F2. This is what the system uses as the proposed billing document type. If you want the system to propose ZF2, create a copy of DL and assign that to ZLO as the default order type. Change the billing document type to ZF2 in the sales order definition and you will be able to propose ZF2.
Hope this helps.

Close FPGA VI Reference breaks when moving project...

I created a cRIO project with an FPGA target, and assigned the output of Open FPGA Reference to an indicator.
When I moved the project to a different computer, the wire to the indicator broke, so I selected "Bind to Typedef..." on the Open FPGA Reference node, replaced the indicator, reconnected all the local variables from old indicator to the new one, and deleted the old one. So far so good.
But now, when I move the project to a different computer, the wire to the Close FPGA VI Reference breaks.
If I delete and replace the broken wire whenever I open the project on the new computer, everything's fine. Am I stuck with that? It could be worse, I guess, but I'd like to fix this for real. Any suggestions?
Thanks in advance.

Hi Ron,
I do not believe that there are any other workarounds for this behavior. I've been attempting to fix this myself in another way, but it seems that due to the simplistic nature of the close reference vi, it is not possible to go about this in another way when distributing applications. I will try to see if we can make a product suggestion for this in the future releases of the software.

Delay when applying large, hierarchical type definitions

Hello,
I searched around using various terms, but couldn't readily find posts on what I'm experiencing.
Has anyone else noticed huge delays when applying large, hierarchical type definitions? I've got about a dozen nested type definitions of clusters, each containing anywhere from 10 to 100 controls, and they're used throughout a large application. When I open any member of that hierarchy, make a small change, and hit apply, I see the hourglass (spinning ring of death in Vista/7) for a good two to five minutes.
A short term workaround has been to close all dependent VIs and typedefs, and then make an isolated edit. Then, if I open the whole application again, I see some compiling taking place, but it seems to take a lot less time than when the whole application is open.
I could have sworn that I read a discussion by some others commiserating about this at some point, but now I can't find it.
Has this been addressed, and has anyone heard if there's any development effort to improve this?
Thanks,
Jim

Hi Fred,
Thanks for getting back to me on this.
> You could use more specific typedefs and not a massive one to pass data through VIs.
It's funny, I've actually adopted using larger typdefs in the last year or two for architectural simplicity, and that's when I've noticed this becoming a problem. In fact, for what it's worth, right now I'm using a data reference to store the "data dictionary" (large typedef) but that doesn't really help the issue.
From an architectural sense, it makes things easier for me because I have much fewer wires to pass around most of my data is in one place.
> Or you could pass a queue reference to the subVIs and have the queue be made of of elements that are the large type definition.
Actually, I'm using a data reference right now, which is somewhat analogous to what you're suggesting. (Maybe not? I also use queues and notifiers depending on the situation.) I haven't really seen this technique help the issue; I'm still noticing the large delays, but only when editing the typedefs.
The only way I've really found relief is to separate the large typedef into smaller ones and pass them around separately. This is kind of a pain because it means I have many more references to data structures to keep track of.
> If this is causing major problems, let me know, and I'll pass along your concerns to R&D.
Actually, if I'm to be honest, it really is starting to become a hassle. I hit apply and end up working on something else for a few minutes while the compiler chugs away. I'd be really interested in an improvement in this area. If it makes things easier, I can discuss this via email and upload an application I'm working on as an example. (Multiple large apps I'm working on exhibit this behavior)
Thanks again for your help.
Regards,
Jim

[Application Builder] What does "disconnect type definitions" accomplish?

Hi all,
Inside the Build Specification properties, there's an option "Additional Exclusions" -> "Disconnect type definitions".
The only piece of documentation I've found is at http://zone.ni.com/reference/en-XX/help/371361H-01/lvdialog/additional_exclusions_sd/ but it's not very descriptive. It suggests that disconnecting might cause front panel objects to be displayed incorrectly. Is this the case?
What does this option do? Its existence suggests to me that type definition info persists inside a compiled LabVIEW application, unless we choose to disconnect them.
When should I disconnect, and when should I leave type definitions alone?
Thanks in advance!

I only know one use case for this option: when application builder throws errors during builds or exe itself doesnt work.
One reason to use it is when you use Network Shared Variables with typedefs - I recall problems with shared variables not founding theirs typedefs after build. This option also happens to fix more exotic problems - see LV2014 bug fixes:
426523
A specific large project fails to build with a GenIL error and then crashes if you do not select Disconnect Type Defs
So, other than to workaround app builder problems - I don't know any other reason to mark Disconnect Type Definitions.

Bind FPGA host reference to type definition in labVIEW 2012 crashes labVIEW

Similar Messages

Maybe you are looking for