Communication issue between a MCU and LabVIEW

[MSebastian]

Hello,

I'm trying to establish a connection between an ATmega16 and LabVIEW. I've attached some files below, which I hope are useful.

My objective is to send a character "A" using the USART communication protocol to LabVIEW and I want LabVIEW to display said character.

Frame format:

• Start bit
• Data bits: 8
• Parity bit: odd
• Stop bit

I've connected an oscilloscope to the TX pin of the MCU and it looks like it is sending the correct data. After checking the TX pin with the oscilloscope, I've used a serial port monitor to see if the sent data is received by my computer. Again, just like my oscilloscope, the serial port monitor reads the correct data.

The problem is that LabVIEW doesn't seem to receive any data from the MCU, not even wrong information. Whenever I highlight the execution I get an error, which I've attached below. I've watched a video about the proper way to communicate over serial and nothing seems to work. At some point I tried to do it the other way around and send data from LabVIEW to the MCU and it didn't work.

If it is of any use, I've managed to send data back and forth between LabVIEW and Proteus using the ATmega16, however I did that through a virtual connection.

What am I doing wrong?

Is there any other driver besides NI VISA that I should install?

Thank you,

Sebastian

[crossrulz]

Typically when something this horrible goes wrong, it is a hardware issue.  Given your description, it is likely that the port has not been properly closed and your LabVIEW code cannot properly open it.

From your code, I see that you are never actually closing the port.  That is a major red flag.  Make a stop button to stop your loop and then let the VISA Close close the port.  Do not rely on the Abort button as this will leave your hardware in an unknown state and not properly close things down.

I'm also concerned about your waveform from the oscilloscope since it does not actually look like RS-232.  It instead looks like TTL UART.  Was this probed on the cable or between the MAX232 and the MCU?

Additionally, I question if a parity bit is actually being used.  It doesn't show up in the waveform (odd parity would make this a 1, which matches the stop and idle bits).  This is not likely your problem as you would get a framing error, not an unknown hardware error.

[MSebastian]

I made a stop button and whenever I press it I get the same error.

You said that I never actually closed the port. Does that mean I have to manually close it because I relied on the abort button so many times or does LabVIEW take care of it?

That waveform is indeed TTL UART since I probed it between the MAX232 and the MCU.

Also, you are right about the parity bit as one is not being used. I changed that in my LabVIEW code.

[crossrulz]

---

@MSebastian wrote:

You said that I never actually closed the port. Does that mean I have to manually close it because I relied on the abort button so many times or does LabVIEW take care of it?

---

When you use the Abort button, you are never calling the VISA Close.  So the resource is leaked.  The only real way I have found that can fix that leak is to close LabVIEW.  In rare cases, I had to reboot the computer.

[MSebastian · Accepted solution]

It works now.

The MCU sends data to LabVIEW through a CH340 USB to RS-232 cable and a driver needs to be installed in order for the computer to receive data.

I tried to open the VISA test panel in NI MAX for COM5, as this was the port the USB end of the cable was connected to. Every time I tried to open the panel I was getting the unknown system error. After installing the driver, I could finally open the test panel and LabVIEW was displaying the character 'A'.

I've attached the driver below, just in case someone else needs it.

Thank you for your time!