Leaderboard

So one would think, but actually one can use a network-published shared variable even in a time critical loop on RT--as long as one configures it to be RT-FIFO-enabled. Then LabVIEW is smart enough to wait to do the networking part of the operation outside the time-critical loop. (Of course, there will be jitter in when the remote recipient gets the data because of the networking, but if this is OK for your application--as it is for ours--then this works fine. One of the folks at NI recommended I do it this way a couple years back, and it works.)

Reminds me of the Al Gore "hocky stick" graph. Are we also responsible for increased global warming since 2000?

The Code Capture Tool 2.1.2 has the option to back-save the snippet in an earlier version. Download it here (LAVA) or here (SourceForge). Ton

I haven't look at it in detail yet, only had a quick play when it came out as I had to demo it, but in LabVIEW 2009 (or rather DAQmx 9.0) the new TDMS API (2.0) is integrated with DAQmx. The increased speed is attributed to not having to go through the TDMS, LabVIEW or OS buffers, essentially data goes from hardware to HDD. See here, as it mentions logging raw data to reduce file size footprint. Reading out the data should still come out scaled. Worth checking out methinks? Cheers -JG

Hi LAVAs, I already picked the curiosity of some of you guys with this Open Office Report Generation toolkit. So here is a snapshot of what's gonna be made accessible shortly through the Code Rep. But most importantly, I'd like to know what would be useful for the community. I'm having a design decision to make at the moment and I want to get people's opinions. The toolkit will be based on AODL, a .NET API for Open Document Format. It's still in beta (v1.3) and includes only Text Documents and Spreadsheets, but it's a complete interface. It's a complicated API, but after spendig a few days poking around it, it's a quite simple mechanics. I'm building this toolkit with LVOOP. For the moment, the "Basic" palette is taking form: * Init Document * List Styles * Add Text * Add Table * Add Table of Content * Add Image * Save * Load * Dispose() To be used somehow like this: That's fairly straightforward. Where it gets a little more complicated is that I'd like to propose a true API to extract one part of a document and modify it. For that, each token that is constructed (Content of document) needs to be done by first creating the empty construct with the document reference as input. I haven't found a way yet to create content without first assigning a document reference. (i.e. I would like to find a way to create it with an empty reference and change that reference later on when I decide which document I want to add this content to.) This constraint quickly adds a bad feel to the whole exercise... What a spaghetti! So I might solve this problem by creating an active directory a FGV of current documents references (provided there are many) and each new content class (i.e. Create Empty Table) would be provided a Document Name to search the reference in the directory. This allow addition or modification of content in a State Machine. I can see why some people would not like this idea because it clearly breaks dataflow... but since the .NET API is by-reference, perhaps it's an acceptable compromise. The final toolkit would include some Advanced palette to edit, insert before/after, include content inside other structures recursively, and the like. My initial tests with LVOOP indicate this could be quite versatile and expandable as the AODL (An Open Document Library) is extended. Any thoughts on this? I'd like to hear your design advices as well as any requested features for the first draft. PS: BTW, this AODL API is great. You can create reports without OpenOffice being istalled on the machine! I still haven't looked at the "Save as DOC file" yet, but it shows promises.