LabVIEW
Looking for help with Serial Communication, Events, and State machines
Solved!
@crossrulz wrote:
@ShotSimon wrote:
I would also be interested to see where and how you implement the fake timeout error.
I have just set the timeout to something short (500ms, at least long enough to read an entire message) and let the VISA Read time out. It will return whatever was already in there. You can choose to throw that away or add the CRLF yourself on the timeout. I have done both methods.
I meant that if you never get anything (always the "0" case) you probably don't want to keep trying forever.
@billko wrote:
@crossrulz wrote:
@ShotSimon wrote:
I would also be interested to see where and how you implement the fake timeout error.
I have just set the timeout to something short (500ms, at least long enough to read an entire message) and let the VISA Read time out. It will return whatever was already in there. You can choose to throw that away or add the CRLF yourself on the timeout. I have done both methods.
I meant that if you never get anything (always the "0" case) you probably don't want to keep trying forever.
With my set ups, yes, I do try forever. That is because I make my serial communications its own loop to act as the terminal interface. It will constantly try to read and it will write if it gets a command to (via a queue). This loop does not care if the instrument responds or if it is constantly spitting out data. Any data it reads gets logged (with a date/time, great for debugging) and optionally sent through any number of queues (each command gives a queue reference and an expected pattern for the return data).
@crossrulz wrote:
I'm going to put some people into shock here...Do use the Bytes At Port. I haven't had much luck with the VISA Events, so what I do is use the Bytes At Port to see if any message has started. I can then read a full line. If there is no data (bytes = 0), then I use a short wait (50ms) before checking again. This allows the loop to handle the stop button or messages coming from other loops fairly often while also keeping the serial port as a priority.
NOTE: The "0" case just wires the error and VISA Reference through along with a 50ms wait.
I am in shock.
Now, I KNOW that not every interface designer follows the following:
- Use a termination character - unfortunately <CR LF> became popular back in the 1950's with 77Baud terminals It was nice to "Return" the carriage that struck the paper AND advance the paper a whole line. <These developers should realize that paper isn't as available as it was in 1956 a single term character is fine!>
- Declare Size of Package- yup ACSII STX Followed by 4 hex characters that define the size of the Text Block (Yeah, STX means "Start Of Text") so just look for STX then grab 2bytes then grab the rest. <These developers need to throw out their ASCII billboards and get a ASCII Chart on a mouse-pad> Yup,
- Then there are the "Chatty Cathy's" you know, the UARTs that just spew formless data ..... Those developers just need to go to school.
@JÞB wrote:
Declare Size of Package- yup ACSII STX Followed by 4 hex characters that define the size of the Text Block (Yeah, STX means "Start Of Text") so just look for STX then grab 2bytes then grab the rest. <These developers need to throw out their ASCII billboards and get a ASCII Chart on a mouse-pad>
The only time I have seen the STX character used is in a raw/hex/binary data format. Any ASCII based protocol I have seen has no start character, only a termination character.
Now in the case of this thread, we are dealing with a terminal. Terminals just write raw strings back and forth because there are an infinite number of possible commands. So the only real way to state that a command or data is done is to write a new line. Therefore, the termination character is very important.
Yes, I deal with Linux terminals constantly.
I definitely want to write out whatever comes over the serial port so a constantly running terminal is mostly like the best solution for my application. I have seen some protocols that are very strict like GPS ASCII data but the Command-Line-Interface (CLI) that I have worked with lately typically put out anything they see fit or even worse no response at all. Which usually leaves me with a follow-up command to get the data to confirm it was received. That is if they have written a "get" to get the information back.
I think Crossrulz has a solution to my initial problem (if you take out the caveat of the ">" character. Others have suggested solutions that I might investigate further when time permits. I do want to follow-up with how to handle a state machine in this event structure or outside of it in some event controlled fashion? Do you recommend I start a new thread, marking Crossrulz solution complete or continue here with the remainder of my application design question?
-SS
@ShotSimon wrote:
marking Crossrulz solution complete
Absolutely! 
@ShotSimon wrote:
I do want to follow-up with how to handle a state machine in this event structure or outside of it in some event controlled fashion? Do you recommend I start a new thread
Probably best to start a new thread.
@SpaceTrek wrote:
This solution works great for VISA read but I am not able to figure out how to add VISA write to the code based on user events on the UI like clicking specific buttons to send commands over VISA. Any help will be much appreciated.
VIWeek 2020/Proper way to communicate over serial
There are examples available that show this.
