Mellroth

Do you want the application that you have written to load when you double click the *.dat file, and directly start processing the clicked *.dat file? If this is what you want, please checkout the link http://labviewwiki.o...indows_Explorer /J

Hi A others already have stated, the host VI is probably where you can gain the most performance by simplifying the code. The FPGA VI seem to be pretty straight forward, but as Hooovahh said it depends on if you are planning on repeating a specific signal, having On/Off functionality etc.. Comments to simplify the code; 1. why store each AO waveform in separate files? TDMS is well suited to have multi-channel measurements in one single file. If you can have a single file instead, you'll gain a lot of file reading performance since only one file pointer is managed, and data is correctly formated directly out of the TDMS-Read function 2. why are you configuring the FIFO in each loop iteration, this should be done before you enter the loop 3. the same goes for the FPGA start, this should be done before the loop starts. 4. don't split the files in smaller chunks, this will get you a lot of overhead opening and closing files all the time. Instead you should read smaller chunks of data and while you are reading the next chunk to be transmitted, you write to the FIFO in parallel, i.e. you can use pipelining in Windows as well as on the FPGA (as sachsm linked to). 5. When reading the TDMS files you can specify the data type directly, this will clean up your diagram and get rid of a number of nodes. 6. The code currently autoindexes the error output constantly growing an error array, this will also decrease your performance. Instead use a shift register to pass around the error, and act on the error correctly. /J

I agree with Shaun on this one, the best is probably to stream data to disk. If you go the memory path anyway, be aware of that having all data in one array might fail due to that there is not enough contiguous space in memory, even if the reported amount of memory is enough. Having many smaller arrays are therefore less likely to fail. /J

I have a similar issue with NSV:s and RT. If the RT application is executed from development environment, everything works fine, but if the application is built into a rtexe and set as startup the application is broken. If the rtexe was built with debug enabled and I connect to the rtexe, the panel displays a broken arrow but no information about what caused the application to break. I've tried the delay before accessing any shared variable, but it is still the same. The only solution that seems to solve my issue is to replace all static NSV:s with programmatic access. Lucky for me I only have 5-10 static NSV's in the application. /J

Hi, If you want to stream data to disk as fast as possible, you must know the block size of the harddrive, and write data in chunks with size that is a multiple of this block size. The reason is that RT does not use buffering (probably the cause of error 6), and it must therefore read the old block before writing a partial block to disk. So, writing partial blocks to disk results in unwanted disk access as well as decrease in performance. Hope this helps /J

Hi If you are reading files with "unknown" formatting, there is no need to use the "Binary file" functions, just use the "Text file" functions but disable the EOL conversion. Personally I don't use the binary versions unless I have to read/write values that are to be displayed/handled in LabVIEW, and then you need to know exactly how the data was stored (byte order?, size prepended? etc.) Using the "Text file" to copy data from end to another have never failed me. Don't forget to escape the special characters during the RS232 transfer, or are you prepending length information to the transfer? /J

Hi, Even if you convert to a newer LabVIEW version I think you will still have to do some major redesign; In the picture posted in response to Bens question, you are entering the loop with both the complete cluster as well as an individual cluster element. Doing so should force LabVIEW into copying data. /J

Hi, I might be missing the point, but if you put a graph/chart on each tab and set the "Scale all objects with pane" (right click on scroll-bar) property then the Tab as well as all graphs/charts will scale with the pane? You might have to reposition the Tab control after the resize operation has finished, but this can be handled with the Panel Resize event. /J

Always nice to hear that others think the same For clarity I prefer to use the cast, and because of constant folding I believe that there will be no hit in performance. /J

If it is all about performance, how about this; /J

I'll see what I can find. /J

I'm not particularly found of using the properties in the application builder to solve something that could be solved in LabVIEW. If everything is handled in LabVIEW I could launch the application on one computer and use another PC as a client, and this gives me complete control during testing/debugging. The application builder trick prevents me from doing this, or requires special handling if we are in an application or in development. Maybe I'm missing the point, but once connected you can always query the application for a list of exported VIs On the server side you can use the Static VI refs to get the qualified names of the VIs to export, and then define these as exported using the "Server:VI Access List Property" to enable remote access.The client then only has to connect to the server, and use the "Application:Exported VIs In Memory Property" to get the available server methods regardless of where they are located in the application./J

I've used a lossy-queue (size 1) to filter events that are sent to fast, pushing new events with the Lossy-Enqueue primitive. If the consumer loop can keep up with the event loop, all events will be handled. If the consumer loop runs behind, older events will be discarded, but the last event will always be handled. /J

I have no problem opening VIPM at the moment. When do you get the popup, at startup or...? /J

The quickest way (AFAIK) to deploy a RT applikation (with just one reboot), is to 1. upload the new rtexe, including dependencies, to the real time target into a new folder (perhaps with the version in the name) 2. download the ni-rt.ini file from the RT target to the local disk 3. Change the RTApp.StartupApplication path to point at your newly uploaded rtexe 4. upload the edited ini-file to the RT target 5. reboot 6. new rtexe should start running I also believe that it is possible to use private VI-server methods to edit the ini file directly on the RT target (if remote access is enabled) but I cannot check at the moment. Doing so would replace steps 2 to 4 above. /J

I agree, if the node generates an error the outputs of the called VI should probably be discarded anyway. /J

I have nothing more to add at the moment, used it successfully on 3 or 4 classes. Thanks /J

+1 /J

I have not tested the new version, but according to the video it looks perfect. More feedback tomorrow (some of us do sleep ) /J

Its more than that, its close to perfect (if you just add 6x4x4x6 it will be ). (and I don't understand when you have time to sleep, its like you are logged in all day and night) /J

You are welcome, I really like the idea of the tool. The class currently edited used 5x3x3x5, and the work made is not that much really; I start by creating the first method, then I just save a copy of that method whenever I need a new one. In this case I had to go through the code to understand why my renaming didn't work. I don't mean that we should throw errors for any control not matching the criteria, I would just like to have more control. In this case the main issue was probably the missing information in the ReadMe. As an alternative, you could pop-up a dialog if shift-z was pressed, and give the user a number of replacement options; move label?, limit to CP X?, replace on all VIs in class?, etc.. Sorry, couldn't help it. /J

Thanks, let's hope Michael agree... Tool feedback; At first I couldn't understand why the tool was failing, but then I looked into the code and realized that you had to use a specific connector pane pattern.this should at least be stated in the ReadMe ideally I'd like to be able to use any connector layout. In most cases it really doesn't matter where the LVOOP controls are connected, only on methods that combine, compare etc. is this a problem. [*]The first point leads me to the next one, error handling. I really don't like that the tool runs without any feedback. If it fails on a number of VIs, this should be displayed to the user.[*]The tool should check that the control being renamed is of the correct class. If another class is connected to the upper left corner this will also be renamed to the class name Once I figured this out, the tool runs very smooth. Code feedback The VI "Rename LVOOP FP Objects__icon_lib_scripting.vi" does not close control references if cating to "LabVIEWClassControl" fails The VI "Rename LVOOP FP Objects__icon_lib_scripting.vi" fetches the library name in every loop iteration, but this could be done before we enter the loop. The VI "Align All Block Diagram Labels__icon_lib_scripting.vi! could be realized with just one loop instead of three, using a select node to select left or right justification depending on if the object is an indicator or not. /J

Sorry about the cross-post, originally my post was just about fixing the tool in LAVA CR. I noticed that you are using VIPM2010, but the tool could have been installed with an earlier version of VIPM (I read a note about how much you just love VIPM3.0 ) Feedback is coming... /J

I filed a bug report for VIPM, see http://forums.jkisoft.com/index.php?showtopic=1465 for more info. I have tried multiple PC:s, both community edition as well as Pro version of VIPM. Once I edit the ogp file so that icon.bmp is not ReadOnly anymore I can successfully install the package. Have you installed using VIPM 2010 or VIPM 3.0? I believe that this is a issue only with VIPM 2010. Regarding feedback, check back later today (its morning here in Sweden) as I have not really started using it yet. /J

<YELL>I REALLY LIKE THE IDEA OF A LAVA REPOSITORY</YELL>, it would be much easier to find packages using VIPM instead of digging through the CR. It would also solve the issues of dependencies between LAVA submissions (I don't know if there are any today). /J