Source distribution with FPGA support

I am trying to deploy a series of VIs which interact with FPGAs (PXIe-7966 based). When I run my RT vi's in development mode, the automatic deployment includes many vis such as:
Deploying niLvFpgaWhatHappensToTopLevelVI.ctl(already deployed)
Deploying niFpgaNodeNameForErrorReporting.ctl(already deployed)
Deploying niLvFpgaFormatErrorSource.vi(already deployed)
Deploying nirviWhatTheDeviceIsDoing.ctl(already deployed)
Deploying niFpgaHostInterfaceSession.ctl(already deployed)
Deploying nirio_resource_hc.ctl(already deployed)
Deploying nirio_resource_hc.ctl(already deployed)
Deploying niLvFpgaFormatErrorSource.vi(already deployed)
Deploying niLvFpgaErrorClusterFromErrorCode.vi(already deployed)
Deploying nirviErrorClusterFromErrorCode.vi(already deployed)
Deploying niFpgaNodeNameForErrorReporting.ctl(already deployed)
Deploying niLvFpgaWhatHappensToTopLevelVI.ctl(already deployed)
Deploying niLvFpgaFormatErrorSource.vi(already deployed)
Deploying niLvFpgaErrorClusterFromErrorCode.vi(already deployed)
Deploying nirviErrorClusterFromErrorCode.vi(already deployed)
Deploying niFpgaNodeNameForErrorReporting.ctl(already deployed)
Deploying niLvFpgaAdjustHostInterfaceError.vi(already deployed)
Deploying niLvFpgaWhatHappensToTopLevelVI.ctl(already deployed)
Deploying niLvFpgaAdjustHostInterfaceError.vi(already deployed)
Deploying niLvFpgaFormatErrorSource.vi(already deployed)
Deploying niLvFpgaAdjustHostInterfaceError.vi(already deployed)
Deploying niFpgaDynamicAddResources.vi(already deployed)
Deploying niLvFpga_Close_Dynamic.vi(already deployed)
Deploying niLvFpga_Open_PXIe-7966R.vi(already deployed)
None of these show as dependencies though on the RT target project. When I try to create a source distribution, I can't seem to get these deployed. My VIs (When called by reference or invoke) thus fail to start (Error 1003). I'm assuming it's because the source distribution didn't include the above items.
How then can I include the FPGA and RIO vi's in the source distribution? Including vi.lib, instr, and user (From the source distribution properties) doesn't appear to pull in any of these. Including NiFpgaLv.dll doesn't seem to help either. There's no other source distribution options that seem to address FPGA or RIO inclusion.
Thanks,
Robert

Hi Robert,
After doing a bit of research, it looks like this exact issue - down to the 1003 error code and behavior with vi.lib - was reported earlier this year. Apparently it only occurs on Pharlap OS (which corresponds to your PXI RT target). R&D has been notified, and the current target version for fix is LV 2015. The listed workaround is simply to FTP the files to the RT target as you are doing. Let us know if you have any further questions!
Regards,
David R
Applications Engineer
National Instruments

Similar Messages

LV 2009 Source Distribution with Broken VIs

It looks like LV 2009 has made another "improvement" to an edge case that has caught us off-guard. This is admittedly not a huge issue for us to deal with, but I thought it might be worth getting some more feedback and seeing if anyone else has comments as to whether this change is for the better or not.
   We have a plug-in architecture in which we compile a main program, then use a Source Distribution to create directories of plug-in modules that the main program calls dynamically. We can send out updated or new plug-ins this way without having to recompile or redistribute the main program.
   For each module, I have a "List" VI, similar to a driver "Tree" VI in NI drivers. It contains all the top-level VIs that that module uses. Many are called dynamically, so by loading this List VI into memory, you can be sure that all parts of the module are in memory. It also simplifies the build script, since if you include the List in the Source Distribution, it automatically includes all the top-level and dynamically called VIs you need in the distribution.
   The List VI is not executable. I add a broken wire on purpose, since this VI is not meant to be run. In addition, if any of the VI's on the diagram have "Required" inputs, that breaks the List VI.
    In LV 8.6 and before, we could build a source distribution with this broken VI. In LV 2009, the source distribution build fails with a message about not being able to save a file. If we "fix" the List VI, it works.
   So it appears that in LV 2009, NI "fixed" the source distribution to only work with executable VIs. It's not too hard for us to accomodate this, by fixing our List VIs. But I wonder if there aren't other edge cases where this "fix" is not such ideal behavior. Might you not want to be able to make a source distribution of source code that isn't finished and hence isn't executable?
   (Oh - another subtlety that may be relevant - we remove the diagram as a security measure. Maybe you can't remove the diagram from a broken VI? Though it did seem to work in 8.6...)
DaveT
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
There are 10 kinds of people: those who understand binary, and those who don't.

Sorry - false alarm. The difference did turn out to be that I had checked "Remove Diagram" for the broken VI, not just for the good VIs. You apparently can't remove the diagram from a broken VI since it can't compile it. In our 8.6 distributions, we didn't check that box for the broken VI. In 2009, I was checking that box for all VIs.
DaveT
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
There are 10 kinds of people: those who understand binary, and those who don't.

App. with source distributions work on XP pro but dont work on XP home

Hello!
We built application and a number of source distributions driving from apllication. It works fine on PC with Windows XP professional, but return error when we try to run it on XP home edition. We test it on 6 PCs. How to use application on XP home?
PS LV 8.5

Since you consistently cannot get this to work under XP Home, then clearly you must be using something in the OS that exists in XP Pro, but does not in XP Home. So, the question is what? You'd need to tell us more about what your application does in order to determine that.

Source distribution overwrite vi

Hi!
I'm making a source distribution for my dynamically called VI's. These VIs operates on classes. I would like make one Distribution, that contains all called vis. My problem is, I've serveral overwrite class methods, with equal names as well. But when I make a preview, the distribution separates these vis, because they have similar names.
What is the common trick or solution for this problem?
Thanks in advance!
+++ In God we believe, in Trance we Trust +++
[Hungary]
Solved!
Go to Solution.

Hi Durnek,
1) dynamically loaded classes has to be added to always included section of build specification.
Add the classes as “Always Included” in the Source Files page of the Executable Properties dialog box
Place those classes into a directory next to the executable so that the relative path is still accurate. Follow these steps migrate the files along with the executable:
Create new destination folders in the Destinations page of the Executable Properties dialog. These destination folders must have the same relative path to the executable as the source class did to the top-level VI.
Navigate to the Source File Settings page of the Executable Properties dialog.
Browse through the Project Files tree and modify the Destination settings so that each file is migrated to the appropriate destination directory.
Another solution is to add unused object anywhere to block diagram. Application builder will find the class then.
2) In the Additional Exclusions page of the Executable Properties dialog, remove the checkmark from the Modify project library file after removing unused members checkbox.
3) VIs with the same name inside executable are supported from LV 2009+, so the new layout has to be selected. Otherwise you will have to create separate llb or folder for each class.
If you want to discuss more I would need to see your structure of the files. So you can either upload it in the forum or send it [email protected] You can put my name into subject.
Regards,
Jiri Keprt
NI EE Czech Republic
Certified LabVIEW Architect & Certified TestStand Architect

Error 6 during Build Specification of My Source Distribution in Project explorer

While trying to convert a LV 8.0 application into a project file I get an Error 6. Message as Follows:
Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:
Error 6 occurred at ABAPI Dist Chg and Save VIs.vi -> ABAPI Dist Build LLB Image.vi -> ABAPI Copy Files and Apply Settings.vi -> SDBEP_Invoke_Build_Engine.vi -> SDBUIP_Build_Invoke.vi -> SDBUIP_Build_Invoke.vi.ProxyCaller
Possible reason(s):
LabVIEW: Generic file I/O error.
NI-488: I/O operation aborted.
The error referenced a vi from a third-party labview driver for Iotech hardware.
Could the path be too long?

JT1958,
These types of errors are a bit tricky to diagnose. I would try the following, in order of easiness:
1) Mass compile your project by doing a <Ctrl-Shift-Run> on your top level VI to make sure your project is linked correctly. Sometimes if there is a bad VI reference somewhere you can have these types of problems.
2) The path being to long most likely isn't the issue, but if you suspect the IOTech driver, you may try taking it out of your code and see if that allows you to build a source distribution. If that works, try creating a simple project that contains VIs from the driver and see if you can get it to build. The point is to narrow down what specifically is causing the build to fail.
3) You can try to build this in LabVIEW 8.2 as some improvements to the source distribution builder were made.
Doug M
Applications Engineer
National Instruments
For those unfamiliar with NBC's The Office, my icon is NOT a picture of me

A source distribution created in 32-bit LabView 2009 says that VIs aren't executable when opened in 64-bit LabView 2009. How do I run the main VIs?

A source distribution was made for a VI using 32-bit LabView 2009. The distribution was verified to work on another machine that ran 32-bit LabView 2009. However, when opened on a 64-bit LabView 2009, the VI was broken as indicated by the attached error message. How do I make the VI executable?
Solved!
Go to Solution.
Attachments:
source dist error.JPG ‏70 KB

Seems you have a problem with the installation of the Advanced Analysis Library (AAL) or the Intel Math Kernel Library that is used by the AAL on that 64 bit machine. Can't say for sure if these are already supported on 64 bit LabVIEW. At least a repair installation of LabVIEW seems to be in place.
The other error is from the HSD component not working. Again I can't say if this should even work on 64 bit LabVIEW. If it should a repair installation should be most probably done.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Desktop Application Distribution with Files in ZFS 6.5

I'm trying to do a Desktop Application Distribution with a simple NAL and
can not get the files associated with the NAL to copy to the subscriber
server. I am using ZFS 6.5 SP1. I am using a mapped drive letter in the NAL
and have chosen "Keep the same source paths for the replicated objects" in
the distribution. I also have defined a variable in the service location
package as 'drive letter'='volume name' and associated this policy with the
container that the distributor and subscriber are in. I checked the box in
the subscriber's variable property to use this policy. The documentation
also says to use a SOURCE_PATH macro and 'Package Source List' to define the
mapped drive but I am unsure how those should be defined. Should they be
just a drive letter or the entire path to the applications files? Also, I'm
not sure if anything else is need to make this work.
Any Ideas of what I might need to do to get this to work?
Thanks!
John

Graham,
Thanks for the suggestions. I thought this type of distribution still
worked in Zen 6.5. It used to work great for us under Zen 6 and I hadn't
seen anything that said it didn't work with Zen 6.5. We'll probably use a
second distribution for the short term and then try one of your other
suggestions or see if we can find another way that works better.
John
"Graham Mitchell" <[email protected]> wrote in message
news:[email protected]...
> Depends on the kind of app you're trying to distribute... If it's a simple
> one ie you run something like setup.exe in a directory of files, then the
> files will NOT replicate out. If it's an MSI you're trying to distribute,
> even one with a file of support files (like say office), these WILL
> replicate out. Unfortunately, this is working as designed. You'll also
> find
> that file rights are NOT copied out yet either...
>
> There are a couple of ways round it... One is to do a seperate file
> distribution object to copy out the needed files/directories - I think
> this
> is messy, as you need to have 2 distributions for each application.
>
> You can use the repackager that comes with Zen to repackage the files into
> an MSI and use that to install the application on the workstations. This
> will replicate out fine.
>
> Another way, and they way we're starting to look at doing it, since it
> resolves some issues with workstation associated installs, is to have the
> application object copy all the files from the server onto the local
> workstation and run the install from there. To do that, you need a
> SOURCE_PATH pointing to the server distribution point, and another
> variable
> (we call it INSTALL_PATH) pointing to somewhere on the local workstation
> (C:\Install\MS\Office2k3). We then run the install from this location.
> Since
> all the files are mentioned in the distribution portion of the application
> object, when we distribute the application out to the remote servers, all
> the required files are copied out too.
>
> To do this manually for more than a couple of files is a royal pain in the
> ass... however, there's a makeaxt.pl PERL script available on
> coolsolutions
> that does most of the donkey work for you - give it the source and
> destination directories, and it will make an AXT file you can import. The
> only thing we have to do is to hit it with an editor, and replace the
> absolute paths (C:\Install\MS\Office2k3) with the variable we want to use
> (INSTALL_PATH).
>
> We're actually doing this, combined with the MSIs at the moment, since
> we're
> doing an image/application refresh for WinXPSP2, so we're rebuilding all
> the
> apps this way.
>
> If anyone is doing it differently, or has other suggestions, I'd love to
> hear...
>
>
>
> Graham
>
>
>
> "John Malinowski" <[email protected]> wrote in message
> news:[email protected]...
>> I'm trying to do a Desktop Application Distribution with a simple NAL and
>> can not get the files associated with the NAL to copy to the subscriber
>> server. I am using ZFS 6.5 SP1. I am using a mapped drive letter in the
> NAL
>> and have chosen "Keep the same source paths for the replicated objects"
>> in
>> the distribution. I also have defined a variable in the service
>> location
>> package as 'drive letter'='volume name' and associated this policy with
> the
>> container that the distributor and subscriber are in. I checked the box
> in
>> the subscriber's variable property to use this policy. The documentation
>> also says to use a SOURCE_PATH macro and 'Package Source List' to define
> the
>> mapped drive but I am unsure how those should be defined. Should they be
>> just a drive letter or the entire path to the applications files? Also,
> I'm
>> not sure if anything else is need to make this work.
>>
>> Any Ideas of what I might need to do to get this to work?
>>
>> Thanks!
>>
>> John
>>
>>
>
>

Recompiling Postfix with MySQL support

It took me so much time that I think the following explanation could be useful.
Goal: Recompiling Postfix with MySQL support without losing compatibility with Apple administration tools
Original instructions from webutilities:
downloaded the postfix from the Darwin Sources here:
http://www.opensource.apple.com/darwinsource/10.4.3/
Thx to pterobyte
i created the directorys
/src
i put the source in there
/src/postfix-144
and
/AppleInternal/Deverloper/Headers
i put the Sasl headers in there
/AppleInternal/Deverloper/Headers/sasl
then i modyfied the makefile in postfix-144
SRCROOT=
to
SRCROOT=/src/postfix-144
and
build :
echo "ENV = $(ENV)"
$(ENV) $(MAKE) -C $(SRCROOT)/$(PROJECT) makefiles OPT="-DBIND8COMPAT -DHAS_SSL -DUSESASLAUTH -D_APPLE_ \
-I/AppleInternal/Developer/Headers/sasl -framework DirectoryService $(CFLAGS)" \
AUXLIBS="-L/usr/lib -lssl -lsasl2.2.0.1 -lgssapi_krb5"
$(ENV) $(MAKE) -C $(SRCROOT)/$(PROJECT)
cd $(SRCROOT)/postfix/src/smtpstone && make all
to
build :
echo "ENV = $(ENV)"
$(ENV) $(MAKE) -C $(SRCROOT)/$(PROJECT) makefiles OPT="-DBIND8COMPAT -DHAS_SSL -DUSESASLAUTH -D_APPLE_ \
-I/AppleInternal/Developer/Headers/sasl -framework DirectoryService $(CFLAGS) -DHAS_MYSQL -I/usr/include/mysql" \
AUXLIBS="-L/usr/lib/sasl2 -lssl -lsasl2.2.0.1 -lgssapi_krb5 -L/usr/lib/mysql -lmysqlclient -lz -lm"
$(ENV) $(MAKE) -C $(SRCROOT)/$(PROJECT)
cd $(SRCROOT)/postfix/src/smtpstone && make all
then in the cli
cd /src/postfix-144
make build
cd postfix
i tryed to
make update
but it gave me
nothing to do back
so i made a backup of the postfix files
mv /usr/sbin/postfix /usr/sbin/postfix.bak
mv /usr/sbin/postfconf /usr/sbin/postfconf.bak
mv /usr/libexec/postfix /usr/libexec/postfix.bak
i moved
mv src/postfix/postfix /usr/sbin
mv src/postfconf/postfconf /usr/sbin
mv libexec /usr/libexec/postfix
Here is what I did not understand first:
1. SASL headers
These headers can be found in Apple's distribution of passwordserver_sasl-59.3 (http://www.opensource.apple.com/darwinsource/10.4.4/). Here is the list:
-rw-r--r-- 1 administ admin 5472 Sep 3 2002 exits.h
-rw-r--r-- 1 root wheel 3547 Apr 11 2005 gai.h
-rw-r--r-- 1 root wheel 1368 Apr 11 2005 hmac-md5.h
-rw-r--r-- 1 root wheel 1442 Apr 11 2005 md5.h
-rw-r--r-- 1 root wheel 1007 Apr 11 2005 md5global.h
-rw-r--r-- 1 root wheel 7273 Apr 11 2005 prop.h
-rw-r--r-- 1 root wheel 47906 Apr 11 2005 sasl.h
-rw-r--r-- 1 root wheel 30986 Apr 11 2005 saslplug.h
-rw-r--r-- 1 root wheel 2648 Apr 11 2005 saslutil.h
2. Postfix update
I did a "make build", then moved to /src/postfix-144/postfix and did a "make update". But it was not enough, I had to follow the instructions by manually copying the files (src/postfix/postfix, src/postfconf/postfconf, libexec).
And it seems to work fine!
David

It took me so much time that I think the following explanation could be useful.
Goal: Recompiling Postfix with MySQL support without losing compatibility with Apple administration tools
Original instructions from webutilities:
downloaded the postfix from the Darwin Sources here:
http://www.opensource.apple.com/darwinsource/10.4.3/
Thx to pterobyte
i created the directorys
/src
i put the source in there
/src/postfix-144
and
/AppleInternal/Deverloper/Headers
i put the Sasl headers in there
/AppleInternal/Deverloper/Headers/sasl
then i modyfied the makefile in postfix-144
SRCROOT=
to
SRCROOT=/src/postfix-144
and
build :
echo "ENV = $(ENV)"
$(ENV) $(MAKE) -C $(SRCROOT)/$(PROJECT) makefiles OPT="-DBIND8COMPAT -DHAS_SSL -DUSESASLAUTH -D_APPLE_ \
-I/AppleInternal/Developer/Headers/sasl -framework DirectoryService $(CFLAGS)" \
AUXLIBS="-L/usr/lib -lssl -lsasl2.2.0.1 -lgssapi_krb5"
$(ENV) $(MAKE) -C $(SRCROOT)/$(PROJECT)
cd $(SRCROOT)/postfix/src/smtpstone && make all
to
build :
echo "ENV = $(ENV)"
$(ENV) $(MAKE) -C $(SRCROOT)/$(PROJECT) makefiles OPT="-DBIND8COMPAT -DHAS_SSL -DUSESASLAUTH -D_APPLE_ \
-I/AppleInternal/Developer/Headers/sasl -framework DirectoryService $(CFLAGS) -DHAS_MYSQL -I/usr/include/mysql" \
AUXLIBS="-L/usr/lib/sasl2 -lssl -lsasl2.2.0.1 -lgssapi_krb5 -L/usr/lib/mysql -lmysqlclient -lz -lm"
$(ENV) $(MAKE) -C $(SRCROOT)/$(PROJECT)
cd $(SRCROOT)/postfix/src/smtpstone && make all
then in the cli
cd /src/postfix-144
make build
cd postfix
i tryed to
make update
but it gave me
nothing to do back
so i made a backup of the postfix files
mv /usr/sbin/postfix /usr/sbin/postfix.bak
mv /usr/sbin/postfconf /usr/sbin/postfconf.bak
mv /usr/libexec/postfix /usr/libexec/postfix.bak
i moved
mv src/postfix/postfix /usr/sbin
mv src/postfconf/postfconf /usr/sbin
mv libexec /usr/libexec/postfix
Here is what I did not understand first:
1. SASL headers
These headers can be found in Apple's distribution of passwordserver_sasl-59.3 (http://www.opensource.apple.com/darwinsource/10.4.4/). Here is the list:
-rw-r--r-- 1 administ admin 5472 Sep 3 2002 exits.h
-rw-r--r-- 1 root wheel 3547 Apr 11 2005 gai.h
-rw-r--r-- 1 root wheel 1368 Apr 11 2005 hmac-md5.h
-rw-r--r-- 1 root wheel 1442 Apr 11 2005 md5.h
-rw-r--r-- 1 root wheel 1007 Apr 11 2005 md5global.h
-rw-r--r-- 1 root wheel 7273 Apr 11 2005 prop.h
-rw-r--r-- 1 root wheel 47906 Apr 11 2005 sasl.h
-rw-r--r-- 1 root wheel 30986 Apr 11 2005 saslplug.h
-rw-r--r-- 1 root wheel 2648 Apr 11 2005 saslutil.h
2. Postfix update
I did a "make build", then moved to /src/postfix-144/postfix and did a "make update". But it was not enough, I had to follow the instructions by manually copying the files (src/postfix/postfix, src/postfconf/postfconf, libexec).
And it seems to work fine!
David

Using VI Server and Source Distribution on a cRIO breaks if there are bitfiles

Hello.
We have a project in LV 8.5 that runs on a 9014 cRIO. It uses some custom FPGA code to communicate with several modules. We are upgrading to LV 2010 SP1 and have run into a snag. Our plug in that loads the FPGA code does not load.
We use VI Server techniques to have a plug in architecture. The plug ins where distributed as executables or dlls, but they were used like LLBs. This is because back in 8.5 an exe or a dll was essentially a llb with some interface code tacked on.
Now in LV 2010 this is not an option. The contents of executables and dlls are not accesible with VI server Open Reference calls.
This leaves us two choices, Source Distribution and Packed Libraries. We are going with Source Distributions because our attempts to use packed libraries have failed. (I could explain, but frankly that is another issue.)
Source Distributions work for plugins that are not loading bitfiles to the FPGA. When the main code (our Framework) loads the plugin that would load the FPGA, it gets error 1003 at the Open VI Reference call. (This error says that the vi it is trying to open is broken.)
When we copy the plugin back from the cRIO and open it, the IDE looks for and cannot find the two bitfiles the VI uses. Presumably then, the RTE on the cRIO is failing to open the VI because it cannot find the bitfiles.
Various questions:
Do we need to copy the bitfiles over to the cRIO for the plugin to load, and if so, where? We already tried putting them in the LLB only to discover this is not allowed.
This is the second time we have tried to upgrade to 2010. Last time we did not have this problem, but other concerns pushed back the schedule and when we came back we decided to go with SP1. Does that make a difference? Or is there something crucial we did right the first time that we did not make proper notes on?
Please let me know if I have not explained anything. Thanks for any help!

Additionally, here is the section of code I am having trouble with...
Attachments:
Coercion Dots.JPG ‏67 KB

Dvi to hdmi with sound support

I was looking for a way to watch movies from my MBP (mid-2011 13") on a HD LCD TV, and I found an HDMI port in the back of the TV. I went to the Apple store and picked up a Kanex "Mini DisplayPort to HDMI Cable (with sound support)." The picture looks great, but there's no sound. Is there a switch I need to activate somewhere that turns on the sound for the DVI port? Do I need to set anything on the TV?

Try going to System Preferences > Sound and chose your TV as an output source. Also, go into Applications > Utilities > Audio MIDI Setup and in the left side of the window chose the output source. If these don't work then you may have a problem with your TV, it may not support audio from a HDMI cable. In that case you could use a Digital Optical Cable (TOSlink) with a 3.5mm adapter for the headphone jack of your Mac and plug that into your TV (if it has a Optical Output).

Error 7 occurred while building source distribution in labview 8

I can build exe file and installer for my project. But while trying to build source distribution i got an error. Error description is as follows:
Error 7 occurred at ABAPI Dist Report Read Link Info Error.vi -> ABAPI Dist Cmp Settings to Disk Hier.vi -> ABAPI Get Settings From File.vi -> SDBEP_Invoke_Build_Engine.vi -> SDBUIP_Build_Invoke.vi -> SDBUIP_Build_Invoke.vi.ProxyCaller
Possible reason(s):
LabVIEW: File not found. The file might have been moved or deleted, or the file path might be incorrectly formatted for the operating system. For example, use \ as path separators on Windows, : on Mac OS, and / on Linux.

Hi Andy,
FYI, initially part of this project was developed in LabVIEW 7.1 and now I have
converted all the project files to LabVIEW 8.0. This was done by mass compiling and
saving all the VIs.
It is possible for me to build source distribution for some other programs. But I got the error while building source distribution for my current project. Same error was generated even while previewing the source distribution. This project contains some dynamic VIs. I had included them under the dynamic VIs and support files while creating EXE file. While building source distribution, i got an error message saying that :
"Unable to generate preview. An included VI or one of its dependencies does not exist. Open all Startup/Exported/Dynamically called VIs, recompile them (Ctrl-Shift Click the run arrow), and save them to update their dependencies.
\\Source code\Controls\Tests\Battery Current Calibration\Battery Current Calibration1.ctl
<Call Chain>Error 7 occurred at ABAPI Dist Report Read Link Info Error.vi -> ABAPI Dist Cmp Settings to Disk Hier.vi -> ABAPI Get Settings From File.vi -> SDBEP_Invoke_Build_Engine_Preview.vi -> SDBUIP_Build_Rule_Editor.vi -> SDBUIP_Item_OnDoProperties.vi -> SDBUIP_Item_OnDoProperties.vi.ProxyCaller
Possible reason(s):
LabVIEW: File not found. The file might have been moved or deleted, or the file path might be incorrectly formatted for the operating system. For example, use \ as path separators on Windows, : on Mac OS, and / on Linux."
For this error I rename the control, relink it in the code, and save the VI. Now I got an error message indicating different control. I was totally confused by this behaviour. What is the problem? Why the problem occured? What procedure to follow to avoid these kind of errors in future? I would be thankful, if I can get answers for my questions.
Thanks in advance.
Ramasamy.

No permission to copy file (to NAS with AFP support) - extended attributes?

For certain files that I copy from one of my drives to the NAS here (Synology 206j), ever since upgrading to Snow Leopard, Finder's behaviour has changed. It will simply refuse to copy the file, stating that "The operation can’t be completed because you don’t have permission to access some of the items."
The source is an external USB drive in Mac OS Extended format, I do have full permissions on the files and in any case the drive is set to ignore ownership.
The target is, like most NASes, in EXT3 format. It's sharing via its own AFP implementation.
I'd have tried repairing permissions, but for whatever reason, it's greyed out on my external drives. Since then I've figured that it was probably not that anyway, which will become apparent:
I tried copying the file via the terminal and it actually worked, but also gave an error: "cp: myfile: could not copy extended attributes to /Volumes/media backup/myfile: Operation not permitted"
This suggests to me that, as expected, the target volume doesn't support extended attributes. But rather than popping up with the message that Leopard did (something along the lines of "your target volume doesn't support extended attributes so your file's metadata may be lost, do you wish to continue") it just aborts instead.
I'm not sure if this is a Snow Leopard problem or a change that Synology need to catch up with. A workaround is to compress the file to ZIP first.
Thought I'd mention it here before trying to report it as a bug somewhere. Anyone else having similar issues, either with a NAS or some other storage, in which case please specify?
Message was edited by: Cloudane

Thanks guys, yeah I've been monitoring the netatalk mailing list myself: they're onto the same problem, have come to the same conclusions about it being Extended Attributes and have much better proof of such than I
It looks like they're currently debating the best way to fix it (pretending to support EAs but sending them to a black hole being the quick and dirty way, but I suspect they'll go for implementation)
It'll be a while for sure, but the Synology guys are very good with Mac support so I'm sure they'll apply the update fairly quickly once the netatalk crew get something public. FWIW, I did detect a certain sense of urgency from the netatalk discussions.
Although it's essentially answered, I'll leave the question marked as unanswered in case Apple come up with a better one
Message was edited by: Cloudane

Getting error in building source distribution

While building source distribution, I am getting an error
Error copying files.
Source: ..\Program Files\National Instruments\LabVIEW 8.6\resource\visarc
Destination: D:\Chirag\builds\Arduino LLB\Arduino LLB\data\data\visarc
Librarian Path Location.vi
Error 1 occurred at AB_Destination.lvclass:Copy_File.vi -> AB_Source.lvclass:Copy_SourceItem.vi -> AB_Build.lvclass:Copy_Files.vi -> AB_Build.lvclass:Build.vi -> AB_Engine_Build.vi -> AB_Build_Invoke.vi -> AB_Build_Invoke.vi.ProxyCaller
Possible reason(s):
LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
=========================
NI-488: Command requires GPIB Controller to be Controller-In-Charge.
can someone please help me with this ??

Do you have multiple job servers in your environment? Did all the Job servers configured SMTP settings?

Is the labview 8.2 compatible with FPGA (altera) thats ordering code is DK-DSP-3C120N ?

is the labview 8.2 compatible with FPGA (altera) thats ordering code is DK-DSP-3C120N ?

Hey Mouath,
The FPGA module only supports the following:
Virtex-II 3000
Virtex-II 1000
Spartan-3 1000
Spartan-3 2000
Virtex-5 LX30
Virtex-5 LX50
Virtex-5 LX85
Please refer to FPGAs - Under the Hood for further information.
Aashish M
Applications Engineer
National Instruments
http://www.ni.com/support/

Building mesa with OpenCl support [Solved]

Hi,
I am trying to use OpenCl with the current mesa drivers as it is explained in this post from freedesktop: GalliumCompute, but when I try to install my own build of mesa with OpenCl it fails due to some conflicting files.
If we follow the post, we can see that we need:
- LLVM with '--enable-experimental-targets=R600', but the stable repo already provides this so we are fine.
- Libclc can be found in AUR: libclc-svn
- Mesa with '--enable-opencl'. This has to be built manually with ABS adding the flag to the PKGBUILD.
But when I try to install the generated packages I get an error because there are conflicting files:
error: failed to commit transaction (conflicting files)
mesa: /usr/include/CL/cl.h exists in filesystem
mesa: /usr/include/CL/cl.hpp exists in filesystem
mesa: /usr/include/CL/cl_ext.h exists in filesystem
mesa: /usr/include/CL/cl_gl.h exists in filesystem
mesa: /usr/include/CL/cl_gl_ext.h exists in filesystem
mesa: /usr/include/CL/cl_platform.h exists in filesystem
mesa: /usr/include/CL/opencl.h exists in filesystem
mesa: /usr/lib/libOpenCL.so exists in filesystem
mesa: /usr/lib/libOpenCL.so.1 exists in filesystem
mesa: /usr/lib/libOpenCL.so.1.0.0 exists in filesystem
Errors occurred, no packages were upgraded.
Checking with 'pacman -Qo' I have found that the headers come from 'opencl-headers' and the shared objects from 'libcl'.
So, is there a way to install mesa with OpenCl support?
Thanks in advance.
Last edited by Noxbru (2013-09-30 16:13:18)

Lordheavy's git packages are setup to make switching between mesa-git and mesa easy, so include provides/conflicts/replaces lines in the PKGBUILDs to ease substiution.
No need to uninstall mesa.
Mesa is a split package, and you should replace all parts of it.
If you run pacman -S mesa-git , there should be errors because all parts need to have been build against the same source,
but i don't know if pacman handles that correctly.
To be on the safe side, you should tell pacman to install ati-dri-git instead as that will pull the other necessary mesa-git subpackages.
about the files from opencl-headers & libcl :
mesa-git incudes opencl-mesa-git which does provide those files, but libclc-git doesn't have opencl-mesa-git as dependency.
I think the full command you should use is : pacman -S ati-dri-git opencl-mesa-git libclc-git .
That should pull in all needed pacakges and not give any conflicts.
Edit :
The PKGBUILD for LH's mesa-git are in http://pkgbuild.com/~lcarlier/mesa-git/sources/ .
I looked directly into the sources to verify what i posted above.
Last edited by Lone_Wolf (2013-09-30 11:57:12)

Source distribution with FPGA support

Similar Messages

Maybe you are looking for