mcduff

I don't have extensive experience with PXIe systems, but have made some systems in the past and present. A current system collects data continuously at 20-30MSa/s for 32 channels. At that rate the 15TB RAID array is filled up in a few hours. Advantages: Throughput. Unless your modular instruments are attached via thunderbolt, hard to beat PXIe throughput. However, it might not be needed in your case. Triggering. Simple to implement triggering or advanced triggering through the backplane. Can be done with modular instruments also, but more wires and more hassles. If you need a synchronized start, the PXI backplane is your friend. Synchronization. Can share reference/sample clocks through the backplane. Can be done with modular instruments also, but more wires and more hassles. Compact. Somewhat more compact than modular instruments. Disadvantages. Expensive. Noted in previous message. Support. If you have instruments from different vendors and there is a problem, each vendor may blame the other. I had a chassis, a controller, and digitizers from three different companies. When there was an issue with the cards and the slots they could occupy, everyone at first blamed the other, Eventually, it was found that the chassis had an issue with the interrupts. PXI is supposed to be standardized but ... Future proof. The embedded PXIe controllers seem to always be a generation or two behind current CPU offerings. In addition, their components are difficult to upgrade or have limited upgrade capabilities. You may want to also purchase an external TB controller card. This allows to you to attach the chassis to a computer via the TB port and control from that computer instead of using an embedded controller.

I don't work in Industry, I work in a R&D facility but I am slightly pessimistic. My gut feeling is that Python will take over sometime in the near future. I have seen it before. When I first joined my group about 15 years ago all of the analysis was done using Matlab, now everyone uses Python. NI seems seems to be pushing solutions such as Flex Logger, Instrument Studio, etc, instead of LabVIEW. (Interestingly, those solutions look like they were built with NXG. ) On the plus side, we recently had a presentation by a NI rep who detailed plans for new DAQ equipment that was/is going to be in development. They were looking for feedback. The future is interesting.

Excuse my ignorance and stupidity, but I never really understood the following settings in the Compile Settings. I always leave them as the default value. Do those settings remove both Front and Diagram from VIs in the EXE? I know the setting may affect debugging an EXE file and possibly some of the tools to reconstruct VIs from an EXE, but should I be checking or not checking those options in an EXE? Thanks

You may not be able to specify the channels in any order you want. If I recall correctly for some DAQs you can only specify them in ascending order. Not sure if this holds true for simulated instruments.

I do not think it is a bug, just floating point math. You don't have infinite precision. See below for another example.

Does this token need to be added to the INI file of a compiled exe or does it automatically get included?

This is why "Export to Excel" is a useless feature. The data is exported using the display format of the plot's axes; since the plot uses SI formatting, it is expressed as 10k, 100k, etc. This does not help if someone wants to plot the data in Excel.

Good Read here, a bit depressing https://nihistory.com/nis-commitment-to-labview/

The LabVIEW Multicore Analysis and Sparse Matrix Toolkit is definitely faster but it seems to have issues with the large number of points. For example, on my laptop I cannot do a FFT of 20M points, but the built in FFT does 100M points no problem.

Read and copy the file in chunks. No need to open the whole file at once. To increase speed write is multiples of the disk sector size.

Is this number greater than the number of COBOL programmers? It seems like it's getting close.

Before you convert to a string why not take the String from the Read Function, convert to Byte Array, split it into the fixed lengths you want then convert into string. This can be done in a for loop, have an array of lengths and use that to split the string.

No hassles. Just curious. I need to set up a remote RT system, no FPGA, and am trying to find best practices/methods. In addition, what were your security considerations? Thanks!!

I know it's 3 years later, but would you, @Neil Pate, mind sharing which method you chose? I will need to set up a similar system. Thanks

You should link this to the original discussion on the darkside, https://forums.ni.com/t5/LabVIEW/Help-issues-with-arrays/m-p/4299181 There you marked the VI by Altenbach you posted here as the solution to your problem. What array do you want to extend? Your question isn't clear to me. Maybe some of the learning resources at NI would help?