How to read periodic signals from a compressor using RS232 serial communication in Labview

[moonlaker]

I want to test whether serial communication can work between a heat pump and a PC through LabVIEW. During the communication, I want to send a certain signal to change the compressor rotation speed of the heat pump and receive feedback from the heat pump to confirm if the compressor works at the specified speed. Sending signals is easy, but I don't know how to receive signals continuously. The heat pump transmits the internal status (169 bytes) as binary data in 1-second cycles. The first data after there has been no communication for 320 ms or more should be the first byte. By extracting the upper 8 bits of the 39th byte and the lower 8 bits of the 40th byte, 16-bit data can be formed from which the rotation speed for the compressor can be obtained. For example, the upper 8 bits of the 39th byte is 0x00, the lower 8 bits of the 40th byte is 0x00, so the 16-bit data should be 0x0000. How can I do in Labview to read this periodic data after 320ms? I tried it in the Open VISA Test Panel on MAX, but the error: a framing error occurred during transfer was reported. 

[crossrulz]

Framing error typically means you have a wrong setting (baud rate, number of start and/or stop bits, data bits per byte, handshaking, etc.).  Do you have a link to the manual to the heat pump that explains the communication scheme?

[moonlaker]

Thanks for your reply very much! Yes, I set up the baud rate, number of start and/or stop bits, parity in Labview from a one-page pdf file. I attached the Communication Standard of the compressor. Sorry, but I don't know what bits per byte and handshaking are. 

[crossrulz]

Well, from LabVIEW, you should have something like this.  I would need a lot more information on the format of the messages to be sure that part is correct.  But the initialization is what you need.

[moonlaker]

Sorry for the late reply and thanks for your advice. Sending commands from Labview worked and were relatively easy. I think the present problem is how to receive data from the compressor. The error shown in the attached picture came up every time I ran the program at first. This is probably because the speed at which Labview receives and processes the data is slower than the speed at which the compressor sends the data. To solve this problem, I added a block to the while loop that waits for 1 second (the period that the compressor sends data is 1 second). As a result, after the first few times I ran the program and that error came up and forced it to keep running by pressing continue, the error disappeared and the data continued to be displayed on the read buffer screen smoothly in a cycle of one second, but the length of the data in bytes was different each time. You can see this in the attached VI file and video. To give you one specific example, if you look at the attached photo, you will see that the number of bytes, not including spaces, is 134 bytes (268 characters * 0.5 bytes = 134 bytes since the data is displayed in hexadecimal). However, the number of bytes of data that can be produced in the one-second cycle by the compressor is 169. (That means the number of characters displayed in hexadecimal should be 338.) Looking at the video, there were times when 169 bytes of data came out, but I still don't know why the number of bytes was different each time. The purpose of receiving the data is to extract the 39th and 40th bytes of data from the 169 bytes of data and calculate the rotation speed at that time, so I want the data received from the device every second to be the 169 bytes of data. What should I do about this problem?

[Albert.Geven]

Hi

You should look at the example from Crossrulz and maybe your instrument ends the message with a linefeed or carriage return. In that case enable the end character and ask for more characters than needed, because the read will terminate on the end character.

Never use bytes at port when an end character is available, because if you ask the number of bytes available too early you only read part of the message.

And by the way, connecting the error wires is a good way to find out where the error occurred.