JohnRH

Great idea! :thumbup: This is even better than my original plan! Thanks! I'd buy you a beer at NIweek - but won't be able to make it this year. (too much work)

Although I am hoping someone has some insight into this matter - this might be considered more of a rant than an actually request for help. I thought I'd like to 'simplify' the installation of multiple built applications on one computer by first installing the LabVIEW runtime engine, then simply copying the .exe's. To do this I downloaded the entire LV Runtime installer (over 30MB!) then installed it on a couple test stations where I'll be running several LabVIEW applications. I then copied a few executables onto the desktop and tried to run them. I immediately got the following error: Error -1073807202 occurred at an unidentified location Possible reason(s): VISA: (Hex 0xBFFF009E) A code library required by VISA could not be located or loaded. Since I do not have an installer for this particular application, I ran an msi installation of another unrelated application, which causes the first application to start running fine. (both of these applications use VISA based serial IO) So ... I am guessing that the regular LV Runtime installer does not install VISA the same way that it gets installed when included with a built application? Perhaps I am missing something but I really don't understand why installing the runtime engine separately shouldn't work. For this to work would I need to do a separate 40+ MB VISA installation? (you would think that at 30MB - the runtime would include VISA serial IO capability) I must have assumed wrong. Oh well - I guess it's back to building installers.

Wow! I certainly came to the right place! Thanks for the help and the examples! The "Launch Generic Process VI.vi" will come in very handy! :beer: Cheers! :beer: John

What I am trying to accomplish might be kind of difficult to explain, but I'll do my best here. When launching a 'process' using the "Run VI" method ("Wait until done" set to FALSE) - how would one go about passing information to this process that is needed for the process to execute? For example - if I have a process that handles serial communications on a COM port - how could I specify which COM port to use at run time? I'd like to launch the serial IO process using the "Run VI" method, but it doesn't look like we can pass data directly to it's controls. I've thought of setting a value in a global prior to launching the process - so that the process could then read that value to determine what COM port to use. I just think there should be a more elegant way of doing this. To make this even more challenging, what if I'd like to launch multiple instances of this process - where each instance handles a unique COM port? (would it work if I just made the process vi reentrant?) Any ideas? Thanks!

I'm in.

Bryan is right - examples are a great way of learning this stuff. here are some really basic concepts: - use the VISA "Open" function to open a connection to your serial port - use a VISA Property Node to set perameters such as your baud rate - use the VISA "Write" function to send commands to you instrument - use the VISA "Read" function to read results back from your instrument - use the VISA "Close" function to release your serial port attached is a REALLY simple example you will find the devil is in the details, but if you can find some documentation is should help. You really need to find out what commands to send to the instruments, and in what format to send them. Also you will need to find out what to expect back from the instrument. To make 'drivers' out of all this, you would wrap each of the VISA functions in you own custom VI's that automatically issue the correct commends etc. hope this helps get you started! John H.

I work for a company where we are contracting out some LabVIEW development work (since we can't seem to find anyone to hire). For the applications we need developed we REQUIRE the source code. The main reason for this is simply that we have programmers who are capable of supporting the software, and don't want to be dependant on an outside company for future support/upgrades. (The only reason for contracting out in the first place is due to lack of manpower.) I'm not sure about other companies, but Data Science Automation seems to be very willing to provide source code for the applications they develope. Obviously there are agreements to sign for this kind of thing, but nothing that would prevent maintaining and upgrading the software on your own. Keep in mind here, the software I am talking about is for in house use only - not for re-sale. Just thought you might be interested in a customers perspective. John H.

You might want to call your Inside Sales Rep at NI. If you haven't recieved your SSP upgrade yet then you may be the victim of a 'small' problem they had when mailing them out. A database used to print the mailing labels got messed up somehow, and the names and addresses didn't match. Fortunately the people in our receiving department know me well enough that when they saw packages from NI addressed to people who don't work here they gave them to me anyway. Also, it looks like some of the packages may have been re-sent since I got a second set in the mail just a few days ago. So you might recieve the SSP shortly anyway. When I called NI about this, they were very quick to point out that it was an outside company that messed up - not NI. John H.

Another option (not necessarily better) is to convert the variant back to a cluster then just bundle the new value. Of course this requires the cluster constant which then requires you to make it a type def (for 'safety'). Maybe not worth the hassle.

:worship: I like it!

You touch on some interesting point. There has certainly been a little 'bad blood' between NI and MCC for some time. Their specific targeting of NI is a good example. Another example would be the "White Paper" MCC wrote, basically accusing NI of misleading advertising. However, it always seems to be MCC going after NI - not the other way around. (just a reminder - as Mike already mentioned. It is MCC that filed this particular lawsuit against NI) So if NI is really going after MCC, did they bring it on themselves?

I agree - as long as 'protecting' patents doesn't turn into simply trying to eliminate competition. One could argue that copying music is simply stealing, but to apply the same argument to the SoftWire/LabVIEW lawsuit is stretching things a little. To me, SoftWire and LabVIEW appear to be very different from eachother. One is a way to graphicly program with Visual Basic, while the other is esentially a new programming language altogether. If SoftWire infringes on LabVIEW's patents, then what is the next product that will infringe? What about UML diagram editors that automatically generate code? Where do you draw the line? Drawing diagrams is an intuitivly human way of communicating ideas, and programming with diagrams is such an obvious evolution for programming that no one company should have exclusive rights to this method. (in my opinion) But, when it comes right down to it. The details of the patents are not as simple as just programming by drawing diagrams, so NI might actually have a case. Not having the expertise or the patience to review the patents in detail, there is no way I can know this. It will be interesting to see what happens. Thanks for the input!

Also, since I'm sure Mr. Bailey won't mind. Here is the email we exchanged yesterday: And his response: To be honest, my only concern is the effort to "prohibiting NI from continuing to sell LabView" as Regis pointed out. All this dialog is very interesting and educational, but unless we can make a difference regarding this very specific threat, it almost seems like a waste of time.

I finally got a response from NI:

It makes sense that the change in NI's support policy would result in a greater need for forums such as this. At the same time, I see a need for NI to perhaps make their new support system just a little more flexible. The circumstance I am thinking of is similar to what you previously mentioned. In my case, our company owns multiple SSPs to multiple software products, but they are all registered in my name - regardless of who is using it. I am responsible for maintaining all the SSP's, and registering them all in my name makes this easier. It would sure be nice if we could register the users seperately somehow. (for how much we spend on NI software, and how little support we actually require - it ticks me off a little that I am the only one that can make a phone call)John Howard

Maybe I'm just dense - but differential equations and vector calculus seemed less intimidating than this patent law stuff. Must be why the lawyers get the big bucks.

I still haven't heard from NI. Maybe I am approaching this wrong? Here is what I wrote:

I've sent one more 'request for clarification' to NI. I'll post here when (if) I get a response. John Howard

I've sent a few emails to both Softwire (Measurment Computing Corp.) and National Instruments management, regarding this legal action. First it was because I was angry with MCC, then based on their response I was a little angry with NI. Now I don't know what to think. I am posting the email dialog here in cronological order for those who are interested. At one time I had the crazy idea that we might actually be able to convince one or both companies to back off, but now it seems that they are both determined to see this legal action through to the end regardless of consequences. This is a fairly long dialog, but I learned a lot from the responses of both companies, so thought I'd pass them along. Here is my first email to MCC managment: Response from Ben Bailey (MCC Founder/CEO): My response to MCC: Mr. Bailey's second response to me: My first email to NI managment: Response from Peter Zogas (NI's Senior Vice President of Sales and Marketing): My final email to MCC: MCC's most recent response:

The following seems to lead to nasty errors and finally a complete LabVIEW crash. 1) drop down a 3D gauge control 2) right click gauge, select "Properties", and Add two more Needles (so the gauge now has 3 needles). 3) click OK It appears that this bug shows up on any numeric control which you can add multiple pointers to. The work around is to add one pointer at a time, either in the properties page, or by right clicking on the control and selecting "add needle...".