LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

extract a whole line after termination character from serial port

Solved!
Go to solution

Okay, I have made the changes and saved the default. Hope it is what you had asked me to do.

 

0 Kudos
Message 11 of 17
(1,135 Views)

Thanks, so the data is reasonable, but sometimes it takes 2 or 3 reads to get a full line in your TERMINAL string, is that correct?

0 Kudos
Message 12 of 17
(1,128 Views)

One issue I see is that several of your write commands are terminated with a carriage return.  Your serial port is configured to terminate a VISA Read with a line feed character, which would make sense since I see the lines in your display are terminated with a carriage return/line feed character.

 

My concern is that it is very unusual for a CR to be used to terminate commands you are writing to a device, then have it terminate its responses with a line feed.  It is usually line feed both directions, or carriage return both directions.

 

Are you sure your commands should be terminated with a CR?  What happens if you terminate them with a line feed?  If you are sending a command with a CR, but it is truly expecting a LF, then its possible the device is timing out waiting for the complete response, and this is eating into your timeout for the the VISA Read not leaving it with enough time to grab the complete response ending with a LF.

0 Kudos
Message 13 of 17
(1,109 Views)

@Gregory that is correct.

 

@RavensFan I tried to fix that it is slightly better but still having some here and there.

Also how do I not make it update while typing while entering a command to Serial write?

0 Kudos
Message 14 of 17
(1,091 Views)
Solution
Accepted by topic author LVPS28

@LVPS28 wrote:

 

@RavensFan I tried to fix that it is slightly better but still having some here and there.

Also how do I not make it update while typing while entering a command to Serial write?


Why do you want to "update while typing"?  That is a feature in LabVIEW that is only used in special situations.  Like if you wanted to create some sort of filtering feature that modifies some other indicator or control while you type. 

 

Your question caused me to notice something in your VI.  I can only see your question applying to 2 string controls in your VI.  First would be Commands.  But that doesn't make sense.  You have to actually enter whatever you want in there before you Run the VI because that control is read immediately and never read again.  That is actually a poor user interface choice.  But then again, you never use the value from that control anywhere in your program, so you should just delete that control.

 

The other spot is "Enter" string.  it is NOT set to "Update while typing".  This is where I just noticed you used a "Key Down" event for that.  Why?  There is no way that could work properly.  Let's say you would enter "123" as your command.  You'd key down on "1".  Guess what, that event will execute and VISA Write a "1" followed by a carriage return.  Then you key down on "2".  Now it VISA Writes "12" followed by a CR.  Now you key down on "3".  Now it writes a "123" followed by a CR.  There is no way that is what your device would want you to do.  But it could very possible cause it to send multiple messages if it is responding to 3 different commands.  So I think your current Key Down event is effectively causing it to behave the same way as "update while typing".  And you definitely don't want that.

 

That event should be a value change event so when you type in "123" and hit Enter to enter it, the value change event would run once and send "123" followed by a CR.  For me, a better user interface is to add a separate button called "Send" and have the code execute on the "Send" button's value change event.  This causes the command to only execute when the user explicitly presses that button.  Otherwise there is a chance they could accidentally click enter while that string control is active and cause a command to be sent when they didn't really mean to.

0 Kudos
Message 15 of 17
(1,080 Views)

@RavensFan wrote:
For me, a better user interface is to add a separate button called "Send" and have the code execute on the "Send" button's value change event.  This causes the command to only execute when the user explicitly presses that button.  Otherwise there is a chance they could accidentally click enter while that string control is active and cause a command to be sent when they didn't really mean to.

Let's also not forget the capability of resending commands that you gain with the Send button.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 16 of 17
(1,056 Views)

Thank you I have changed that to a Value change event.

Now that combined with the timeout somewhat made it better.

 

Thanks a lot.

0 Kudos
Message 17 of 17
(1,043 Views)