How select COM-port before starting looped VISA write?

[Stepper]

Hello,

I have an app that in essence is a simple loop that writes a user-input string to a serial com-port (VISA).

The VI includes a COM-port selector. However, if the default value of this selector is not equal to the actual port-number to which the serial-device is connected, the app gets stuck in an error-message loop that cannot be stopped with the stop button.

One solution I can imageine, is having to always explcitly select the COM-port before the write-loop starts (and having an indication when that hasn't been done that). No idea how to do that. Automatically searching for the FTDI-device appears too complicated. I know how to read-in parameters from an external file (I use that for other initialisations), but don't know how to connect that to the port-selection mechanism. So far, the explcit port selection is my preferred solution.

LabView 8.0 VI screenshot of the VISA-functionality is attached. (I know, I know, there are cleaner ways to do certain things - first want to get it to work)..

Any help will be greatly appreciated!

[Saverio]

Your fundamental problem is that you are opening/closing the serial port in every iteration of the loop. This is a waste of time and resources. The serial port should be opened once, before the loop, and closed once, after the loop. If you're concerned that someone may choose a VISA resource that does not correspond to a serial port, or to the wrong serial port, then you need to check before you start your loop. You don't show the rest of your code, but a simple state machine could be used for your architecture. You'd have an "Init" state where you mess around with controls (as you appear to be doing below the loop), a "open serial" state where you check the port and verify you're connected to the right port, and a "close" state where you close the serial port, and do any cleanup.

Additional comment: you can replace the big Concatenate String with a Format Into String function.

[ShaunR]

Unbundle the error cluster after the Error Message Dialogue VI and "OR" it with the stop button to terminate the loop. The loop will then stop if there is an error or if you press the stop button.

[asbo]

If you're concerned that someone may choose a VISA resource that does not correspond to a serial port, or to the wrong serial port, then you need to check before you start your loop. You don't show the rest of your code, but a simple state machine could be used for your architecture. You'd have an "Init" state where you mess around with controls (as you appear to be doing below the loop), a "open serial" state where you check the port and verify you're connected to the right port, and a "close" state where you close the serial port, and do any cleanup.

This is good practice and I agree with it, but it might be overkill, depending on what OP is doing. I would be satisfied with making the improvement ShaunR suggested wrt checking the error output and letting the loop terminate after one iteration based on that.

Additional comment: you can replace the big Concatenate String with a Format Into String function.

Amen! Anytime I concatenate more than 3 strings, it's time to pull out the Format into String node. It usually helps eliminate upstream code as well, as it would in this case.

[hooovahh]

Amen! Anytime I concatenate more than 3 strings, it's time to pull out the Format into String node. It usually helps eliminate upstream code as well, as it would in this case.

You dislike the concatenate string function so much that I use it just out of spite.

But seriously I have a bad habit of over using the concatenate function and find that using format into string is almost always better.

[Saverio]

This is good practice and I agree with it, but it might be overkill, depending on what OP is doing. I would be satisfied with making the improvement ShaunR suggested wrt checking the error output and letting the loop terminate after one iteration based on that.

The code is designed on the premise that "everything is working". If the VISA resource control is set to the "correct" value, then the code will run without error (barring communication errors). Opening and closing the serial port on each iteration. How is this a good thing? Yes, checking for the error code will stop the loop, but it does not eliminate the fundamental problem with the code that I pointed out. On the NI forums we see this all the time, and we tell those who do this the same exact thing (all the time): initialize before the loop, close after the loop.

[Stepper]

OK, thanx for the suggestions! I have implemented the following changes:

1) move the initialization of the VISA port to outside the loop (duuhh).

2) unbundle the error cluster and connect the error status to the halt thingy.

Resulting VI (LV8) attached (I am sure that there are more areas that scream for cleaning up etc. - humor me for now).

This fixes the problem with selecting the COM port before the loop gets going. Great.

The communications-LED on the connected hardware is blinking away, which implies communication to the device is active and interating. The concatenated string that is input to the VISA port, follows the GUI inputs as it should. However... I now have to stop and restart the VI before the connected device actually gets the latest user input. Any thoughts on that?

I will convert the Concatenate function to Format-into-string, as soon as I get the thing to work.

N4SPP-miniVNA-sig-gen-V12.vi

[asbo]

The code is designed on the premise that "everything is working". If the VISA resource control is set to the "correct" value, then the code will run without error (barring communication errors). Opening and closing the serial port on each iteration. How is this a good thing? Yes, checking for the error code will stop the loop, but it does not eliminate the fundamental problem with the code that I pointed out. On the NI forums we see this all the time, and we tell those who do this the same exact thing (all the time): initialize before the loop, close after the loop.

I wasn't talking about init'ing and closing outside of the loop, which is why I didn't quote that part. I think it's unnecessary to implement this as a state machine, which is what I did quote.

[Saverio]

I have to admit that wasn't all that clear from your response, as you basically said that you thought Shaun's suggestion was sufficient, and he simply said to unbundle the error cluster. Nothing was mentioned about the initializing/closing. Well, at least it's clear now.