All Activity

The VI hierarchy window is fairly useless. For large projects, it is painfully slow to update. The links between objects don't make the architecture of a project any clearer. It cannot be printed with high resolution as a PNG or PDF file. Etc. Ignoring these shortcomings, it appears to not behave as expected: when selecting View>>Always Show Labels, collapsed library boxes expand laterally as if to accommodate the library label, but no label is displayed. I am labeling this as a bug, but maybe it isn't. Similarly, a library is represented by said box with an icon inside. The icon seems to be picked up randomly from one of the VIs in the library. This is not helpful. There should be a way to set a "library" icon (not just a template as defined in the library "Properties" window. Tested in Windows LV 2021 SP1 64 bit

I have a LabVIEW-built DLL. (2021 SP1, 64-bit, Linux) I am calling this DLL cyclically by a RUST application over FFI. Never on the first DLL call, but sometimes on subsequent DLL calls, I am hitting a segfault: LabVIEW caught fatal signal 21.0.1f6 - Received SIGSEGV Reason: address not mapped to object Attempt to reference address: 0x170 I can't seem to figure out why this is happening. It has something to do with the fact that I am needing to call the DLL several times, with little wait time in-between calls. I suspect that the DLL is unloading, and then reloading between each call. And I suspect that this unloading might be creating a weird race condition with the runtime engine, where the runtime engine is still busy unloading the DLL from the first call, when the 2nd call happens. Any ideas are welcome. Scratching my head on this one.

a

I've seen memory consumption [leaks] when Queues and notifers are used where multiple instances of 'Create Queue' are called which instigates a new queue memory pool. You need to pass the Queue reference wire to each queue read/write. I've seen this from novices when using Queues and Notifiers....We had this problem of the code crashing after some time. Just a thought.

Hi, I have this .vi project where I acquire data from the NI-Module and save it to TDMS. The acquisition rate for the TDMS is in the Resample Waveform block. However when I examine the TDMS in excel it does not match the expected number of samples recorded based on the chosen acquisition rate. I also tested it without the Resample Waveform block, when the rate is directly set in the Task, the TDMS again does not match the expected rate. Any thoughts? Regards R_R_9_single_channel_1.vi

Also make sure you don't have thousands of files in the installation directory - it slows down the verification process at the end of an installation.

I cannot look at your file, but I suggest save the data to TDMS or any binary format of your choice. Once the file is saved, then you can convert it to text.

How do I postprocess automatically, so that the .tdms is converted into the delimited .txt file that includes the time and all channels involved columns. Also to have headers. See the .vi attached. R_R_9_MTDS_2.vi

Do you mean, to save into MTDS, and postprocess to text?

Post process the data into a text file.

Hi, What would be the most efficient way to record data in sampling rates >1MS/s into the .txt? I tried to use Write to Measurement File but after a few seconds it spits error, saying that I run out of memory. Please have a look at the .vi. R_R_3.vi

All those packages are quite large - even with a fast computer it takes time.

Hi everyone, I'm currently using LabVIEW 2020 (32-bit) and I've been distributing my application by creating an installer that includes the built executable. The problem is: users are reporting that the installation process takes at least 1 hour, and sometimes up to 2 hours to complete. This seems extremely excessive, especially considering that the executable itself is relatively small in size. I suspect something might be misconfigured, but I'm not sure where to start debugging this. Here's a screenshot of the additional installers I'm including during the build process 1.NI LABVIEW RUNTIME 2023Q1 2.NI-488.2 RUNTIME 22.8 3.NI-SERIAL RUNTIME 23.3 4.NI-VISA RUNTIME 23.3 Has anyone else run into this kind of delay? Any advice or tips on how to reduce the installation time would be greatly appreciated. Thanks in advance!

If it is indeed a fixed 5 byte message and not terminated with a char sequence then the message may be terminated by a break. See the Set Break example of how to set it. IIRC, you also need to set the End Mode For Writes property to Break and set Send End Enable to False then add the primitive after your Write. Another thing. The Write and Read have a little watch icon in the corner. This means they are asynchronous. While you are troubleshooting then right click on the icon and select "Synchronous"

Can you try some serial port monitor when the EXE is running? I have no experience with this, but maybe something like it. There is probably a better tool that someone elese here can suggest.

ShaunR, I realized that exception 90 minutes after I posted. I removed the property - thanks for the heads-up. Yes, ensegre, the cable is a straight cable and the C++/QT exe works fine. If I increase the byte count, it does time-out and error. I am totally flummoxed as to what might be the problem... Thanks, Folks.

"Port Connected" is only applicable to NI products and doesn't work with OS Com Ports.

i.e. crossover cable vs. null modem cable. But the OP says that the exe succeeds with the command, so that doesn't seem to be the issue here.

Just to make sure - if you read 5 bytes, you get the first 5 bytes. If you increase the number to 'byte count', you would get a timeout warning if the other program really outputs only 5 bytes, but you would see the trailing ones, if there were. Also, right-click the string indicator, check 'Hex display' may come handy.

or there's an issue at the hardware level eg. the TX and RX pins are swapped

Thank you for the thoughts. The radio expects no termination characters. it demands only 5 bytes - four Parameters and the fifth byte being a Hex Command, and 2 Stop Bits (and 4800 Baud, No Parity, No Flow Control). The C++/QT exe built by another to test the radio (changes VFO-B to what is in VFO-A) works fine. I have a USB to RS-232 adapter with a Female DB-9 so I configured it as another Serial Port to read what his exe is spitting-out to make sure my formatting is correct. I wrote a VI to open and read the Com Port and return the string. While I did not do a String to Byte Array conversion, the string outputs exactly what I am sending - the 5 bytes Null, Null, Null, Null, ... (without the commas). This string corresponds with 0,0,0,0,85. I am reasonably sure that the formatting is correct. (Screenshot attached). For the heck of it, I inserted a Property Node after configuring and opening the port to make sure nothing is amiss in the settings. All settings returned are what I set (amended VI attached). If I add the property Is Port Connected, the VI throws a Error-1073807331 The Specified attribute is not defined or supported by the referenced resource. Is it possible that I am missing something in how LabVIEW handles Serial Communications? I appreciate your patience on this. It seems there are several layers to VISA and I may be missing something here. Thank you for your time and insight, John ensegre2.vi Read EXE File.vi

Those aren't typo's and errors. They are tests to see if we are paying attention.

When you know the baud and parity etc; issues that result in the instrument not responding at all are almost always the termination character. Initalise the com port and try a few term chars (CR,LF, CR+LF). ensegre's example turns off the term char. You may just need to add 0D0A to the array. There are examples shipped with LabVIEW and you can also play around with VISA using the NI MAX software. Note that if you right click on the string control and select "Hex Display" you can enter the hex values:

Can't say without seeing the rig's documentation (if at all good) and some amount of trial and error. These old devices may be quirky when it comes to response times (the internal uP has to interpret and to effect the command) and protocol requirements. Are you sure the message does not require an EOT or a checksum of some sort? Does the rig respond with some kind of ACK or error, which you could read back? Are you sure of your BCD encoding? Wikipedia lists so many flavours of it: https://en.wikipedia.org/wiki/Binary-coded_decimal If there are read commands, returning a known value, like the current frequency or the radio model, I would start with them, to make sure that the handshake works as expected.