All Activity

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 🙂

Unless I'm completely hallucinating, there used to be an Edit command in this pulldown menu. And it is now for this post, but not for the previous one.

I am unaware of a time limit on editing your own posts. You are welcome to use the report to moderator to make fixes. I realize small things are just easier to ignore than making a report.

I believe that I was able to edit in the past posts even if they were older. Just came across one of my posts with a typo and when I tried to edit it, the Edit command is not present anymore. Is that a recent change, or am I just hallucinating due to old age?

If the child classes are statically linked in the code (via class constants, or whatever other mechanism you use), then this approach should always work, because the child classes will always be in memory.

Despite the documentation, I tried running this in the run-time environment and it worked. I did have to add class constants of each of the child classes to the block diagram (no this does not defeat the purpose for me). Am I missing something and in a different environment, it could stop working?

As far as I can see on the NI website, the WT5000 instrument driver is not using any DLL or similar external code component. As such it seems rather unlikely that this driver is the actual culprit for your problem. Exception 0xC0000005 is basically an Access Violation fault error. This means the executing code tried to cause the CPU to access an address that the current process has no right to access. While not entirely impossible for LabVIEW to generate such an error itself, it would be highly unlikely. The usual suspects are: - corrupted installation of components such as the NI-VISA driver but even LabVIEW is an option But if your application uses any form of DLL or other external code library that is not part of the standard LabVIEW installation, that is almost certainly (typically with 99% chance) the main suspect. Does your application use any Call Library Node anywhere? Where did you get the according VIs from? Who developed the according DLL that is called?

HI. Using LabVIEW 2018 32-bit, I created an application for Windows 10, but random crashes occur with error code 0xc0000005. My suspicions fall on the VIs used to communicate with the Yokogawa WT5000, but after reviewing the various lvlog files, I haven't been able to identify which specific VI is causing the crash. That said, I would kindly ask for your assistance in identifying the VI responsible for the issue. Thank you. 03dc9418-0115-4f24-ba73-07f98ebf6821.zip 3eb1d949-0f35-4147-809b-7f7dff13ad06.zip 6bcc6278-fb26-48c7-a715-ab2f35a336de.zip 6f80126d-b9e2-4a12-b7f2-e8c15fb9ea48.zip

You can use this private method to get all the tag names from a VI.