Leaderboard

Greetings, wireworkers! Michael Aivaliotis and I are teaming to co-host a new monthly web show -- VI Shots Live (http://vishots.com/live/) -- where we invite special guests to talk shop and tell stories about the business of software engineering with LabVIEW. This show is streamed live, and you can watch using the link above. Episodes are recorded, and the archive will be available also at this link. As a live viewer, you can ask questions that we'll answer on-air. The Pilot Episode airs this Wednesday, 29 January 2014, 12noon CST (18:00 GMT). We're quite excited to be talking with Christopher G. Relf (Chief Architect at V I Engineering, Inc, a National Instruments Platinum Alliance Partner) and Darren Nattinger (Principal Engineer, CLA, LabVIEW R&D). The topic is on building sustainable careers with LabVIEW. Hope to see you there! Again, the link: http://vishots.com/live/

The ref num goes around the loop but the error cluster goes through the loop and then to the two Close Refnum nodes. At least that is how it looks in the picture. Maybe the real wiring is behind the loop but that would be a major style fault. Unfortunately the VI Snippet resource seems to get lost between posting to LAVA and downloading it to my computer, so can't really check it.

Very interesting !!! Any Chance to have it in 2011 version ? Regards Eric

Not specifically LabVIEW but I'm a fan of DisplayFusion. I've seen alot of LabVIEW developers use multi-monitor setups and having quick shortcuts to moves windows between monitors is nice along with multi-taskbars. Custom Quick Drop items. Several of the more popular ones. Custom scripting functions that I put in the Tools menu. Simple things like Array to Enum, and Configure SVN with my settings, or setup LabVIEW.ini a specific way. I don't think I've ever had just a single version of LabVIEW installed on my main development machine. Things like the custom LabVIEW icons help differentiate between versions. Abort All VIs function. Variant Probe. WinAPI functions. How much time has been lost by accidentally opening a 2011 project in 2012, and clicking save all, only to realize it later. SCC helps but it can still be a problem. I use a updated program similar to my old LabVIEW Tray Launcher which high jacks the execution of .vi files. Also adds an Abort All VIs, Launch LabVIEW (version specific), and Kill LabVIEW (version specific).

I detected that Mercurial has a commandserver/pipe interface, after some debugging I got a stable 38 msec per call for the most basic call, (coming from 150 msec) so that speed improvement is pretty good. Here's the code I ended with: Do you know what the overhead per dll call is? Ton

Ton, How about using the following process, for controlling any third-party executable running on cmd prompt using WinAPIs: 1) Get the third party window handle by using GetWindowHandle API. 2) Use AttachConsole() API from kernel32.dll - This would make the third party console controllable through LabVIEW 3) Use GetConsoleScreenBufferInfo() from kernel32.dll, with which you can read the console information 4) Use another function (can't remember the function name) which would write to the console 5) Repeat Step 3 and read the output for the written command in step 4 (you might need to do some string parsing to get the desired output) 6) Use FreeConsole() function from kernel32 again, to free up the console at the end of the application. This way, you don't need to redevelop the third party app in labview, rather you could re-use the cmd prompt with this method with labview and have control/read data on it. I am planning to make a small example of this and post it very soon. -FraggerFox!

or write a LV app that query google constantly about LV... PJM