07-24-2019 04:47 PM
Okay, I have made the changes and saved the default. Hope it is what you had asked me to do.
07-24-2019 05:12 PM
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?
07-24-2019 08:25 PM - edited 07-24-2019 08:28 PM
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.
07-25-2019 10:23 AM
@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?
07-25-2019 10:57 AM
@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.
07-26-2019 06:57 AM
@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.
07-26-2019 09:38 AM
Thank you I have changed that to a Value change event.
Now that combined with the timeout somewhat made it better.
Thanks a lot.