LabVIEW
VISA Write /Read
Hi Fredo,
@Fredo123Danzel wrote:
Unfortunately, I don’t have LabVIEW 2019.
I only use LabVIEW 2022
File -> Save for previous…
@Fredo123Danzel wrote:
I tested my system using PuTTY and found it to be very fast. That’s why I would like to develop a LabVIEW VI that can perform similarly to PuTTY.
What do you think of my VI, please?
Again, we need to know a lot more information on the messaging protocol your device is using. We can accomplish what you are asking, but you have to use the protocol to get anything useful out of it.
@Fredo123Danzel wrote:
use an RS232 communication (FTDI). The supported baud rate by the board is 115200 bps.
I send hexadecimal frames using VISA Write, and I would also like to read hexadecimal data.
You misunderstood crossrulz' request. The things you mention here were already quite clear. But there are about zillion ways to transfer binary data (you don't transfer hexadecimal data, that is just the format your logger chooses to present the binary data to you).
The data is binary obviously but in order to transfer binary data there needs to be some sort of format: start character, end character, possible CRC data, length of message or how that length is encoded, etc. etc. Are multibyte values little endian or big endian?
Without this information it is simply impossible to come up with a good programmatic algorithm to receive and decode the data, or generate according data to send to the device. So far you just showed pictures of the protocol logging with some random numbers shown in hexadecimal notations. No real explanation about what each of those messages should mean, which part is protocol signaling and which part is data. You need to provide this protocol documentation, we can't invent it ourselves. You have the device with which you can do experiments. I and everybody else here can investigate unclear and missing protocol documentation only if we can get our hands on the hardware itself and do trial and error, which is not an option here.
@Fredo123Danzel wrote:
I send hexadecimal frames using VISA Write, and I would also like to read hexadecimal data.
And how are those frames defined? Is there any documentation from your device?
Your still are very vague.
First, are those hex values simply the hexadecimal values of the bytes you sent over the line or are you converting your binary data to hexadecimal text to send as ASCII text?
What is the meaning of the individual values? Why does the command start with 1C or maybe 1C20, or is it rather 1C20AB? What are the remaining data before the CRC? Do you know the algorithm to calculate the CRC? What is it?
Similar questions about the response.
Is every command always 8 bytes long? And every response 10? If not how does the receiver know how many bytes to read?
So you have some fixed data sequences you have to write out. No problem, just write them. I can assure you that Putty won't be able to do it faster than LabVIEW. That's because the limiting factor by far is the serial port speed itself and with modern computers, LabVIEW can dance, balance an inverted pendulum, babysit a dozen of devices and send out a 8 byte string to your device at the same time you need to blink once.
The problem is with the receiving end and putty does it the very inefficient and slow way of reading one byte after the other until there are no bytes left. Since it is a terminal program the limiting factor here is you, the operator as you can't notice that the bytes arrive one after the others on screen. And that's it, your screen displays these characters and does absolutely nothing else with them. You can stare at the screen for hours and try to make sense of the displayed characters, or simply dismiss it and send another command and then stare at the characters appearing on screen.
In LabVIEW however you want to read a number of bytes and then do something with it. You could of course read one byte after the other with a VISA Read reading each time one byte. That would be pretty much the same as what putty does. But when do you stop? When there wasn't any byte anymore for 100 ms, or maybe 500 ms, or rather 2 seconds? You have to have some way to abort in order to let your program continue with the next step. If you chose the timeout to short, you may conclude that the device has finished sending because it was slower than the computer (which it almost always is). If you chose it to long, you get what you perceive as slow communication in LabVIEW since the VISA Read function waits the full timeout before returning a timeout error. So trying to mimic putty is not a very good strategy and it is not that putty is faster, but that what putty shows you appears faster but simply because putty does nothing else than constantly waiting on the serial line for new data and whenever it appears it displays it on the screen.
But I know how long my message is, it is always xyz bytes! Great! In that case simply issue a VISA Read for exactly this amount of data and the problem is solved.
Or, I do not know how long my response is beforehand but there are characteristics that are always the same. This could be:
- There is always a specific byte at the end of the message. Pronto, simply configure the VISA session to terminate on that character, and issue a VISA Read with more bytes to read than the longest message you expect. VISA Read will terminate as soon as it encounters that byte. This is most commonly used for text protocols where the command is terminated with carriage return, line feed or both. But there are also binary protocols that use for instance a start of text (0x2) and end of text (0x3) byte code. The difficulty is that if it is a true binary protocol, it can also contain these byte codes in the data part and the sender then has to escape it if it is part of the data by for instance doubling that byte. Your protocol seems definitely not to fall under this category since you have as last byte a CRC, which of course will vary with every text response depending on its content.
- There is a header of some sort that has always the same size and contains the number of variable sized data elements that follows.
- The size of the entire answer is known from one of the first bytes in the message and that indicates what type of response it is and that type of response has always the same amount of bytes for this particular type
- The size of the answer is known from the command that was previously send. That is a pretty unreliable method, since you can not be sure that you are reading the response to the last command or a response that was send to an earlier command but not yet read because of a software error or similar.
If your message protocol does not fall under one of these (and the last point I would also not really allow to count), it's not a protocol but garbage.
