Ton Plomp

One option is to use a Issue tracker (or bug tracker), like Mantis. NI offers the Gateway tool for this, but i don't know if it can track to the VI-level about a state of the VI. Ton

Pravin, sorry I don't have an answer for you, but you should look at the IMAQ toolkit which has several functions for character recognition. Others, please, what kind of replies are that? Is that how we react these days to such a question? If you don't want to provide an answer, then don't answer it. Ton

Oh, yes I remember I must have some quick-basic code lying around that makes a Cellular Automata (just the basic 1D ones). Way back on a 286/386. Perhaps interesting to port that code to LabVIEW. Ton

This is quite interesting. January first 2011 a poll will be started that includes the input from this thread to decide what the best design feature of LabVIEW is. If you have any ideas left, please post them! Ton

This is quite interesting. January first 2011 a poll will be started that includes the input from this thread to decide what the worst design feature of LabVIEW is. If you have any ideas left, please post them! Ton

Running my SystemExecTimeOut.vi makes my LabVIEW installation very very buggy, it is very prone to crashing (almost every run), so I guess I let the function go. Ton

I meant that ignoring such a basic feature (auto-tool) that is very good (I mean very good) just because you don't want to spent the time to use it, is like being Apple (or NI in some cases) wher they ignore the popularity of basic things of life (like a right mouse button for a long time. In hindsight I might have been a bit harsh in that comment. Anyway, it's good that there are several bad things in LabVIEW. Ton

Yes, almost.

Yes that runs without an error since it doesn't time out (it returns before the timeout is exceeded), you could alter the cmd string to "ping www.google.com -t" that will ping until the cmd is terminated. Ton

I try to use the standard LabVIEW systemexec.vi with a timeout and wrote a little wrapper around the VI: However this is not functioning as expected, the AbortVI returns an error 1000: The only thing I found was a thread of last year, that concluded in a taskkill. EDIT: At the dark side there is a discussion. This has a solution where the command is run asynchronously and the output is written to a temporary file that is read the function times out, not something I am looking forward to do. Anyone ever looked at this? Ton

Yes, I use the default mercurial (HG) commands to interface with Mercurial. Removing the compiled code from the VI definitely creates less merges. But the LabVIEW merge utility (LVMerge) is quite good. And yes, Mercurial is no silver bullet in this case, it is however important to limit the number of branches and merges (but that goes for textual code as well). Ton

XControls. Ton

XControls are your friend sir. About the probe dialog, what I don't like is the fact that the new dialog gets focus after creating a probe. It's a major step back in quick debugging (and that for a prototyping language): A VI with unforseen outcome Drop a probe hit ctrl-r (run) nothing happens .... Oh yes, the probe dialog has focus Switch back to VI hit ctrl-r find bug Ideally that would be a 3 stepper. Don't reject the auto-tool! You are like Apple (who needs more than one mouse button?) Ton

This is fixed in LabVIEW 8.6 Ton

Looking at your process this would mean the reuse user placed vi.lib and user.lib under SCC as well? Ton

Good info, could you create a page on the LabVIEW wiki, have a look at the Mercurial page for an example. Ton

In my book Built files do not belong in SCC, for mercurial I excluded the following items from scc: .ogp$ /built*$ built /build*$ .lvlps$ .aliases$ .zip$ This prevents OGP and zip files as wel as built/d folders to get automatically added to SCC, I can add them manually (hg add ......) Ton

I doubt that you can run LabVIEW (IDE) on that platform, officially Debian is not supported by NI. Running a Linux LabVIEW executable might work, but that really depends on what you want to do, remember that hardware support (serial for instance) is very hard to get working on debian platforms. Ton

Two things come to mind: Paths, things in the user.lib (or vi.lib/instr.lib) have an aboslute path, moving a VI that uses one of those functions isn't going to force a re-linking. This means I can have my code under SCC in d:\sourcecode, my colleague can have it on his USB-drive at f:\code. Which also means it's easier to setup a coherent IDE, just install the packages in a manner you like (copy, VIPM, install with NI installer) and you have them where you expect them QuickDrop The items show up in a quick drop search (which can be very usefull) The other advantage is the thing you allready mentioned but (IMHO) is very important, you can easily access them. It's possible to browse them through the palettes. In some of these dying seconds of the day (when the coffee isn't ready yet, a download is going on, facebook is offline, whatever) you can go through them and see if any of your colleagues has writing a little gem, he mentioned but you weren't listening. Ton

Could you post that VI? I only see a screenshot of some code, but there is no typecast in that piece of code. Ton

Good post! However I don't think you'll succeed in retrieving the list of VIs remotely. From the help from the property All VIs in memory: The following table lists the characteristics of this property. However I would love to be proven wrong. Ton

Here's a little snippet on how you can use this code: Ton

No, that's not what I meant, I meant 'double click to open with TC'. Any ideas on how to mange 'Top Level VIs' ? Ton

This is absolutly super! Duper. Kudos, to you Vugie! One question, is it hard to tweak the usage to 'standard' behaviour (double click to explor). I once looked at building such a plugin, but never got through the TC documentation. Ton