LabVIEW
Commniucation with port com
@Andrey_Dmitriev wrote:
Then you should explain this to NI first to remove this from standard NI examples. In general this way could be helpful at the beginning if developer would like to check if something in port at all then read. But later replace it with reading till terminator or fixed amount of bytes, agree. I've used this several times during putting some specific devices into operation, but haven't any in production code at the end.
I had been periodically screaming for years for NI to get rid of the Simple Serial example. That was the reason I made that presentation. It is actually too generic to be useful. You actually need something like 4 or 6 examples to do this properly, which I laid out in the presentation.
@Sina6611 wrote:
Hello,
I made the following program to communicate with the Serial port (Com port). Through this program, I send commands to the device, but it happens nothing. Thank-you. When I send with Terminal program commands to the device. It Works. Can anyone give me a solution.
In order for us to really help you, you really need to give us a lot more information. What device are you communicating with? What is it's messaging protocol?
It works with a terminal, so I am left to assume the following:
- It is an ASCII-based protocol.
- It has a termination character, likely a Line Feed (0x0A).
With this limited information, I would change the following things in your VI:
- Remove the Open VI Session inside of the loop. There is no reason to keep opening the session repeatedly. The VISA Configure Serial Port before the loop is all you need.
- As previously stated, you are using a very unusual baud rate. Double check that value. If it is not correct, there is no way you will be able to talk with your device. I also tend to just leave the rest of the inputs to the VISA Configure Serial Port unwired as the defaults are correct in 95% of the cases.
- Use Concatenate String to force a Carriage Return and a Line Feed to be appended to your command. Many terminals send both, so I would start with that. If using Windows, use the End Of Line Constant.
- DO NOT USE THE BYTES AT PORT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! (still not enough emphasis). Get rid of the Bytes At Port and just tell the VISA Read to read more bytes than you ever expect in a message. I tend to use 50 or 100, depending on the device. But my reuse code sets it to 4096.
@crossrulz wrote:
- DO NOT USE THE BYTES AT PORT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! (still not enough emphasis). Get rid of the Bytes At Port and just tell the VISA Read to read more bytes than you ever expect in a message. I tend to use 50 or 100, depending on the device. But my reuse code sets it to 4096.
To be honest, I still not fully understand your statement. Why do not use? Some known issues? The Number of Bytes at Serial Port property specifies the number of bytes currently available at the serial port used by this session at the moment when it was called, it is clearly described in Help. Let's say — I would like to know which amount of bytes are available at the moment of call and don't want to read these immediately (why this is my own problem), just count, nothing more. Which race conditions can be introduced here? It should be obvious to everyone that if you use it as shown in the NI's example, then the following VISA read may not get all bytes, because new bytes can arrive after the "Number of Bytes at Serial Port" call but before the VISA Read call. The following VISA Read will not deliver all the bytes, and as result some will remain in the interface. If a developers thinks that with this sequence they will get the full response from the device, then they are wrong, of course. However, there is nothing inherently wrong with this property if it is properly used. On the other hand, this property is really needed very rarely.
The bad thing is that beginners can use this property in the wrong way, but here, the only long experience and a crisp and clear understanding of how it works can help to get a feeling of when it should be used or not.
Can you provide any simple snippet which will demonstrate "weird race conditions" with Number of Bytes at Serial Port?
For me race condition is something like that:
@Andrey_Dmitriev wrote:Can you provide any simple snippet which will demonstrate "weird race conditions" with Number of Bytes at Serial Port?
It is not a race condition inside of the code itself. It is a race condition with the device, communication bus, and the code. The Simple Serial example shows the race condition.
But let's take a step back. The point of communication, in general, is to pass messages back and forth. Those messages contain data, ideas, acknowledgements, etc. The goal for when you read a message is to have a complete message and nothing else so that you can then process that message.
Now the classic race condition with serial communications is you send a message to a device. It takes time for the message to be sent through the port, transmitted across the wires, for the device's port to receive the message, the device process the message, the device actually do something with the message, the device to send back response, and repeat everything above but in the reverse direction. Where most people start is they write the message to VISA and then immediately check the Bytes At Port and get nothing back. So then they add a delay and they only get a part of a message, which is still a failure to communicate. So they add more delay and then it works most of the time, but every once in a while still only get a partial message. So they add more delay. This dramatically slows down your code unnecessarily. This is the danger of using the Bytes At Port.
Assuming an ASCII protocol (which a very large percentage of devices use), you just write your message and then you can immediately try to read more bytes than you expect in a message and the read will end with the termination character. As long as your timeout is long enough, the termination character is what tells you the message is complete, and it works down to the VISA level.
Now I need to clarify one more thing. I do not believe that the Bytes At Port should never be used. I use it quite a bit, but only to tell me if a message has at least started to come in. But the Bytes At Port should never (as in >99.9% of the time) be wired directly to a VISA Read. If you actually watch my video, I thought I made this clear.
But you may have a point on the needing to update my macro to clear this up. It is like when there was a mantra of "never use a local variable" was a reaction to so many issues caused by people avoiding data flow. Local Variables do have their place, but not where they were most commonly being used. Same here: The Bytes At Port does have a good use, just not where the example shows it.
Ok, ranting over...
