mrak1

Hi All, I am not sure if the question here is whether or not user events can be handled by multiple event structures executing in parallel. If this is the question, then I believe that the answer is that it can be done even if one of the event structures is being held up. I have attached an example that I believe demonstrates this. ... sorry for the ugly code.... Thanks, Mike

Hi Ben... no worries.. i don't recall you ever insulting even though i did work with you on a few RT & FP questions...

Ok.. I feel like I must join the :ninja: LAVA coup that is brewing by introducing myself to the forum! AND YES...I also work for VI Engineering as a Systems Engineer like a lot of other people who have recently introduced themselves. Now a little about myself. I have been using LabVIEW for about 7 years beginning with version 4.1. I am a Certified LabVIEW Developer and a NI Certified Professional Instructor. In addition to all that fun stuff, I used to work for NI as an AE and a PSE ==> I am sure that I spoke to some of you regarding support issues and yes I did give you the wrong answer on purpose

Hi Yannis, I cannot give you a simple example because what I have done has always been part of a large applicaiton. However, I can give you some tips: - Have the FPGA application only place data on the DMA buffer when a change has occurred ( if possible) ( see the Buffered DMA Acquisition example from NI for ideas) - Monitor the DMA buffer on RT => when it has some data in it => send it immediately via TCP to the Host - On the host, keep the file reference opened and continuously add data as it comes in. You would do this with the TCP read VI and transferring the string directly to a file. If your file needs to be in a specific file format, you may want to do this after the acquisition is complete. (There are several streaming to disk examples from NI) Good Luck! Mike

You could also try setting the priority of the LabVIEW process to HIGH. However, there is no guarantee that Windows will not preempt the LabVIEW application for something as simple as a mouse event. Good luck! Mike

As far as I know, you can use them in other places. I believe that LV 7.1 allowed the feature on any VI whether or not is was on FPGA, RT or Windows. However, you needed to have FPGA installed to get this feature because fixed sized arrays are only necessary on FPGA.

Hi, I am not sure what the question is but you probably already noticed that you can select "Adapt to Source Wire" for an indicator. This will allow you to set the dimension size for any control, and the corresponding indicators will automatically adjust. On another note, be very careful when using arrays in your program on an FPGA target. Typically, every bit in a numeric indicator or control consumes roughly 1 slice on the FPGA target ( due to addressing logic and the registers). However, when the indicator is a numeric array, each bit consumes more than 2 slices on the FPGA target. For example, lets say that you have 4, U32 indicators on the front panel of an FPGA VI. These 4 indicators will consume half of the real estate on FPGA than an array of 4 U32's. If you have tons of FPGA space left, then don't worry about changing your VI. However, if you are fighting for more space , I would strongly suggest using the memory on the FPGA or breaking the array into indicators using the index array instead of placing an array indicator on the FPGA diagram. Good luck! Mike

Be careful when using the loop timer from a while loop in LabVIEW FPGA. Depending on the speed of your FPGA VI, the iteration terminal could top out quickly. In other words, the iteration terminal counts from 0 to 2 E+9 but does NOT roll over. The loop will continue to iterate but the iteration terminal will always put out the same number after reaching 2 E+9. Also, I have used DMA for fast data transfer from the FPGA to the cRIO RT controller. In my project, I was only interested in a particular amount of data following a digital trigger. - the RT would have a separate state machine that indefinately waits for an interrupt from the FPGA - FPGA would wait for a trigger ( analog trigger, digital, etc) coming from an input card - Once the trigger was received => buffer the data in the DMA FIFO and generate an interrupt to the RT - The RT state machine would then wake-up and begin emptying the DMA buffer ( empty until completely empty) - Start from the top again.... This architecture allowed me to do the majority of the processing on the FPGA and only transmit the important data to the RT and ultimately to the Host. Good Luck... Mike