All Activity

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.

I appreciate your quick response and (I think) I recreated your work. But neither command does anything. Is there something I am missing? John ensegre1.vi

Decades too late, I am just learning RS-232 communication and the only resource that has a Com Port library is LabVIEW. I am having problems understanding how I should send the data and really could use some pointers... I have a Ham radio which I would like to communicate with through the computer. It is as Plain Jane as you can get: 4800 Baud 1 Start Bit 8 Data Bits 2 Stop Bits No Parity No Flow Control The radio expects 5 bytes - the first four are parameters either in BCD or Hex and a fifth Command code in Hex. Any of the four Parameter bytes not needed are padded to provide 5 bytes, which the radio expects. There are two commands I would like to send - one requires only the Hex command (and padded Parameter bytes); the other BCD Parameters. Walk before I run... 1) The easiest is transferring the VFO contents from VFO-A to VFO-B. The Command is 85 (Hex) with the four Parameter bytes padded (I tried zeros). I had a friend create a simple routine in C++ and QT which does this nicely - so the radio works. While I cannot see inside his exe, I presume the 5 bytes are 00 00 00 00 85. 2) The other command is to change VFO-A to the frequency 14.250.00 MHz. The parameters contained the frequency in BCD Packed Decimal) and the Command 0A (Hex) to complete the five bytes. The five bytes are formatted as such: Byte 1: 00 Byte 2: 50 Byte 3: 42 Byte 4: 01 Byte 5: 0A Per the radio manufacturer, sent in this order will change the frequency. But no matter what I try, I cannot even perform the simple task of copying VFO-A to B. I have tried arrays writing within a loop, sending a string, typecasting, flattening - all examples I found online. I don't know how LabVIEW handles data through VISA Write. Worse, the radio manufacturer gives a BASIC example of command 2 (changing frequency) as: Print #2 CHR$(&H00);CHR$H50);CHR$(&H42);CHR$(&H01);CHR$(&HA) I recognize this BASIC syntax as converting Hex into String and sending them off to the Port, but cannot convert this in LabVIEW. Yes, I use VISA Configure Port matching what the radio expects. I think my problem is what I am feed VISA Write - I am hopelessly lost here. I am not even sure 85H is 85 when sent as a string. Are the 5 bytes converted to an array and sent as one string or sent in 5 iterations (if the latter, do I convert a single U8 from a byte array to a string? If there is a conversion, what is it? Thanks for helping the dinosaur. John

VI server. Simple and easy to implement with no framework dependencies. Define a distinction between Services and Plugins (plugins don't contain state, services do). Use a standardised uniform front panel interface between plugins. I use a single string control (see this post) and events for returns. An alternative is a 2d array of strings which is more flexible. Each plugin is contained in it's own LLB which contains all of it's specific VI's. Just list the llb's in the directory for plugins to load. Replace the LLB to upgrade; delete to remove. Names starting with an underscore (either in the LLB name, directory name or file name) are ignored and never loaded. They are effectively "private". A scheme to prevent unknown plugins being loaded.

Hi there, Great question — building a modular LabVIEW application with dynamic plugin loading is definitely a rewarding (and sometimes tricky) path. I’ve worked on similar architectures in test systems for electronic components, where we needed to dynamically load test procedures (as VIs) based on the device type or protocol (SPI, I2C, UART, etc.). Here’s what worked well for us: VI Server + Strict Type Definition: We defined a strict connector pane interface for all plugin VIs. This made it easy to load, call, and communicate with each plugin uniformly, whether it was a basic power test or a complex timing validation routine. Plugin Metadata: We stored metadata (e.g. DUT type, test category, plugin path) in an external config file (JSON or INI), so the main application could dynamically discover and load plugins based on the connected device or selected test plan. Encapsulation: To keep each plugin clean and focused, we implemented per-plugin state handling internally using FGVs or even mini actor-like modules. Main challenges: Version compatibility: When firmware or hardware revisions changed, some plugins required updated logic — this required version tracking and good documentation. Debugging dynamic calls: Debugging a broken plugin that fails to load at runtime can be painful without good error logging. We included detailed error tracing and visual logging in the framework early on — a huge time-saver. Hardware abstraction: We wrapped hardware interaction (like GPIO toggles or I2C commands) in common interface VIs to decouple the plugin logic from the actual test instruments. If your application also deals with automated test equipment or embedded devices, making your plugin architecture hardware-agnostic will greatly increase its flexibility and reusability. Would be happy to chat more about plugin communication models or modular test design for electronics! Best,

There is no typos and errors in your posts. Only pearls of wisdom and oracles of truth that we mortals can't understand yet...

Drat, and now my typos and errors are put in stone for eternity (well at least until LavaG is eventually shutdown when the last person on earth turns off the light) 😁

@Rolf Kalbermatter the admins removed that setting for you as everything you say should be written down and never deleted 🙂