Mike Ashe

You might want to search the Info-LabVIEW archives for both messages and code. Here is an old library for LV 3.0 http://www.info-labview.org/the-archives/vi/lv3.0/ On that page look for: gps_nmea.zip and gps_nmea.txt Don't know how well written it is, but it might be a good start. If you improve it, remember to share back with both Info-LabVIEW and the LAVA forums here. Good luck.

You might also want to search the Info-LabVIEW list archives for MySQL. http://www.searchview.net/ Various people have shared and traded MySQL code in the past 2-3 years. Good Luck. PS: As an alternative, you might want to go to the LabVIEW Open Source Tools (L.O.S.T.) at: http://www.jeffreytravis.com/lost/labsql.html This is written to use ADO and connects with any ODBC compliant database. I know that there is both ODBC and JDBC driver sets for MySQL and your can use MySQL that way. LabSQL is free, open source and works pretty well.

If NI tried to do something to prevent you from selling your product, or told you that it was not "authorized" per the license agreement because it competes with their toolkit, then I think that you would have a legitimate beef. But it is somewhat foolish to expect them to advertise your competing product in their newsletter. Market it as best you can and if it gains a niche, great. If not try to improve either it or your marketing, but don't focus on what NI does or might do or not do. I made that mistake for too long myself. You might want to try to write an article explaining hierarchical state machines and use your product as an example, then submit to one of the trade magazines such as Test & Measurement. Good luck.

Hi Ben, First, the bad news: As Alex said, unless you have CVI you cannot currently make the function panel and the LabVIEW CVI->VI function currently only works with function panels. Now the good news: I have been working, in my not so spare time, on a utility to do exactly what you are asking for. Take the external information about the DLL and write VIs to access the functions. At least to populate the CALL LIBRARY NODEs automatically, and then to make the front panel controls and indicators. This is a work in progress and is far from ready for prime time. However, I need a couple of test cases, and if you could email me the .h file, something that has the function call prototypes in it, I will try to use it as a test case and a spur to get a little more developed michael.ashe@imaginatics.net This will be an open source tool when it is finished. Looking forward to hearing from you. Mike

There is a free, open source LabVIEW toolkit for doing exactly what you want. It is called LabSQL and is ADO based. This was actually one of the first open source LabVIEW projects and the L.O.S.T. was/is a precursor to the OpenG project. Go to: http://www.jeffreytravis.com/lost/download/ and download the LabSQL Toolkit. You will get the complete source code, it is free and it works well. Enjoy!

NI has had this ability for years, so they DID do a utility. You can see it in LabVIEW, under: Menu: Tools > Instrumentation > Import CVI Instrument Driver... If you point this to a CVI Function Panel file (*.fp) which lists all the functions in the driver, it will then create wrapper LabVIEW VIs for all of the functions, 2, 10 or 100. It was beautiful to watch the first time I saw it work. It did in less than a minute what would have taken me over a week on one driver. This function is also available in an invoke node, if you know the way to program the parameters. The function requires a CVI.fp, but it should be trivial (relatively) to reprogram to a text file (*.h, etc...) for the function prototypes. The problem with releasing it as a general DLL conversion tool, from NI's perspective, is that you wouldn't have to buy another expensive software tool like CVI, and it would make it too easy for some of NI's hardware competition to quickly produce LabVIEW drivers for their hardware. NI makes good money off software and training (and they deserve it, great products) but they make more (or always did in the past) off of hardware sales. Recall the internal motto: "The software is the sizzle, but the hardware is the steak!" Guess its up to us open sourcers...

Hmmm... if use of the screensaver is intended to drive up someones costs, could not this be construed to equate to "financial damages" and therefore cause salivation in the company's "lawyer on a leash"? Probably not a problem for the rack and file user, but for the original programmers of the screen saver?

Thanks for the post & attachment Jim. Great idea to run a DDS against the spammers. It would be nice to be able to add spammers to your list when they email you. Firefox and Thunderbird rule!

Oh that was cute, and, turned inside out, actually might be kind of useful.

I think he is referring to how to do this with Scripting. I don't think there is a way. If you search for the Private_Class_Generator page here on LAVA http://forums.lavausergroup.org/index.php?...class_generator and run the generator you get refs to all kinds of diagram objects, including the loops. Selecting a while loop ref and constant and wire property and invoke nodes and you don't find a property for setting the color. And this is even with all the super duper secret INI file settings turned on that someone exposed on Info-LabVIEW a little while back. I think we are waiting for LV 8.0 or the Scripting Toolkit to be formally released by NI.

We need to get some of these things into a bunch of subVIs, put them into a pallete with the Merge option on the menu and make up our own LAVA/OpenG Scripting pallete/toolset.

Thanks a lot PJM! This has to be the single best and worst thing I've found on LAVA and OpenG combined. Best because of all the goodies it exposes and worst because, like a really great book, it is hard to put away.... I used this to hack together a little utility that writes the function prototype and parameters to a Call Library Node. The next step is to add a parser for a c/cpp.h file and make a utility that will auto generate wrapper VIs for DLLs, something I have wanted for years. I'll post when I get it finished.

Hi, I have a couple of distributed applications that communicate with TCP/IP. Lots of clients, etc. Development is ongoing. Occasionally I find that a client cannot connect into the server and it turns out that the IP address that LabVIEW sees for the local machine has been superceeded by another IP assigned by some other program, like a VPN tunnel. Has anyone else experienced this, and if so, does anyone: 1. Have a method to automatically detect this in LabVIEW? 2. Have a way to switch the IP that LabVIEW sees, back to the network card? 3. Have a way to prevent LabVIEW from switching to the new address in the first place. Thanks in advance for all replies and code!

Are you returning a "packet XXX recieved" notification. It seems that adding a little bit of info to the buffer you build up (when the connection is down) might workaround your problem. I agree that it would be nice to know why you are loosing the packets, but making your recovery robust seems more important. The reason I say robust recovery is more important is that I have seen multiple ways that LabVIEW's TCP/IP comms have problems over the years. Spurious timeout errors (you set the timeout to 2 seconds and the read VI returns in 50 millisec with a TO error) to buffer overflow errors when you try to transmit to fast. I have run into som many types of errors that I assume that there will be multiple error modes with TCP/IP and implement accordingly. Best of luck!

Excellent tutorial and example. Perhaps a bit of an Open Source toolkit can be slowly built up around this as time goes by. Not sure what NI's reaction to this might be though. Keep up the good work! Hmm, along these lines, it might be useful to have a list of express VIs that people really need or a place in the LAVA site (and/or OpenG) that will start a library of express VIs and VI requests....

I ran into this a long time ago with MCLB. They look great, but sloowwwww..... I ended up using a 2D string array (table now) with some tweaking in the custom control editor to add scroll bars and a couple of VIs to manage highlighting selections, etc, for cut/copy/paste in the table. Fast and efficient. Cheers,

If you have the source code to the C++ side, so as to make modifications... Four other ways would be: 1. Communicate using TCP/IP, simple enough on the LabVIEW end, (YMMV on the C end). 2. Compile the LabVIEW side into a DLL and have the C program call the LabVIEW routine as a DLL. 3. Compile the C/C++ end as a DLL and have LabVIEW call that. 4. Post Windows Messages to the LabVIEW Window Message Queue. If you search on the LAVA and OpenG.net websites you will find Windows Message Queue LabVIEW VIs so you can have LabVIEW listen for Windows messages, notifying it that the boolean needs to be set. Cheers

If the "normal digital camera" has a USB output then you can grab images using a couple of freebie (or very low $) VI libraries that people have posted. Here are a couple: LabVIEW Webcam Library (free) http://www.cs.unc.edu/~parente/labview/ IVision Package (very inexpensive for what you get) http://www.hytekautomation.com/Products/IVision.html Enjoy,

The Probes contributed above are great. :worship: I think it would be good to combine some of this with the Universal Probe that Jim Kring developed: http://www.openg.org/tiki/tiki-index.php?p...iversal%20Probe Combining timestamping with universality and a queued logging mechanism would be very useful.

Thank you for that undocumented setting. This is worth experimenting with. I may have application to a multiple server application.

Here is another slightly modified version of the listbox tab control modify / panel VIs. I just moved the generation of the references outside to avoid memory leaks and added a slight delay in the read loop to allow other VIs to operate. This could continue to be modified to make it more generic (and therefore useful) by: 1. using a tree control to write the values to (with filter options), 2. optional timeing on how often to update the value tree, 3. making a list of VIs running in memory and allowing switching between them So many mods, so little time... Mike Download File:post-45-1096481602.zip

Very cool code! PlugIn Control Has anyone else noticed that the generated tree contains a lot if items that cannot be found in either the palettes or any of the scripting examples/goodies here at LAVA. One in particular intrigues me. under GObject>>Control there is a PlugIn Control listed. I have long wished to be able to add controls at run time as part of a plugin architecture. Does anyone know of anything about this object and its use?

I knocked but nobody was home... :headbang: Still, nifty idea. I second the idea that we should be able to get a list of who is connected. Another nice feature might be the ability to send a private note that is not broadcast. Mike

I used to have a small utility that showed what the mouse position was and what VI it was in. I used it to make similar VIs have essentially the same front panel layout. I think the same effect can be written pretty quickly with George Zou's GToolBox VIs (which are worth several times the toolkit price ~$40.00)(no I'm not affiliated, it's just a good kit). I'll see if I can dig up the utility. Its not a ruler, but... Also, using George's VIs you can give a VI a "skin". This can be dynamic, so I suppose you might be able to put a ruler skin down, use it, then remove before you saved... Mike

Yes, it works, yes it is still buggy. I think there are also some INI file switches that help the usage, but I don't recall what they are. Anyone?