JamesMc86

I've been using LabVIEW Task Manager - http://lavag.org/topic/18322-cr-labview-task-manager/ Not sure how useful it will be to spot them though, good if you need to get at one you know is running but I think they will all remain at runsub state if loaded.

It is possible to get around that by using event callbacks. It is intended for activeX and .net support but seems to work with internal LabVIEW events without issue. I used it to be able to set up dynamic binding for an MVC framework - http://www.wiresmithtech.com/mvc-in-labview-library/ In my case I'm not using OO to change the response but you could make the callback method a static parent method and then have a dynamic dispatch core VI inside (I don't think you could use dynamic dispatch directly).

Hi All, OK, so the titles a bit vague as I have yet to figure out the correct terminology for this. I'm working on an app with a couple of areas at a high risk of change/versioning. In essence it comes from the fact that there is a central server and 100+ distributed nodes collecting data. As time goes on, features are added or changes are required on the nodes and we need the servers to be able to support the new version but also any older versions that are out there. Examples of what I mean are: Communications protocols could change as the networks change and support improved methods. File schemas almost certainly will change as firmware gets upgraded to capture different measurements or values. What I haven't managed to find yet is recommended design patterns for handling these changes. The obvious one is to take advantage of dynamic dispatching although I have concerns about the two obvious methods I can see of doing this: You can create an abstraction layer and have all version be a child of this, however we don't know which sections will change and could end up having to repeat code in each child, which leads to: v1 is the parent, v2 is a child of v1, v3 is a child of v2 and so on. This seems like the natural way but I have seen some concerns over performance of deep heirarchies and I may end up still fudging sub-versions to avoid creating a new layer for smaller changes. I'm simply curious, are there any known good patterns out there? How have you managed with similar problems in the past? (I'm certainly not going to be the first person!) Cheers, James

Hey Lewis, Bad luck, my functionality score was pretty low in the end as well which meant I only scraped it! I didn't start from a sample project but I did generate one and nick a couple of useful subVIs, I think I used a watchdog from one to try and save time. Cheers, James

Congrats Neil! I also got mine through and passed, just!

This method may work well for you but just note a global variable is not deterministic, from LabVIEW help:

Hi Alex, SUre it was a new feature in 2012 I think. The DVR is created in the RIO driver and is really intended to be fired straight into the TDMS function. The help page is at http://zone.ni.com/reference/en-XX/help/371599J-01/lvfpgahost/fpga_method_fifo_acqread/ but can't find much else. There is an example of it under Hardware Input Output>>FlexRIO>>High Throughput>>High Throughput Streaming.lvproj One thing I have never worked out is that everything references it as an "external" DVR but I never found any documentation about what this differentiation means. The one important comment is that it must be deleted before the driver can acquire more data, it must be this. Cheers, James

Hi Alex, I suspect it's not quite true but there are a couple of shortcuts. As long as you are reading data into your application there is CPU intervention then. There are a couple of techniques with TDMS where this doesn't happen, I don't think it is direct DMA but it is lower level: Using the DAQmx logging the data is logged in the DAQmx driver layer rather than your application, it is also logged as raw data with scaling information making it very fast. You can read a DVR from FPGA targets instead of data and there are corresponding write functions for TDMS which can mean better performance. One thing I would say for your situation either way is that TDMS files don't do great with being streamed at different rates, it keeps rewriting the header portion causing the file to be fragmented which means worse write performance and file sizes increase rapidly. You may be worth keeping them as different files anyway. Cheers, James

I've always avoided Ubuntu as the LabVIEW installers uses rpm based installers but ubuntu uses debian packages. It is theoretically possible, from memory I think there is a program called Alien or similar that allows rpms to be installed to ubuntu and I know someone tried LabVIEW with this somewhat successfully. Alternatively any of the supported should work (Red Hat, OpenSUSE, Scientific Linux) or RPM based shouldn't have major issues. Believe I have had success in the past on Fedora, CentOS and Manjaro (Fedora and CentOS are closely related to RedHat, Manjaro was luck! but had some font issues)