JamesMc86

What is the problem after the upgrade? (null)

One thing to be aware of with the 9205 is that it is isolated. This means everything is referenced to ground on the connector not the chassis. Try tying this to a stable ground and see if it improves (null) Also just be aware the DMMs are slow and often don't show noise, not that I doubt you but it alone doesn't rule out noise on the line (null)

Hi Flinstone, I have seen real time (although on VxWorks, not PXI) struggle with large directories before, if you can break it down this is probably best. The only other thing I could suggest is maybe trying the file transfer through the web interface. If it was protocol related then this uses a different technique (something over HTTP) but if it is the number of files you will probably see the same thing again. Cheers, James On trying to find a recommmended number I found this: http://digital.ni.com/public.nsf/allkb/C9B0A1443BF1C3398625760A004DB976?OpenDocument seems 'significant' means a few hundred files

Simplest thing is to try it on another PC to rule this out (tech support will probably ask this anyway if you get it fixed). I would confirm it with another source. Also what if you jut ddo one channel? But sounds like it could be a fault. Especially if you've had to recalibrate the volts (null)

Very true, the short answer is if you are not doing something about it, yes you will need to run as admin to have write access in this folder.

For standard accounts you only have read access to ProgramData, not read/write so if the application is to be run by someone it would have to be elevated to admin before being able to write. Rolfk: I wonder whether you have always had admin priveledges or I believe if you have just one user there is some kicker in Win7 which gives the user that creates the folder R/W permissions (I am not sure about this, someone may be able to elaborate better). The recommendation from Microsoft is that your installer should set permissions for your folder entry in here if you need it. This is not straightforward from LabVIEW but I believe it can be done with a batch file. Another option is that you can sit a mainfest file with your exe which tells Windows that your application must always run elevated (but I suspect this is not recommended practice!). This appears to have caused confusion and problems for programmers across all languages! Mads link in the reminder is pretty good and will have to keep it on stock. Here it is again and reading the comments you can see the frustration this can cause! http://blogs.msdn.com/b/cjacks/archive/2008/02/05/where-should-i-write-program-data-instead-of-program-files.aspx?PageIndex=2#comments. Primarily because you will have no such issues with the equivalent in XP.

I would beware of ProgramData. It can cause upgrade issues going to Win7 due to access restrictions, seen this catch a few people out. (null)

Absolutely, it is how we maintain our training rooms! The one issue you could hit is if you have a single user lincense and ghost a new PC. Then you would have to reactivate (null)

I think all of the ideas you have mentioned are valid but the right decision is going to be based off how you view the data (and how much data there is). If you were going to view it in DIAdem or another tool that can plot non-continuous waveforms based off timestamp channel I would be tempted to add a time channel and keep it in one channel (this will also impact your file size of course). If you did do this though you would also need to be aware of file fragmentation (I wrote an comparision of the affects of TDMS fragmentation here: https://decibel.ni.com/content/docs/DOC-20522) I would probably agree with asbo though, you can add some nice features then like adding the properties related to the trigger as well. But again if the channels are very short you are going to see a lot of overhead from the headers (which will look like fragmentation although is really an expected consequence of the format).

Hi All, I was hoping to crowdsource some of your experience today on a common application architecture that is bugging me slightly, but I can't decide whether it is genuinly bad or if it is just me. In the spirit of Steve Watts talk at the European CLA summit, something stinks! The problem statement it solves is, I have multiple data sources, let's say they are the same rate but I have seen different rates as well, that I want to log to disk as a single file. I have seen the same solution several times involving FGVs, this is what makes me nervous! What they do is have a seperate DAQ process per source of data and a single write to file process. Then either a)They have an FGV per DAQ process or b)A single FGV that different process write into different points in an array. Then in the log to file they either a)read from all FGVs or b)read from the FGV. I don't like this because: There is no buffering, the only thing that guarantees getting the data is that the various loops stay in phase. FGVs make the code pretty hard to read. But it is hard to rip it to shreds when fundamentally people are succeeding with this. What I am interested in is what you guys have found to be a good solution to this problem. Ideally the data should be buffered which points to using queues, but another smell to me is waiting on multiple queues in one loop. One thought I have had is to have a data collator process, this would have to wait on multiple queues but then outputs the single set of data, or is this just b) from above again? I think this could be done in the actor framework as well where the collator then spawns the various DAQ actors. So what are your thoughts, is there a deodorant to this or is this problem always going to smell! Cheers, James

On first glances there are two sections of the code I would want to double check the logic of, not sure if its wrong, but looks like a potential source of data loss. One is where you and output valid of the FFT with less than 512. I am not sure exactly what this is doing yet but if those two disagree then data would be lost. I am also trying to work out your logic for writing to the Frequency Spectrum FIFO. It looks like you are enabling everything off ready for output rather than output valid. Typically I would check first for Number of Elements to Write for the queue and use that as the ready for output flag. EDIT: I think I see what you are doing now and it looks like it should work but the counts will tell you. I guess your Valid FFT Out vs Elements loaded vs Valid outputs counts should suggest which of those is the problem.

The PXI trigger lines are great for this as is TCLK for really tight synchronisation. If you search the respective help files for state diagram there are a series of diagrams that show the states of the hardwares and most importantly the different trigger signals that are generated so you can see what can synchronise the right parts. T-Clock is a technology on PXI for very tight synchronisation of most modular instrument boards from NI (The have to be based on the SMC architecture). I am pretty sure that all of these boards meet that (The 653x doesn't but I think the 654x are) and this gives typical skew of 200-500ps. Check this and see if it is what you need: http://zone.ni.com/devzone/cda/tut/p/id/3675 but you may get by with just the correct trigger signals. Cheers, James

Hi Austin, If you are doing high speed control the RT/FPGA are much better for this. Doing control ideally should be done on single point data, no queues as the introduce latency to the system but everything we do on windows tends to use buffers of some form to get the performance required for DAQ. Perhaps if you post a little more information on your FPGA issues we can suggest some improvements to make it fit. Cheers, James (null)

Hi Mike, There used to be some standard functions that supported different data types in the HIgh Performance Analysis Library (HPAL). Not sure about extended but I know they went the other way and implemented some in SGL. I went to the NI labs page but it looks like it has been pulled but there is a beta program where the functionality has been moved to. The page is at https://decibel.ni.com/content/docs/DOC-12086 with the address for the beta program if you were interested. Cheers, James Scratch that. Remembered I still had the HPAL library installed to LV 2010 and check, it has SGL support but not EXT, sorry for the confusion. Cheers, James

Just be aware that the spreadsheet to array functions will work if you save to a csv or tab delimted file from excel, but the XLS or XLSX files are harder to get into LabVIEW because they have to come in through automation of office rather than acting on them directly (unless there are some third party tools out there for it now). Cheers, James

Hey Nitin, Do check out the guide as well. Both of those are good techniques but it depends on the type of data you are transferring that will decide for the best on a case by case basis. For example if you need to stream continuous data the RT FIFO is the best inter-process but then over the network then network streams are much better than shared variables. There is rarely a catch all technique. Cheers, James

Hi Alex, With the multiply I think you should be OK. As you said it returns within one cycle and this means it will return its output in the same cycle when it is called in the single cycle timed loop. I wouldn't go as far as to say all as there may be other elements which can't return in one cycle (e.g. is there reciprocal in high throughput? EDIT: I guess not as this is what you are doing!). I think the overhead is minimal if you enable the handshaking when available. The one problem with the code above is what happens if the output FIFO is full? To truely complete the four wire handshaking on the divide you should handle the time out case there which involves latching the divide output until you know it has been succesfully read, I think there is an example of this in the FFT shipping example. Cheers, James ...or to avoid latching I think you could do it just with checking the queue status has a space (available elements to right). If this is greater than 0 then set ready for output on the divide.

Check out the cRIO developers guide at www.ni.com/compactriodevguide. It has a whole chapter on this, even if you are using a different RT target the same should apply. Cheers, James

Hey Wim, Definitely using the digital input as a clock is easiest. Don't think it will do rising and falling edge natively though but I remember seeing schematics for a basic circuit which can take care of this. Cheers, James (null)