Jump to content

Troy K

  • Content Count

  • Joined

  • Last visited

Community Reputation


About Troy K

  • Rank
    LAVA groupie
  • Birthday 12/16/1973

Profile Information

  • Gender
  • Location
    Melbourne, Australia

LabVIEW Information

  • Version
    LabVIEW 2015
  • Since

Contact Methods

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. OK, now I've tried 4 different ways: 1 Test DVR data retention All in1.vi (As picture above) - works OK. 2 Test DVR data retention subvis.vi (As above but using subvis) - works OK. 3 Test DVR data retention fgv not dynamic.vi (DVRs stored in FGV) - works OK. 4 Test DVR data retention dynamic.vi (Data generated and added to FGV in dynamically called subVI) - FAILS (as neil said it would). My tests were in LabVIEW 2011SP1 & 2012 Test DVR data retention.zip I'm guessing the LabVIEW compiler decides that the DVRs created inside the Dynamic VI can be released. So as long as I don't try
  2. Are you sure? I tried to confirm your statement but it seems to work how I expected it to. Here is my test VI (I'm assuming an object in a DVR will behave the same). I profiled the memory usage of the VI and it showed just over 8MB, equivalent to 1 of the waveforms. This is what I anticipated. The profile performance tool can't capture the data stored in the DVR, only the reference itself. So even though I generate a total of 200MB of data, it only ever peaks at 8MB at a time because only the data from 1 element appears on a wire at any given time. Even though I didn't think it would make
  3. DOH! Just when I thought I was beginning to understand it. Back to the drawing board.
  4. Yes you are correct. I agree. I realise the low priority thread requires a copy. However you'll note that in my original post I stated my second objective as "reduce data copies", not eliminate all copies. Again, I agree with you. I was hoping readers would recognise that by saying "passing wires through the application" I was referring to a traditional LabVIEW programming methodology that had an increased likelihood of creating data copies when branching wires. The LabVIEW compiler is a very complicated beast and very few people would attempt to predict exactly when a data c
  5. Thank you all for your valuable input. I'm glad I asked here. So far no replies on forums.ni.com. Good suggestion. We are already doing the analysis part for one measurement type within the FGV. The reporting function writes xml, saves graph images, saves the tdms file and then zips it. This is done in a separate low priority thread so the next test can be started without having to wait. The report target folder could be on a network share slowing down the process. That is why I kept it separate. If I use a temporary storage TDMS file it will have to be on a local drive to keep it fast.
  6. Is LVOOP like Pandora's box?

    1. Michael Aivaliotis
    2. Aristos Queue

      Aristos Queue

      I can see the comparison, but Pandora's Box had positive air pressure. LVOOP has negative air pressure -- it sucks evil in rather than spewing it out. Once it is encapsulated, it's much easier to deal with.

  7. [cross posted to forums.ni.com] Greetings LVOOP masters. I realise this is not a simple question but I would really appreciate your opinion please. I'm trying to make some data handling improvements to a test sequencer application that I've written. User defined tables determine how much data is acquired. Long tests can easily generate 100's of MB's of data. Collecting, analyzing, reporting and saving that data tends to create copies and we can easily run out of memory. It's currently written without any LVOOP methodology but that is about to change. I'm new to OOP but have been readin
  8. OK so I worked out what I was doing wrong and now dont need the intermediate dll any more. So now the C source code isn't needed any more (in fact I had lost it)... Not that the debate it triggered wasn't interseting. Turns out I had the call library function node set to use 'C' calling conventions when it should have been set to 'stdcall'. Still the same link but the content there is now updated.
  9. Sorry to resurrect an ancient thread, but in case anyone is searching for a solution to this it can be found here. I cheated and used an intermediate dll. https://decibel.ni.com/content/docs/DOC-30180
  10. Had a quick go at making your VI_Modularity_Index.vi recursive. (In LabVIEW 8.5.1) PS. Thanks for the undocumented feature. Very handy if you don't have LV Professional!
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.