Re: Labview Linux!!
Here is a command-line build tool that I created. It has a lot of useful features that overlap with what you are trying to do. http://www.openg.org/tiki/tiki-index.php?page=LVBLD%20-%20Command%20Line%20Build%20Tool good luck, -Jim Kring
RE: GOOP and spawning VIs on FieldPoint RT controller
Tore, If you are running on an RT Target, then the reentrant approach is better than the template technique, IMO. The reason is because of a catch 22 -- you cannot create an instance of a template while the template is in memory; but, the template must be in memory in order to be transferred to the RT target when running in development mode (while targeting the RT system). In order to include a template into the build you would have to add it explicitly as a dynamic VI -- since it cannot be in the application hierarchy -- since you can't have it in memory when an instance is created at run-time. So, in conclusion, when spawning multiple instances of non-GUI processes, I highly recommend the reentrant VI approach in conjunction with the static VI reference to insure that the process VI is included in the application hierarchy. In general, most of my RT/embedded apps have been headless (set to run automatically at RT system startup time) and use TCP/IP to serve functionality to high-level GUIs. Since the server supports multiple simultaneous clients, this allows multiple instances of the same GUIs to be run concurrently. -Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tore Johnsen Sent: Thursday, May 27, 2004 1:32 PM To: [EMAIL PROTECTED] Subject: Re: GOOP and spawning VIs on FieldPoint RT controller Alex, Jim: Thanks for your help. Exactly what I needed. Yep, I use the template technique and pass data to the spawned VIs using the Set Control Value method prior to running them. In the past (for non time-critical VIs) I haven't bothered making the spawned VIs reentrant since they are copies and run just fine in parallel without (different story for common Sub VIs that should run in parallel). If the execution speed of the spawned VIs is very critical it is a good idea to make them reentrant (or turn off debugging). The last time I did this on a non-RT target (read PC) I also embedded the spawned VIs as sub-panels on my top-level VI - a great technique when controlling multiple identical systems from one PC. Tore - - Subject: Re: GOOP and spawning VIs on FieldPoint RT controller From: Alex Le Dain [EMAIL PROTECTED] Date: Wed, 26 May 2004 09:29:32 +0800 GOOP works fine. Re spawning the VI's, the important trick is to get the path correct; this takes a bit of figuring out and makes it a little harder to debug than usual. When debugging the code VI (I presume using the template technique) it can sometimes not be updated down on the controller, so you need to download it any time you make a change to the code to make sure you are running the correct version. cheers, Alex. - - Subject: RE: GOOP and spawning VIs on FieldPoint RT controller From: Jim Kring [EMAIL PROTECTED] Date: Tue, 25 May 2004 22:13:55 -0400 Tore, I've employed the spawning pattern extensively on RT with great success. There are a few tricks that will make things easier for you: 1) I assume that you are using the spawning pattern of passing the spawned instance of a reentrant VI data via the Set Control Value method before invoking the Run method. Make sure that, in your built app, the FP's of the spawned VIs are preserved by the App Builder otherwise the Set Control Value will fail. The easiest way to do this is to put a control reference or implicitly linked property node on the BD of the spawned VI that links to a Control on the FP of the VI. This causes the App Builder to assume that you are using, and therefore need to preserve, the FP of that VI in the built app. 2) One thing that I have done to avoid the path problems that Alex mentioned is to use a Static VI Reference (LV 7.0 feature) to reference the spawned VI (instead of referencing by path). However, you can't invoke the Run method on a Static Refnum, so you will need to open another reference by reading the Static RefNum VI's name and then opening a reference, by name. This new reference have the Run method invoked on it. But, remember to close this new reference -- you may want to pass it into the Spawned instance and let it close it itself (but be careful that you don't close it too early or the spawned VI will halt execution and die). 3) The Static VI Reference is also really nice because it causes the VI to be loaded into memory and exist in the call chain of your VI Hierarchy. This causes the VI to be included in the build and it also causes it to be transferred to the RT execution target when you run your app in development mode. If you reference your spawned VI by path and it is not loaded into memory, then it will not be uploaded to the RT execution target when running in development/debug mode. Cheers, -Jim Kring
RE: GOOP and spawning VIs on FieldPoint RT controller
Tore, I've employed the spawning pattern extensively on RT with great success. There are a few tricks that will make things easier for you: 1) I assume that you are using the spawning pattern of passing the spawned instance of a reentrant VI data via the Set Control Value method before invoking the Run method. Make sure that, in your built app, the FP's of the spawned VIs are preserved by the App Builder otherwise the Set Control Value will fail. The easiest way to do this is to put a control reference or implicitly linked property node on the BD of the spawned VI that links to a Control on the FP of the VI. This causes the App Builder to assume that you are using, and therefore need to preserve, the FP of that VI in the built app. 2) One thing that I have done to avoid the path problems that Alex mentioned is to use a Static VI Reference (LV 7.0 feature) to reference the spawned VI (instead of referencing by path). However, you can't invoke the Run method on a Static Refnum, so you will need to open another reference by reading the Static RefNum VI's name and then opening a reference, by name. This new reference have the Run method invoked on it. But, remember to close this new reference -- you may want to pass it into the Spawned instance and let it close it itself (but be careful that you don't close it too early or the spawned VI will halt execution and die). 3) The Static VI Reference is also really nice because it causes the VI to be loaded into memory and exist in the call chain of your VI Hierarchy. This causes the VI to be included in the build and it also causes it to be transferred to the RT execution target when you run your app in development mode. If you reference your spawned VI by path and it is not loaded into memory, then it will not be uploaded to the RT execution target when running in development/debug mode. Cheers, -Jim Kring -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Le Dain Sent: Tuesday, May 25, 2004 9:30 PM To: Tore Johnsen Cc: [EMAIL PROTECTED] Subject: Re: GOOP and spawning VIs on FieldPoint RT controller GOOP works fine. Re spawning the VI's, the important trick is to get the path correct; this takes a bit of figuring out and makes it a little harder to debug than usual. When debugging the code VI (I presume using the template technique) it can sometimes not be updated down on the controller, so you need to download it any time you make a change to the code to make sure you are running the correct version. cheers, Alex. At 03:02 PM 25/05/2004 -0500, you wrote: Dear All, I wonder if anyone has tried using GOOP 1.0 and/or spawning VIs on a FieldPoint RT controller? I know it sounds a bit crazy but here goes: I have an application where I'm independently controlling up to 12 identical test stands - each only needing a few digital outputs (there are a few additional inputs to the system as a whole). Since the loop-time isn't very critical for this application (100ms loop-time would be more than sufficient) I'm considering simplifying the core of the software by making one control VI for one test stand and spawning as many copies as needed at run-time, meaning there will be up to 12 control loops (+ 1-2 loops for application level I/O) running at the same time. I'm also considering using GOOP 1.0 so there in effect will be up to 12 identical objects. Again, this would be crazy if I didn't already have easily reusable code to handle the support functions needed. Have anybody tried using similar techniques running an embedded application on a FieldPoint RT controller? Any reason why this wouldn't work? (I'm receiving the info-labview digest so I'd be grateful to also receive responses directly to my email address) TIA, Tore --- Tore Johnsen Saint Bernard Engineering, Inc. Phone: 651-494-9073 Email: [EMAIL PROTECTED] http://www.saintbernardengineering.com/ Alex Le Dain Software Engineer Poseidon Scientific Instruments 1/95 Queen Victoria Street Fremantle WA 6160 AUSTRALIA Ph: (+61 8) 9430 6639 Fx: (+61 8) 9335 4650 Web: www.psi.com.au
RE: OpenG Coding Challenge - Remove Backspace
I hav just returned from a week-long trip and will be moving forward with the judging. Regards, -Jim Kring -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andreas Nilsson Sent: Tuesday, May 11, 2004 12:27 AM To: Info-Labview Mailing List (E-mail) Subject: OpenG Coding Challenge - Remove Backspace I really wonder who will win the contest... /Andreas
[L] Firewire IIDC (DCAM) cameras in Linux?
Hello info-lv'ers, Anyone write any LV code for communicating with IEEE1394, IIDC-compliant (aka DCAM) digital cameras in Linux through the libraw1394 or libdc1394 shared libraries? Regards, -Jim Kring
Re: Visual source safe
Best of all, CVS and TortoiseCVS are free -- same goes for Subversion and TortoiseSVN. ;-) -Jim Craig Graham wrote: If you're only just moving to source code control, I recommend NOT using VSS. Google for Visual Source Unsafe and I think you get lots of reasons why. I use CVS, and although there's no native support it's still very simple when using one of the helper utilities surch as Tortoise. I gather Subversion is supposed to be better than CVS, but I've no pressing reason to go looking for a replacement. -- Dr. Craig Graham, Software Engineer Advanced Analysis and Integration Limited, UK. http://www.aail.co.uk/ - Original Message - From: James Stewart [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, April 23, 2004 3:10 PM Subject: Visual source safe Does anyone have experience using Visual Source Safe with LabView code? Are there any issues to consider? Is there a recommended way to implement it with LabView? Thanks, James/.
Re: Type Specifier VI Refnum lost at build
Eric, Try adding this to your LabVIEW settings file. I'm not certain that it will fix your problem, but it might. BldApp.RemovePolyVIsandTypedefs=False ## By default, LV7 AppBuilder does not include type definitions and unused instances of polymorphic VIs into executable in order to decrease size of application. If some VI in your exe calls a VI outside (that was not planned by AppBuilder) and uses a type definition in order to pass parameters, you will meet such kind of problem for sure. This undocumented ini setting disables this new feature. ## -Jim Eric Samsel wrote: I'm trying to use the Call by Reference node to dynamically call certain subvi's. It works great during my testing. However, after building the application, all of my Type Specifier VI Refnums go back to the initial way they look when they are created. Saving values as defaults doesn't work. When I quit my application and come back the connector panes still match as they should. The problem only occurs when I build... Does anyone know why this is happening or what I am doing wrong? Thanks, Eric Samsel
OpenG Coding Challenge - Remove Backspace
Hello Info-LV'ers, I have started a contest to create a high-performance VI that removes backspace characters (and the characters preceding them) from a string. The wining entry will become part of the OpenG Toolkit. (Note that VI Icons will be judged separately). Visit http://openg.org page for more info and download the example. Entries must be received by April 31st. http://www.openg.org/tiki/tiki-index.php?page=OpenG+Coding+Challenge+-+Remove+Backspace Regards, -Jim Kring
Re: OpenG Coding Challenge - Remove Backspace
Mike, Here is the problem description that I put up on the challenge page. This isn't an extremely hard challenge, but it is a fun problem. Also, you can spend additional effort trying to shave off the last few milliseconds. -Jim http://www.openg.org/tiki/tiki-index.php?page=OpenG+Coding+Challenge+-+Remove+Backspace Background When you are typing at a terminal (telnet for example) and you press the backspace key, a \b (0x08) character is sent via TCP-IP. The server that is parsing the text must interpret this string and remove the preceding character, which may have already been transmitted over the network. If the server receives a string like This is a test\b\b\b\bgood test for removing backspaces., it should remove the backspaces and the preceding characters so that the string becomes This is a good test for removing backspaces. Since there were four (4) backspaces we have to remove the backspaces and the four preceding characters t, e, s, and t. Easy, huh? But how do you do it quickly? Notice that the example shown above uses both a Build Array and Delete From Array in a loop. This is a performance no-no. It works but we can do a lot better. *Hint* - don't build/delete an array (or concatenate/split strings) in a loop. Ross, Michael wrote: I am curious, what makes this an intersting problem? What makes it hard? Also, what would be the application of this vi? These are not meant to be rhetorical questions, though they can certainly sound that way in an email. I have done just enough screwing around with strings to see that they are irritating, but I haven't had any intractable problem. In other words I am pretty ingnorant of the subject. Mike -Original Message- From: jkring [mailto:[EMAIL PROTECTED] Sent: Saturday, March 27, 2004 1:07 AM To: info-labview Subject: OpenG Coding Challenge - Remove Backspace Hello Info-LV'ers, I have started a contest to create a high-performance VI that removes backspace characters (and the characters preceding them) from a string. The wining entry will become part of the OpenG Toolkit. (Note that VI Icons will be judged separately). Visit http://openg.org page for more info and download the example. Entries must be received by April 31st. http://www.openg.org/tiki/tiki-index.php?page=OpenG+Coding+Challenge+-+Rem ove+B Backspace Regards, -Jim Kring
Re: OpenG Coding Challenge - Remove Backspace
Marco Tedaldi wrote: Jim Kring wrote: Hello Info-LV'ers, I have started a contest to create a high-performance VI that removes backspace characters (and the characters preceding them) from a string. The wining entry will become part of the OpenG Toolkit. (Note that VI Icons will be judged separately). http://www.openg.org/tiki/tiki-index.php?page=OpenG+Coding+Challenge+-+Remove+Backspace That's just depressing! There are people in the rankint with a speedup of about 160! And I've built two versions... one which completes in about halve the time and another one which takes longer than the original! :-( Are the Results on the site really true? I allmost can't believe it! But I'm trying :-) Bye Marco Hi Marco, Yes the results are real ;-) Also, all of the top entries are very similar to the example, but do not use build array or delete from array. Keep trying and good luck. Regards, -Jim
RE: OpenG Coding Challenge - Remove Backspace
Mike, Based on a lot of similar feedback, we have updated the Functional Requirements to the following (thanks to Christian Altenbach for his work on this): -- Removes all backspaces (Slash Code: \b, ASCII Hex: 0x08) and the characters preceding them. If there are N consecutive backspaces, N preceding characters will be removed. Extra backspaces are discarded whenever the edited string reaches zero length. This VI is useful for terminal programs that are processing user input received by TCP-IP. -- Hopefully this catches all of our limit conditions (empty string, all backspaces, no backspaces, etc). Yes, we will be testing for accuracy as well as performance. Regards, -Jim Ross, Michael wrote: Mine does spurious \b's so go for it! mike -Original Message- From: Scott Hannahs [mailto:[EMAIL PROTECTED] In terms of the problem description, must the VI handle the case where there are more \b (backspaces) than there are characters? If this is true then the VIs should pass an accuracy test as well as performance! -Scott
Re: Running two copies of VI and seeing two FPs
Simon Whitaker wrote: Hi folks, I'm trying to get a VI set up so that it can have more than one open FP available at once. It's a log viewer and I'd like to be able to have two instances running side-by-side, with a different log file loaded into each one. Setting the VI to reentrant doesn't appear to be the complete solution. This must be a fairly common problem, and I'd be interested to hear from anyone who's managed to solve it. Cheers, Simon Simon Whitaker [EMAIL PROTECTED] Head of Software Development, Tiab Ltd tel: +44 (0)1295 714046 fax: +44 (0)1295 712334 web: http://www.tiab.co.uk/ Simon, Search the archives for cloning front panels. There are a few approaches, but opening VI Server references to VI Templates seems to be the favorite. There have also been some discussions about this on the NI Dev Zone LV General Discussion. -Jim
Re: OpenG Coding Challenge - Remove Backspace
Alex Le Dain wrote: I would also think that re-entrancy here is only for testing as near to optimum, presumably building a VI into an EXE would achive the same increase in performance as is achieved with reentrant=TRUE, as the UI and debug code are removed then. Is that correct Jim? We'll sure find out ;-) -Jim
Re: How to talk my company into allowing OpenG usage?
You get what you pay for; if it's cheap or free it's crap. And some opinions fit into that category too, but it is best not to generalize ;-) One should always perform an evaluation of the tools (and advice) they are going to use, prior to using them. If they meet your standards and requirements then go for it. If not, you can always throw money at your problems (and pay someone to invent you a wheel). Largely, the price you pay for Open Source software is the time that it takes you to evaluate, learn how to use, and participate in the development of the software -- in that respect Open Source software is not free. But if you don't pay that price, then... (sometimes) you get what you pay for. Regards, -Jim PS - Have you read your NI Software License Agreement lately? Is your application authorized and will it be authorized tomorrow? OK, gotta run... I hear the helicopters circling :-)) Craig Graham wrote: Swinarsky, DJ Derrick (5453) @ IS wrote: Just curious if anyone has any tips on convincing the corporate types that using software developed by the opensource community is a GOOD thing. I would love to be allowed to use all the OpenG tools and think that many in my group would also benefit from them. Also would like to use some of the labXML code developed on sourceforge. Problem is that I work for a big defense contractor that is not too keen about the idea of opensource. Have some paranoid individuals somewhere in the chain that think code developed on sourceforge is not reliable and shouldn't be trusted. Also have heard that in order for anyone in the company to use software downloaded from the internet the company has to have an agreement with the providing entity (company usually). Any help in this matter would be GREATLY appreciated!!! rant I went down the same path about a year ago and gave up. Problems I encountered (and still do in different contexts); 1) You get what you pay for; if it's cheap or free it's crap. 2) If it wasn't written in-house, it's crap. 3) If the license doesn't state in one line of words of one syllable that there are no copyright, royalty or any other IP issues with the code no matter how you use it, it's crap. I disagree with all three points, but that's what I came up against and I've given up on it. With regards to point 3, I got quite an involved email from Jim Kring explaining what we could and could not do with OpenG. Didn't help- the response was that an email isn't legally binding. In another instance, Albert Geven offered to let me use some pretty useful code he'd done for saving and loading panel settings in a way that was resistant to datatype changes, control addition/removal etc. The conditions that were imposed on using that were unreasonable- I was expected to ask Albert to sign a waiver that no IP rights would be exercised on the code and fax it back to us so we could use the code he'd given me as a favour. I didn't see why he should have to mess about like that so I didn't do it. When someone sends you code in an email with permission to do with it as you please, it's a bit off to then start asking them to jump through hoops so they can help you out! Even though you have the source and so the included open-source stuff can be audited (and maintained) just as well as the in-house stuff, I wouldn't hold out hope on persuading the decision makers at your end. \rant
Re: How to talk my company into allowing OpenG usage?
Of course, I have no idea what is Jim's or the other OpenG developers' policy on receiving money. I am just thinking out loud. If you follow the Support this project link from OpenG.org http://sourceforge.net/donate/index.php?group_id=52435, you will see the following: Information provided (by this user or project's admin) about donations: Any money donated will go to maintaining the OpenG.org website and hosting group meetings. This costs approximately 1000 dollars (US) per year. If people would like money to go to the development of specific projects and/or features, please email me prior to donating funds. A full account of how funds are spent, will be made publicly available. Mostly, people contribute to projects that have (monetary or other) value to them and their projects. But, if people would like to pay for new features that are important to them and they would rather spend money than time, we are open to that idea as well. -Jim Enrique Vargas wrote: 1) You get what you pay for; if it's cheap or free it's crap. Somebody correct me if I am wrong, but, if they want to pay money for it, they can. (Give it as a donation to OpenG. ) What I am trying to say is that, AFAIK, the term free in the open source philosophy is not one of free of cost: Free software is a matter of the users' freedom to run, copy, distribute, study, change and improve the software (from gnu.org) The fact that you can obtain the OpenG tools and code at no cost should then be an added benefit. If that do not make them confortable, then they can always pay for it. That is not in violation of the open source philosophy. (I am pretty sure Jim and the team of developers can use the money for the open source cause. I won't even mind if they decided to get some beer: their work is priceless, but that's just me.) Of course, I have no idea what is Jim's or the other OpenG developers' policy on receiving money. I am just thinking out loud. Regards; Enrique Vargas www.visecurity.com
Re: OpenG Coding Challenge - Remove Backspace
Craig Graham wrote: - Original Message - From: Marco Tedaldi [EMAIL PROTECTED] To: Info-LabVIEW [EMAIL PROTECTED] Sent: Monday, March 29, 2004 12:59 PM Subject: Re: OpenG Coding Challenge - Remove Backspace That's just depressing! There are people in the rankint with a speedup of about 160! And I've built two versions... one which completes in about halve the time and another one which takes longer than the original! :-( Are the Results on the site really true? I allmost can't believe it! But I'm trying :-) Well, my first attempt came in at a tad under 20ms. I'll have another crack soon; obviously not much point submitting at this stage. But I also am trying. :) For the short term, take the current performance rankings with a grain of salt. There are statistical uncertainties in those numbers and there are platform and LabVIEW version differences, as well. We are working on a test plan that will test the entries on a variety of platforms and under many input conditions. Ultimately we want to account for (and try to eliminate) any uncertainties. Regards, -Jim
Re: Bill Gates Endorses the LabVIEW methodology
[EMAIL PROTECTED] wrote: From a Reuters news story dated March 29, 2004 Gates also said advances in programming will allow software developers to create applications in less time by using visual representations of the inner workings of software rather than writing lines of programming code. http://story.news.yahoo.com/news?tmpl=storyu=/nm/20040329/tc_nm/tech_microsoft_gates_dc Alan Gleichman Hella Electronics Corp. Plymouth, Michigan Alan, My bet is that Gates is referring to Computer Aided Software Engineering (CASE) tools that generate and maintain code automatically from Universal Modeling Language (UML), or similar graphical modeling languages. LabVIEW/G isn't a system modeling language, it is an implementation language. The new LabVIEW State Diagram Editor is a step towards the LabVIEW *IDE* being capable of modeling -- you can view (and edit) your state machines from the perspective of a state transition diagram. As far as implementation languages go, G is one of the best. It is a revolutionary step up from typing lines of code. However, when we look at the big picture we still have a long way to go and, unfortunately, until we can programmatically generate, inspect, and maintain LabVIEW code we can't start tackling the problem of connecting modeling tools to G. But, with the recent discovery of undocumented scripting features in LabVIEW 7.0 (see link below), this may not be that far off... and Gates might not have anything to do with it ;-) LabVIEW Scripting Forum @ LAVA: http://forums.lavausergroup.org/index.php?showforum=29 -Jim
Re: OpenG Coding Challenge - Remove Backspace
Craig Graham wrote: Hmm. Just got round to my second approach and it also takes 20ms. However if I change it to subroutine it comes down to 8ms here. Have the posted results been normal priority or subroutine? For the results currently posted, all entry VIs were set to the following: Execution System = Same as Caller Priority = Time Critical Priority Is Reentrant = TRUE -Jim
Re: three way switch?
http://www.openg.org/tiki/tiki-index.php?page=3+Way+Switch
Re: flatten to xml from variant
Mathis, Refnums (especially VISA/DAQ/IVI refnums) are tricky. We'll work on it. I have generated a feature request. You can track progress here: http://sourceforge.net/tracker/index.php?func=detailaid=921506group_id=52435atid=466835 Cheers, -Jim
LV Scripting Forum at LAVA?
That's pretty cool, David! The possibilities really makes the mind wander and wonder. I'd be interested in hearing about and seeing some examples of other neat utilities people have been able to put together using these exposed privates. Perhaps a LAVA discussion forum could be created for the purpose of investigating these newly discovered Scripting toys. That way the Advanced LabVIEW user-community could help provide basic tech-support and documentation. Regards, -Jim Kring -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Edwards Sent: Monday, March 22, 2004 6:16 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Warnings coercion dots (Was - All those things) Stephen: LabVIEW now has the very nice warnings feature that is very good for improving code reliability. Unfortunately, coercion dots do not show up as warnings. Finding the diagram property in the code Norman pointed to, allowed us to write a nice utility to scan a complete project for coercion dots. David Edwards FemtoTek, Inc. Standard warning that anything that we try to hide a) may or may not be supported in the next version of LV b) probably has never been introduced to tech support so they won't be able to help you c) may break (read: crash) if used outside of very specific context. Proceed on the theory that if you're using it, you're on your own. We don't typically hide things that we think customers can actually safely use. Pojundery, Stephen R. Mercer -= LabVIEW RD =-
RE: Alternative info-LabVIEW list
OK, my turn... I believe that Michael Aivaliotis would be an excellent info-labview list administrator. He has repeatedly demonstrated that he is technically capable of this task through his management of the LAVA mailing lists, discussion forums, and the NI Week Blog. I have found him to be very accessible by email/IM and ever-present on the various LabVIEW community forums. I am sure that he would keep the info-labview list up and running like clock-work. Best Regards, -Jim Kring Scott Hannahs [EMAIL PROTECTED] said: Ok, I will be public about this. I have offered to take over at least two of Tom's lists and host them here at the lab using the same software that he uses to host them. If Michael wants to do this that is fine, since I also use the Igor list I figured that I could do this with the least disruption. I (and all of us) are waiting for Tom to decide what is the best way to transfer this. In the meantime the system seems to be chugging along (those dang Macs just don't quit!). -Scott At 8:39 PM -0500 3/16/04, Michael Aivaliotis wrote: As far as we can tell, it's just a matter of time since Tom's personal server that hosts info-LabVIEW goes tits up. In the long-term we just want one list of course. Since Tom has asked for help in transferring the list, I am just stepping up to the plate and making the first move. If there is anyone out there that wants to host the list or has any other prior arrangement with Tom then please feel free to say so. I can assure everyone that the new list will follow in the same footsteps as the previous one and maintain the independence that was inherent in the previous list. It will also stay a text based list and prohibit attachments. In addition, it will be monitored and maintained on a daily basis and will be in the hands of active LabVIEW users. --
Re: flatten to xml from variant
A couple things. (1) it appears that this has been fixed in 7.0. I reproduced your problem in 6.1 but not in 7.0 (All testing done on WinXP). (2) OpenG has a Flatten/Unflatten to/from XML tool that is written entirely in G. You can find more information here: a href=http://www.openg.org/tiki/tiki-index.php?page=EXAMPLE+-+OpenG+Flatten+to+XML;OpenG.org : EXAMPLE - OpenG Flatten to XML/a
Re: Repeatedly Launching Reentrant Front Panel
There are a few ways to do this, but the reentrant approach will not work, since all instances of reentrant VIs share the same Front Panel. Here are the possibilities: (1) Create multiple copies of your GUI VI at edit time, and call them statically or dynamically. (2) Copy new instances of your GUI VI at run time using the File Copy function and then invoke the GUI VI dynamically (3) Change your GUI VI's file extension to .VIT so that it is a VI Template. Then open a VI server reference to it multiple times to get multiple instances of the VI and invoke dynamically, as in #2. Regards, -Jim
RE: NI-VISA for serial only - sans installer
I've heard folks mention that you can use the merge modules directly with 3rd party installers. The merge modules are located here: labview/applibs/distkit/redist/modules/*.msm -Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, March 11, 2004 7:22 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: NI-VISA for serial only - sans installer ...and what is the recommended solution for those who do not (and do not wish to) use the installer incl. with Application Builder? Regards, Parker Russell --FORWARDED-- Subject: RE: API Serial Functions From: [EMAIL PROTECTED] Date: Wed, 10 Mar 2004 10:31:29 -0600 Scot, Allen, et al: In your posting you said NI-VISA requires an installation that is often larger than the application we supply to our customers ... I was hoping to develop our own serial functions in a much smaller package than NI-VISA. I just wanted to let you know that starting with LabVIEW 7.0, NI-VISA for Serial only is now included when you have LabVIEW PDS build the application and installer distribution. That's less than 400 KB of VISA files on the target system and directly addresses your concern (and that of many other customers) about the package size. Dan Mondrik National Instruments
RE: API Serial Functions
Allen, OpenG is working on migrating from the LGPL to a Mozilla Public License derivitive. This will eliminate the relinkability requirement imposed by the LGPL. You can read more about this here: http://openg.org/tiki/tiki-view_forum_thread.php? forumId=3comments_parentId=286 Regards, -Jim Kring C. Allen Weekley [EMAIL PROTECTED] said: Rolf, The Open-G VISA idea sounds really interesting. I am a bit wary of open source because it seems difficult to make an installation that is a combination of open source code and proprietary code, and meet the rules for distributing open source code while still protecting the proprietary code. If you have any ideas about how to make this issue easier to deal with I would be interested in working on the Open-G VISA library. Allen -Original Message- From: Rolf Kalbermatter [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 09, 2004 1:28 AM To: 'C. Allen Weekley' Cc: Info LabVIEW (E-mail) Subject: RE: API Serial Functions C. Allen Weekley [EMAIL PROTECTED] wrote: Yes. My company manufactures a variety of instruments that communicate solely with serial. We have been using NI-VISA and are happy with it, but NI-VISA requires an installation that is often larger than the application we supply to our customers, and there are licensing restrictions for distribution. I was hoping to develop our own serial functions in a much smaller package than NI-VISA. This is why I am interested in using the Windows API. NI-VISA with its support for so many kinds of instruments seems like overkill for our application. When the customer installs the NI-VISA driver they end up installing features to support GPIB etc. that are not needed for our application. Well, I see. Just forget about my previous mail then, will you. I have started some work on a VISA32.DLL replacement which I intend to release as Open-G VISA library. It is far from complete and I have only worked on Windows yet but intend to actually push the Linux version more. It is structured similar as NI-VISA with VISA32.DLL as top level API and low level plugin DLLs which provide support for particular VISA resource types. The first I have started with is serial of course, but it is as I said not functional at all yet. I still need some common infrastructure libraries as well. I was intending to get something working before putting it out, but it is geoing slow and it will take quite some time before I get there. If you would be interested in working on that as well I could create an Open-G subproject and put up what I have so far so that you could take a look at it and work yourself on it as well. Rolf Kalbermatter CIT Engineering Nederland BVtel: +31 (070) 415 9190 Treubstraat 7H fax: +31 (070) 415 9191 2288 EG Rijswijk http://www.citengineering.com Netherlands mailto:[EMAIL PROTECTED] --
Re: VIT as Reusable GUI interesting behavior...
Philippe, I don't have time to test this recollection, but I believe that if the FP of the VIT instance is closed when it is unloaded from memory (when the reference is closed) you will not see the save change dialog. -Jim PJ M [EMAIL PROTECTED] said: Hi all, I am spawning reusable GUI using VIT (the spawn is created using VI server [Option input is empty on the Open VI ref], then the run method is invoke with wait until done set to false then in a while loop with timeout I wait until the FP.Open become true then I close the reference) . The spawned VI has the code for unloading itself from memory upon completion. If I proceed as described, then when the spawn process close itself, Labview save changes popup windows shows up. I do not want to see that popup window. If I change my spawning technique such as I set the flag Auto dispose ref to true in the run method (and I DO NOT close the vi ref), everything work as anticipated (no save change windows popup). Is this the expected behavior ? I would feel much better if I could do the same thing and close the reference to the newly spawned process (even though labview is supposed to automatically disposes of the reference). Thanks in advance PJM _ Do you Yahoo!? Yahoo! Search - Find what you're looking for faster. http://search.yahoo.com/?fr=ad-mailsig-home --
RE: API Serial Functions
Allen, I am a bit wary of open source because it seems difficult to make an installation that is a combination of open source code and proprietary code, and meet the rules for distributing open source code while still protecting the proprietary code. I forgot to plug OpenG's Development Environment Application Builder, which can be used to address this issue. It allows building LabVIEW applications (including EXEs, if you have the LV Pro. Dev. Sys.) and you can choose to segregate groups of library VIs into custom locations and optionally preserve diagrams. You can learn about an download the DEAB from here: http://openg.org/tiki/tiki-index.php?page=Development+Environment+Applicati on+Builder There is even an example project that you can download which demonstrates the various features. And, if you are interested in working on an OpenG VISA library (or anything else), you should start by subscribing to the OpenG Toolkit Developers mailing list. We welcome your participation: http://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers Regards, -Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Kring Sent: Wednesday, March 10, 2004 1:00 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: 'Info LabVIEW (E-mail)' Subject: RE: API Serial Functions Allen, OpenG is working on migrating from the LGPL to a Mozilla Public License derivitive. This will eliminate the relinkability requirement imposed by the LGPL. You can read more about this here: http://openg.org/tiki/tiki-view_forum_thread.php? forumId=3comments_parentId=286 Regards, -Jim Kring C. Allen Weekley [EMAIL PROTECTED] said: Rolf, The Open-G VISA idea sounds really interesting. I am a bit wary of open source because it seems difficult to make an installation that is a combination of open source code and proprietary code, and meet the rules for distributing open source code while still protecting the proprietary code. If you have any ideas about how to make this issue easier to deal with I would be interested in working on the Open-G VISA library. Allen -Original Message- From: Rolf Kalbermatter [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 09, 2004 1:28 AM To: 'C. Allen Weekley' Cc: Info LabVIEW (E-mail) Subject: RE: API Serial Functions C. Allen Weekley [EMAIL PROTECTED] wrote: Yes. My company manufactures a variety of instruments that communicate solely with serial. We have been using NI-VISA and are happy with it, but NI-VISA requires an installation that is often larger than the application we supply to our customers, and there are licensing restrictions for distribution. I was hoping to develop our own serial functions in a much smaller package than NI-VISA. This is why I am interested in using the Windows API. NI-VISA with its support for so many kinds of instruments seems like overkill for our application. When the customer installs the NI-VISA driver they end up installing features to support GPIB etc. that are not needed for our application. Well, I see. Just forget about my previous mail then, will you. I have started some work on a VISA32.DLL replacement which I intend to release as Open-G VISA library. It is far from complete and I have only worked on Windows yet but intend to actually push the Linux version more. It is structured similar as NI-VISA with VISA32.DLL as top level API and low level plugin DLLs which provide support for particular VISA resource types. The first I have started with is serial of course, but it is as I said not functional at all yet. I still need some common infrastructure libraries as well. I was intending to get something working before putting it out, but it is geoing slow and it will take quite some time before I get there. If you would be interested in working on that as well I could create an Open-G subproject and put up what I have so far so that you could take a look at it and work yourself on it as well. Rolf Kalbermatter CIT Engineering Nederland BVtel: +31 (070) 415 9190 Treubstraat 7H fax: +31 (070) 415 9191 2288 EG Rijswijkhttp://www.citengineering.com Netherlands mailto:[EMAIL PROTECTED] --
FW: Windows XP SP2 could break existing applications
This just hit the press: http://www.computerworld.com/softwaretopics/os/windows/story/0,10801,90849, 00.html?nas=AM-90849 If someone from NI is listening, could you please tell us if this will affect any versions of LabVIEW running on WinXP? Regards, -Jim
RE: Detecting Lurking VIs (was Confounded and Ranting)
Paul, One solution, that works very well in this sort of situation, is to invoke the General (or Simple) Error Handler by reference. But, make sure not to open the reference (and thus load the VI into memory) until an error has actually occurred. Regards, -Jim -Original Message- From: Paul F. Sullivan [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 03, 2004 5:19 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; George Gatling (Contractor); Hooper, David S OGUK-OGES; Howard, John; Jason Dunham; Smith, Blair; PJ M; Rolf Kalbermatter; Greg McKaskle; Jim Kring Subject: RE: Detecting Lurking VIs (was Confounded and Ranting) Thanks, Rolf. I thought about trying an iteration on callees so that the scheme would work even if more functionality (and thus more subVIs) were added. (I got caught first by Simple Error Handler calling General Error Handler.) Originally, I had hoped to avoid subVIs entirely, but I managed to trigger errors myself and figured they better give some feedback to the user. The Caller in memory sounds like it might be a practical solution. Iteration on Callees looks messy. Maybe a simpler response than the Simple Error Handler is best. I'll look at it tomorrow. ...I just tested it but in LabVIEW 6.1 and higher the General Error Handler.vi has some more subVIs for it's internal user error code database and therefore your VI will always pop-up. Not sure how to fix that LabVIEW version dependant. Maybe try to avoid any VI in the list which has any Caller in memory? Rolf Kalbermatter CIT Engineering Nederland BVtel: +31 (070) 415 9190 Treubstraat 7H fax: +31 (070) 415 9191 2288 EG Rijswijk http://www.citengineering.com Netherlands mailto:[EMAIL PROTECTED] ... GhostBuster.vi, now available on http://www.SULLutions.com/LabVIEW.html, flashes a large, red warning on your screen when the only VIs, Globals, and Type Defs in memory are invisible because they are on the clipboard, off screen, or have their front panels closed... -- EnWirementally, Paul F. Sullivan SULLutions (781)769-6869 when a single discipline is not enough visit http://www.SULLutions.com
Re: Process enum labels dynamically...
Yes, you can change (write) the strings of an enum. However, the VI containing the enum must be idle (not running) in order to write to this property (it doesn't matter for reading). To do this, open a VI reference from another VI and then get a reference to the enum by getting a panel reference, and then searching through the Controls[] for one with a Label.Text whose name is the same as your target enum. -Jim
RE: Confounded and Ranting
Hello All, George Gatling wrote: I am happily working my way through my current project when I suddenly realize about half of my application is in C:\Documents and Settings\...\Temp\ I have no idea how long I have been editing files in a garbage temp folder, not to mention which ones are linked to the temp files vs the real files. GRRR!! Has anyone seen this behavior before? How does an entire app get copied to temp AND then why does LabVIEW link half to temp and half to real? Greg McKaskle wrote: I stinks when this happens, and I'm afraid I can't tell you why it definitely found VIs in your temp path. Rolf Kalbermatter wrote What has happened here is that your target drive was full at some point. LabVIEW saves its files into the temp directory before moving them to the real target to prevent corruption of at least the original file due to memory, system or disk space problems. If the target drive is full LabVIEW aborts the save operation but the files saved to the temp directory stay and if you later save the application again, the current temp copies can get the actual linked ones. I have observed this event on several occasions in LabVIEW 7.0 on Windows XP, and as far as I can remember, it hasn't happened on other system configurations. What happens to me is as follows: I press CTRL+S to save a VI that is open. LabVIEW pops open an error message about not having permission to save the file. The name of the VI changes to some strange temporary name. I press CTRL+S again and the VI is saved to the temporary location with the new name. I am not sure why the file error occurred (I have lots of disk space, which rules out Rolf's scenario). However, maybe the file was locked somehow. Regards, -Jim
RE: PushOK CVS proxy
Craig, Although SCCAPI is an open (not really) standard, LabVIEW will only allow you to use VSS's SCCAPI interface and not others that conform to the standard. You can fool LabVIEW into calling others by hacking the Windows registry and pointing the VSS entry to another SCCAPI provider's DLL. I tried this with Jalandi Igloo, but didn't have great success. PushOK claims to be a lot better than Jalandi Igloo, so maybe it would work better. However, after using TortoiseCVS http://www.TortoiseCVS.org for a while, I don't even miss LabVIEW's SCC hooks. Regards, -Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig Graham Sent: Sunday, February 22, 2004 11:14 PM To: [EMAIL PROTECTED] Subject: PushOK CVS proxy There's something I've discovered called the PushOK CVS Proxy that lets Visual Studio work with CVS as if it were SourceSafe- you don't need to load extra plugins into Visual Studio as with previous attempts at the same thing. Can't get it to work with Labview's source control. Has anyone else? -- Dr. Craig Graham, Software Engineer Advanced Analysis and Integration Limited, UK. http://www.aail.co.uk/
Re: Process with GOOP
Allen, You should be able to take snippets of the process lauch/kill code from the OpenGOOP class and integrate them into an Endevo GOOP class. -Jim
Re: Type descriptors of controls and indicators
Heinrich, The type descriptor (TD) information you are looking for is type def information, which is stored in the reserved/private section of the TD header. It isn't documented (publicly) for several reasons, but primarily because NI wants to reserve the right to change it (in new versions of LabVIEW). Is not being able to have this information a problem for you? If so, there is probably a work-around. Regards, -Jim
RE: Picture.
Daniel, You can make the frame transparent using the coloring tool. -Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Alejandro Moyano Sent: Monday, February 16, 2004 3:49 PM To: Info-LabVIEW Mailing List Subject: Picture. Hello, people mate!! I would need to know if it is possible to remove the window case in the picture.ctl. I mean, I would like to show a picture less window case. RGRDS. Daniel Moyano
RE: Application Builder Settings Dump
Roy, Yes, you can call the VI used by the App builder: LabVIEW\project\prodisttool.llb\Dist Load Script.vi -Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, February 17, 2004 9:32 AM To: [EMAIL PROTECTED] Subject: Application Builder Settings Dump Do any of you have a way to extract the build settings from Application Builder to a text file? I'm particularly interested in getting all of the build settings for front panels that are not removed -- things like has menu bar, modal, etc. Roy Kniskern, Sr. Product Dev. Engineer MOOG Components Group Inc. 1213 N. Main St. Blacksburg, VA 24060 http://www.polysci.com/ (Formerly Northrop Grumman Poly-Scientific) mailto:[EMAIL PROTECTED]
RE: registering a labview built dll
DLLs built with LabVIEW are not ActiveX/COM DLLs and, therefore, can not be registered with the OS using regsvr32. From what I was able to Google on the subject, you can't call standard DLLs from ASP. You will need to create a COM wrapper around the standard DLL, and call the COM wrapper from ASP. FYI, LabVIEW executables can be built (on Windows) with a COM server that includes the ability to execute VIs. Good luck, -Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of André-Philippe Vachon Sent: Monday, February 16, 2004 7:55 AM To: Info-Labview Post (E-mail) Subject: registering a labview built dll I've built a Dll in labview 6.1. Using a CallLibrary node in labview i can call and it works fine. I would like to use it in ASP code. In order to perform this i need to register the Dll. I've tried to create an installer, but still i get an error message when i execute the regsvr32 command. The error says: MyDll.dll was loaded, but DllRegisterServer entry point was not found DllRegisterServer may not be exported, or a corrupt version of MyDll.dll may be in memory. Consider using Pview to detect and remove it as anyone tried and succeed in registering a dll on Win2k? ITF Optical technologies inc. André-Philippe Vachon Senior Software Designer (514)748-4848 #4362 [EMAIL PROTECTED] www.itfoptical.com
RE: Associate a type of file with a LV7 app
Jean-Pierre Drolet has written an article on the subject: http://openg.org/tiki/tiki-index.php?page=File+Handling+Guidelines -Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dany Allard Sent: Wednesday, February 11, 2004 8:07 AM To: [EMAIL PROTECTED] Subject: Associate a type of file with a LV7 app Hi, Is it possible to associate a type of file, like *.txt with Notepad.exe, with a LV7 app. I know that LV7 have a new feature that permit to retrieve the command line used to call the app. But I dont think that would be useful for what I want to do. I want to Double-Click on my file and my LV7 app start automatically and the file is read and displayed. Thanks Dany Allard [EMAIL PROTECTED]
Re: Addressing a scanner from LV
Dave, I think that your best bet would be to access a TWAIN driver from LabVIEW. If you go any lower-level than this, you will need to know a lot more about your scanner than you probably care to learn. Alliance Vision sells a library that contains the LabVIEW / IMAQ Vision Vi's for TWAIN protocol. Take a look here: http://www.alliancevision.com/net/twain/fr_twain.htm Good luck, -Jim David Ferster [EMAIL PROTECTED] said: Has anyone ever tried to access a flatbed or sheetfeed scanner directly from LV? One could have a user make files from the scanner's software and then access the files from LV, but it would be nicer to have the LV app do everything... David -- David Ferster Actimetrics, Inc. 1024 Austin St., Evanston, IL 60202 http://www.actimetrics.com 847/922-2643 Phone 847/589-8103 FAX --
RE: Sub panel size
John, The SubPanel control has size and position attributes that can be set using VI Server. You can inspect the size of the target VI's FP/Controls and adjust the SubPanel. -Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Brohan Sent: Monday, February 09, 2004 1:17 PM To: [EMAIL PROTECTED] Subject: Sub panel size Hello I want to use a SubPanel to hold different sized programs. Specifically I'd like to put the program into the middle of the subpanel. Any Ideas. I am using a small vi with USR to communicate data between teh sub-panel program and its caller. This seems to work fine. The caller decides to stop teh sub panel program and sets a value in a USR. Seems to work even when using build application. Yours Sincerely John Brohan
RE: NI Week 2003 presentation: Managing Large Data in LabVIEW
It's here: http://digital.ni.com/niweekpresentations.nsf/a3153572d74a4dd686256a8e00799 a3c/d367799bdf83d38c86256cf3006235dd?OpenDocument -Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neville Dholoo Sent: Wednesday, January 28, 2004 2:12 PM To: Info-LabVIEW Mailing List Subject: NI Week 2003 presentation: Managing Large Data in LabVIEW Hi, Anybody have a copy of this presentation? Couldn't find it on the NI website. Thanks, Neville Dholoo Test Services Engineer Cellex Power Products Inc. 220-13155 Delf Place Richmond BC Canada V6V 2A2 604 248 3683 604 270 4304 fax www.cellexpower.com
RE: Subpanels in 7.0
Philippe, Actually, an ActiveX container's Value is a reference to the one (and only one) ActiveX control that is loaded into the container *at edit-time* (not a reference to the ActiveX container Control on the FP). When you drop an ActiveX container on the FP you get a Terminal on the BD (not a control refnum). The data (value) that the Terminal will output at run-time is an ActiveX reference to the control within the container. Since a SubPanel can be reassosiated with new VI references and only *at run-time*, NI folks decided not to use the same design as the ActiveX container, and eliminate the Subpanel value (and BD terminal), which would logically contain a VI Reference. However, flowing this data through a diagram in a SubPanel typed wire would be rather pointless, since the VI Reference type already exists. Interestingly, the subpanel, is the only FP control that I can think of which has no data/value (actually, its value is a null variant), and therefore it has no terminal (or LabVIEW suppresses it). Finally, the reason you have an invoke node than a reference is that NI folks thought that you would rather have an explicitly linked invoke node on the BD (for calling directly on the BD of the VI containing the SubPanel), than an explicit Reference (for passing to and calling from a subVI). Regards, -Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of PJ M Sent: Friday, January 30, 2004 1:31 PM To: Scott Hannahs; LABVIEW INFO Subject: Re: Subpanels in 7.0 Scott I am talking about a Subpanel Reference, not about a VI ref. I am expecting a behavior similar to an ActiveX container (drop an ActiveX container on the FP and you get an ActiveX Ref on the BD), PJM Scott Hannahs [EMAIL PROTECTED] wrote: At 09:12 -0800 01/30/2004, PJ M wrote: Another strange thing (to me) is why don't I *automatically* get a subpanel refnum when I create a subpanel (instead of that insert VI method) ? Also, because of that, whatch out for these tranparent supanel with no scrollbar (it is so easy to get more that one on the FP without any indication on the BD). Because the subpanel accepts a vi ref number and not generates it. The ref number is for whatever vi you want to put into it. The subpanel is a sink for references not a source. -Scott Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it!
Re: NI now charging for technical phone support
Maybe the going rate for LabVIEW/NI-HW consultants will go up! :-) -Jim Jack Hamilton [EMAIL PROTECTED] said: A colleague of mine just informed me that NI is now charging for Technical Phone support. Calls are now being directed to the Sale Department. He called today and got the news... (my phone number is now unlisted ;- ) Jack Hamilton Hamilton Design [EMAIL PROTECTED] www.Labuseful.com 714-839-6375 Office --
Re: Autostarting LabVIEW VI in Linux
Jason, I'm not sure if this is your problem, but make sure that X is ALREADY running, or else there will be no display for LabVIEW to use. You ensure this by putting the VI launching command in your X startup script (where the window manager is launched). Take a look at Chs 22-24 of LabVIEW Graphical Programming 3rd Ed for a step- by-step. Good luck, -Jim Jason Dunham [EMAIL PROTECTED] said: I'm using Linux (RH8) and trying to get a LabVIEW VI to run when the system boots up. I added a line to /etc/rc.local, but it doesn't seem to have an effect The line was /usr/local/lv70/labview /home/jason/myvi.vi The computer already boots into a normal X-window session Any ideas or tips? Is there a list of command-line switches for LabVIEW/Linux? Thanks, Jason Dunham SF Industrial Software, Inc. --
Re: Using OpenG Toolkit with base version of LV
Frank, I would recommend modifying your OpenG Package Installer. Simply remove the missing VIs and output default values (null pictures). Then you can use the package installer. -Jim
Re: labview 7 SubPanel Container Question
Great!
Re: unexpected error - why ?
Probably because the Boolean is set to a latch mechanical action. Change it to a switch mechanical action and the error will go away.
Re: Is it possible to pick a point in a graph and drag/move it to another position using the mouse?
Yes, this should work.
Re: labview 7 SubPanel Container Question
I believe that the Front Panel of the VI which is to be inserted into a SubPanel Container cannot already be opened (or already inside another SubPanel Container). To solve this problem, you can set VI.Panel.Open = FALSE just prior to inserting the VI into the SubPanel Container. I hope that works for you.
