Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation


About xavier30

  • Rank
  1. Hi Onno, I found myself in the same situation as you a while back. (this was before the VIPM came out, if it had existed at the time we probably would have used it) We (a team of researchers within a larger organization) where and are doing dedicated, institute specific modules in labview for integrating NI equipment in an existing infrastructure. This has after several projects and years of development turned into a framework that we now (try to ) maintain (and update). To find a easy way of distributing this framework to all the "users" we also thought that svn could get the job done i
  2. Hi, First off, i don't know if this post is in its correct category, or if the question has been answered before. I have been asking my dear friend google quite a bit but this time he/she unfortunately failed me. I was playing around with the labview provider interface (in lack of a better name) today, trying to create my own custom right click menus, to launch various labview plugins/scripts. What i did was taking an existing provider/plugin such as the SCC tool located in <LabVIEW dir>/resource/framework/provider/SCC , copy it, remove everything i didn't need from the toolkit (leavi
  3. Dear Lavaers I guess this question might be a recurring issue when porting LabVIEW applications between platforms, but i was hoping some of the bright minds here had a solution for this problem. I was trying to set up a system where users could run a windows (XP) built LabVIEW application, running on a PXI (the PXI currently runs windows, but will probably be running Phar Lap when every thing is finished), and interact with the applications on the PXI trough remote panel from several linux clients (running Red Hat scientific linux 5). the labview web server on the PXI hosting the VIs work p
  4. Yay! finally lava is back!! I dreaded that my No 1 LabVIEW resource was gone I have been using googles cached copy of the lava pages for the last month XD. (by the way could you perhaps get some of the missing pieces from them? if there are any.) I'm gonna have a few cold brown ones tonight just in the name of LAVA 2.0. and all you guys who got this great site back up!
  5. I been doing some debugging now for a while, and everything so far indicates that the problems we are getting in this case is coming from using the g++ 3.4.x compiler which links to libstdc++.so.6 when using functions like "list" and "vectors" inside the library (we are not re-shaping memory allocated by labview, but we are using c++ functions in other libraries called by mine to do some of the work). I think i managed to reproduce the fault by making a small test library where i create some c++ functions, not doing anything, just initialising things like vectors and lists, and then i compile
  6. QUOTE (Adam Kemp @ Mar 30 2009, 07:11 PM) Thanks Adam, I unfortunately haven't gotten the sources of the code causing the double free problem yet (not my part of the code, and it might take some time but i found a nifty little tool called "die hard" that i'll check out in the mean time: http://www.diehard-software.org/ to see if i can suppress the error until i get the sources and hopefully manage to fix the problem. not really the solution i wanted, but if it works, i'll use it in the meantime Thanks for all the inputs though. X
  7. Thanks Rolfk and Adam To Rolfk : i tried removing all inputs and outputs between labview and the library, and instead piping all error messages and events in the library to the stdio. I also changed all inputs to constants in the c wrapper itself, re-compiled and tried to see if the labview executable would crash just by calling the library, which it did. To Adam: i will see if i can get some more data by enabling the full error checking. I did a small debugging session with gdb and managed to get a backtrace from the shared library and its callers. it seems that the problem could come from
  8. QUOTE (Adam Kemp @ Mar 27 2009, 04:36 PM) Hi Adam and thanks for your reply! I have started the process of narrowing down the problem, and it now seems to be coming from the shared library. my problem is that this implementation is huge, and consists of several developers in different countries, so getting hold of all the sources for re-compilation and debugging isn't always too easy. I agree that it might be a bit to sudden blaming the application builder, but i just find it a bit strange that everything seemingly runs fine in labview 8.2.1 executables. will try to do some more debugg
  9. Dear LAVAers After having the linux version of labview 8.6 for a while, we decided it was time to move our applications from labview 8.2.1 to LabVIEW 8.6. most things when fine, but i got into trouble when trying to port some of the applications making use of shared libraries. There is one library in particular i have been battling with: a implementation of Role Based Access Control (RBAC) done in C++, and used in most of our front ends at work. unfortunately i can't upload the source of the libraries here, since the whole RBAC project invokes several external shared libraries and server dep
  10. QUOTE (rolfk @ Dec 18 2008, 10:09 AM) Thanks Rolf This world of Mac is still new to me After making this post, i managed to make a small Xcode project and creating the .framework "directory" and making use of some simple callbacks. My only "problem" now seems to be how i can re-use my makefile in the mac unix environment. I guess this post is more suited in the mac/linux forums, but i'll post back what i figure out. X
  11. Dear Lava users (im sorry if this post is more a c/c++ code porting problem than a actual labview problem, but... ) I just bought myself a brand new apple Mac book Pro, 15" with OS X Leopard (10.5.X i think?) installed. After playing around and familiarizing my self with mac, OS X and its unix like environment, i decided to port some of my labview code wrappers that we use at work to interface with various things, previously compiled for both windows in visual studio 6 and 8 and linux red hat 4 and 5. (gcc 3.4.2 and gcc 4.1.2 i beleive, but not 100% sure). So i did some reading, and it se
  12. QUOTE (Adam Kemp @ Aug 18 2008, 06:48 PM) Thanks for the input. I could change the permission of the folder containing the top level vi, but i was hoping to avoid this. I guess in the end this would be the easiest sollution. I guess what i was fishing for was if there was a way to programatically re-link the VI's (something like a "mass compile light") if i chose to store them in /tmp. X
  13. Dear users of the LAVA forum I did some brief searching in this (and other) forums, but i couldn't quite find an answer to my problem: I have a non reentrant and non template vi which is not developed nor maintained by me (which basically means i would prefer not to change any of the preferences or properties of this vi). This VI is called by an application i created, where i copy the top level vi i want to call, and when the called vi is in memory, i delete the clone: This way i can launch multiple instances of the VI without making it reentrant, or saving it as a template. My probl
  14. Hi there great people of the LAVA forum. I was just wondering about a small thing: is t possible to run the Shared Variable Engine under Linux OS? I know that the NI pages states that the SVE can only be executed under Windows (and Pharlabs), but im puzzled by the idea of running this under Linux so that you don't have to dedicate a windows server for the SVE in a "linux only" enviroment. If it's not possible to run SVE under linux, could it then be possible through windows emulators such as Wine? or is the SVE to heavily integrated with LV that it would be hard to separate this server as
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.