John Lokanis

LabVIEW does not 'normally' run as a console application. So, making it write to StdOut and StdErr is not simple. But, it can be done with some hacking (in Windows). Not sure if it is possible in OSX or Linux.

But, keep in mind that you get one shot at sending in commands. The app must then process those commands, write to the StdOut and then exit. You cannot send additional commands via the CMD console. (search LAVA for a thread on this from last year)

If you need continuous commands to a running application, I would suggest you write a DLL or create a web service interface for your application. The bonus of the web service is you can use something like curl on the CMD line to send and receive data and you can do that from any machine on the network.

good luck!

-John

Just to add some real world experience from someone who has lived on both sides of the fence:

For many years I used Windows PCs professionally and at home (having built many myself over the years). I still use Windows7 at work everyday. However, when our last Dell laptop died, I decided to give the Mac a try. My wife already had an iPhone and I was impressed with the quality and ease of use it offered.

Long story short, we now have 2 MacBook Pros, 2 iPhones and an iPad2.

The first MBP is used for what I call family activities. Photos, web browsing, kids games, school projects. All the things that pretty much any computer can do, but the Mac makes it easier to get done. No extra SW to buy in many cases and very few bug or compatibility issues.

The second MBP is mine. I use it for music production (hobby) and consulting (LabVIEW). I run LabVIEW under MacOSX and in Win7 VMs. Whatever is needed for the job.

The iPad is used as a consumption device. The kids have lots of games and learning software (it is amazing how a 5yr old can figure out how to use iOS with basically zero instruction). I use it for Twitter, web browsing, video streaming, news apps, etc. My wife uses it for email (as noted, you only get one 'user' per device in iOS), Facebook, web and TV. It is a great device when you just want to look up something quick or want to sit on the couch and 'consume' content.

I would never use it to write long docs or even attempt to do real work on it. It is not intended for that purpose.

As for the debate about Apple vs the rest of the companies out there, I will say this: When we were a PC house, I spent a great deal of my time fixing problems with our PCs. Software bugs, HW compatibility issues, random weirdness that seems inherent in all Microsoft software. After switching all that has gone away.

I know a great deal about fixing Windows but I know very little about Unix or MacOSX. Fortunately, the few times I have had to figure out how to fix something on the Mac, it has been very simple to diagnose and correct.

So, if you like playing an IT support person in your free time, by all means get a netbook, Andriod tablet or whatnot and hack away. But if you want to come home from a long day at the office and just use your devices, then seriously consider an iPad.

As for all the comments about Apple being a 'walled garden' I'll add that their garden is 1000x bigger then the rest of the ecosystem out there (as far as apps go) and a wall is not such a bad thing if it keeps out the snakes and bugs and other things that waste your time.

In the meantime, I am patiently waiting for my parents old Dell desktop to die so I can get them to move to a Mac. Then I will finally be able to eliminate 'IT Support' from my list of job titles.

-John

Glad to hear you passed! Looking forward to the CLA summit too!

You can always write your own. Most of what you want is available via VI Server.

Subtle race conditions can be affected by recompiles. So, sometimes it works (and works every time) and then after a recompile, the code is executed in a different order (like if you edited the block diagram and caused the compiler to rethink the compile order). Suddenly, the code does not work because the intended flow 'loses the race'.

That is the joy of LabVIEW, There is no such thing as a syntax error but there are plenty of opportunities for race conditions to bite you in the behind.

(BTW: that is why in my opinion EEs make better LabVIEW programmers than CS majors. We just naturally think in terms of races and not syntax.)

Here is a way to make something simular, but with the ability to be set at runtime.

http://lavag.org/topic/7174-a-labview-worm/

This has the advantage of letting you globally set a reference that the RTE generates when your app starts.

I am looking for a list of and/or links to all the different architectures that have been proposed/shared in the LAVA community over the last year or so. I want to do an investigation of each and see what features I want to incorporate into a application template I am working on for my company. I have been searching the forums and found many, but I would like to make sure I have not missed any important ones. So, if you have authored one or know of one, can you post a link to the thread on LAVA or the NI forums or wherever else we should go to learn about and download your design?

Personally, I am interested in ones based on OOP but please feel free to post links to ones based on QSM, Events, traditional state machines or any combination thereof. I hope this thread becomes a launching point for anyone looking for information on architecture ideas for LabVIEW.

thanks!

-John

This is a real pain and gives no indication whatsoever where to look.

You get it after building an application exe that works fine in the IDE and usually find that a diagram disable structure somewhere isn't doing what it says on the tin.

You also get this if you use some .NET assemblies that are missing on the target machine. Took a LONG time to figure that one out!

Thanks guys! I use this 'fire and forget' method in a lot of my code. This new node will certainly help clean my diagrams up!

I have a slightly different question about the CBR node. If I want the VI to run and dispose of it's own reference, how do I tell it to do that (I will not be calling the wait node since my VI returns its data via a queue).

thanks,

-John

I had no problem. Just had to make sure I en-queued for the bus before everyone else!

Hope everyone liked the panoramas!

Execution Details

This node exhibits the following execution behaviors:

• Does not require the user interface thread to be idle

I can't tell you how happy this makes me. No more will my users be able to 'pause' dynamic VI launching by dropping down a menu and not selecting anything...

Pretty cool. Wondering how to integrate this into the IDE...

One issue: for some reason, when I open the project, LabVIEW opens 4 new (untitled) VIs while the project loads. Other projects don't do this. Any ideas?

So... This is not possible then? Or nobody has tried it yet? <cricket> <cricket>

emphasis on the 'relatively'... Some of us come from much cooler climates...

I want to allow the user to rearrange the columns in a multi-column listbox by dragging and dropping the column headers. Anyone already done this? If so, can you share the code?

thanks,

-John

Or, you could do something like this (if you are using Windows OS):

If you need the IP address, get the AddressList from the IPHostEntry, index the first element and use ToString to convert it to an IP string.

Finally got around to signing up... Now if the NIWeek PO would just clear...

You must install your web services on the target. So, once you build your exe and your web service (lvws), you must build an installer and have it install the exe and the web service. Then, after you run this installer on the target PC, the web service will always be up and running.

the default port for the Application Web Server (the one that hosts user generated web services) is 8080. So, all your calls must point to this port. You cannot assume the default port 80 will work.

You can change this in the settings for the application web server on the target after you install, if you want. You could even make a batch file that the installer runs at the end to do this change automatically.

I just decided to leave it on port 8080.

good luck!

-John

Is the SQL ADO driver provided 'faster' for SQL Server based calls over the NI DB Toolkit version?

Is LabVIEW 2010 SP1 any faster with .Net 3.5 than in previous posts in 2008 with .Net?

The first example I posted that uses the C# DLL is way faster than the NI toolkit (at least the version I tested it against. They might have improved it since then).

You could easily adapt the ADO version to use the techniques in the SQL Server one. You would just need to modify the C# code to use the right assemblies. The key thing to the speed improvement is the way the recordset is returned to LabVIEW from the .NET memory space. One limitation of my version is all fields are treated as strings.

I have not seen a speed change in .net calls from LV2010. They did fix some stuff between 8.2 and 8.6 I think. Not sure where the change was done but it was really messed up before.

We have many 1000's of hours on this code with no problems. Just keep in mind the workaround in my code for the .net bug. If the SQL query length causes the string in .net to cross a memory boundary, .net will throw an error because it loses the null at the end of the null terminated string. New release of .net fixes this but LV2010 uses the old version. LV2011 *should* fix this.

good luck!

If you need ODBC based access, try this code. It does not solve the record-set transfer issues, however, but you could adapt it using the techniques in my SQL server code.

ADO.NET.zip

Don't give up on .NET. it does offer a lot of advantages over COM.

Here are a few VIs and some C# code that might help you out. I do not recommend using LabVIEW to retrieve a record-set directly. There is a large penalty for using an enumerator across the LabVIEW<->.NET boundary. That is what the DLL fixes for you. There is also a fix in the VI for a bug in .NET 3.0 and earlier (it was fixed in 4.0 but we have to wait for LV2011 to use it). This involves strings that cross a memory boundary.

Open:

SQL.NET Open SQL Server Connection.vi

Execute SQL:

SQL.NET Execute Database Call.vi

Close:

SQL.NET Close Connection.vi

C# DLL and source:

C# SQL DLL.zip

The source of the C# solution to moving data from .NET to LabVIEW came from Brian Tyler (the former .NET guru at NI, now at MS). Take a look at his blog posts:

http://detritus.blog..._vs_arrayl.html

http://detritus.blog...ng_the_arr.html

Hope that helps!

-John

Bummer dude. I guess it comes down to knowing what they want you to say and not what is the correct answer. I know on my CLD and CLA tests I used the most simplistic 'old school' way to solve the problem instead of how I would build it in 'real life'. NI's training and certification testing is at least 10 years behind the rest of us who build real LV solutions everyday.

So, CLD/CLA top tip: Be smart, do not be clever.

Oh, and demand a do-over. I think Steve will be happy to help you out there if you ask.

-John

ni.var.io allows forcing outputs via property nodes but does not allow them to be read back. The shared variable VI reject a URL that uses ni.var.io. They accept ni.var.psp. Also, you cannot browse for anything under ni.var.io.

Looks like it is time to call in the big guns at NI.

BTW: I was able to get it to work somewhat by adding a 300ms delay after the write and adding a delay before the close. But, the value does not 'stick' in the DO. Once the close is called, the value reverts to false (off). If I remove the close, the value reverts when the VI stops. No idea why it wold 'latch' the value.