LabVIEW
Reading and decoding binary packets with serial communication
Solved!
That should be 0 not 5! If for some reasons the remainder of the message that needs to be read is 5, it will fail now!
And you do likely not read the matching message but some other message even though the address is the same. You request 7 registers but only get back 1. So either the device decided to only return one register since the registers directly beyond that one are invalid, or you received a different message that the device was spitting out on its own and the response that was returned for your command is still in the queue.
@constructionworker wrote:
I changed it to 0, nothing changed, the data can still be read.
Yes this should have been 0. I told you there were still little critters (bugs) in the code that are hard to squash when you can't run the code with a real device.
I tried different addresses, I can read from those addresses. I haven't tried multi-reading.
And you do likely not read the matching message but some other message even though the address is the same.
I don't fully understand what you're saying here.
Currently, the device does not spit out different messages. Because when I open different broadcasts, the values I read get mixed up.
In the image you show you specify to read 7 registers so the function should send a command that tells the device to return 7 registers in batch mode. But you only receive 1. Since you receive no error, the received message seems to be valid with correct CRC, so it can't be a decoding issue.
This leaves only 3 options:
- The device returns different packages on its own, but you say you disabled that.
- The device decides to only return 1 register anyhow, for instance since the register right after it is not a valid register address and hence can't be returned.
- The code to write a command to the device somehow doesn't properly encode the number of registers to return or doesn't enable the batch mode bit.
And of course once we know that something seems to be off, it is very easy to spot the error in UM7 IME Write Packet Frame.vi. \facepalm
Yes I updated the UM7 IME Write Frame Packet.vi (and fixed the error you found in UM7 IME Read Frame Packet.vi too) and appended the new archive.
It now set the Batch flag correctly if you request more than one register so that the device should return accordingly multiple registers.
@constructionworker wrote:
I've done some testing right now and I've found that the field here is not working properly. because i''write registers'' field always gives a value of 0. Therefore, only one address can be read. I have elaborated a little more in the picture below. Do you think there is something wrong here?
Yes I do! Tip, check your image with the image I posted 3 posts earlier. Do you see any difference? I described what was the problem, added a picture of the diagram and a ZIP archive with fixed VIs there!
Also you still have trouble to understand even basic LabVIEW programming it seems. I really would recommend you to go through those training materials linked to at the top of this LabVIEW forum.
What are the errors you get? Why do you not show the error cluster on your VI panel? What is the timeout you specify when initializing the serial port?
Most likely what happens is that you get some error in one of the VISA Read function, likely a timeout error. Why? Well here ends may ability to guess things. Without hardware to debug with it's pretty much impossible to do any more analyzing.
