Arduino Uno+Labview 8.5

[Dennis_Knutson]

Just noticed that with your incorrect idn? in MAX, you did not send cr/lf. Please test with the correct string and note exactly the termination characters that you do send with a successful transmission.

[barddya]

I don't think the issue is with Labview code. It appears you are not clear as to how Arduino works. 

Arduino is just an slave serial device. That means, arduino does only what you communicate to it via VIs and firmware it understand.

That is, you either use an existing VI and firwmware that is written already written for Arduino, or you create VIs that are tailor made and the firmware is modified to understand it

Strongly suggest you to go to LINX and use firmware and VIs that are already existing there and if needed, start by modifying a working one

https://www.labviewhacker.com/doku.php?id=libraries:linx:linx

Regards,

Barddya

[nyc_(is_out_of_here)]

---

@barddya wrote:

I don't think the issue is with Labview code. It appears you are not clear as to how Arduino works. 

Arduino is just an slave serial device. That means, arduino does only what you communicate to it via VIs and firmware it understand.

That is, you either use an existing VI and firwmware that is written already written for Arduino, or you create VIs that are tailor made and the firmware is modified to understand it

Strongly suggest you to go to LINX and use firmware and VIs that are already existing there and if needed, start by modifying a working one

https://www.labviewhacker.com/doku.php?id=libraries:linx:linx

Regards,

Barddya

---

He writes that he is able to communicate with the Arduino using NI-MAX's VISA Test Panel.

If that is the case, then he should be able to use LabVIEW instead.

[JohnCS]

 When the VISA Configure Serial Port.vi runs, a reset is asserted on the Arduino since VISA toggles  the DTR line. The Arduino will start to reboot then. It takes a few seconds for this to complete. Since you send the message without delay, the Arduino is not listening yet. When you communicate with the Arduino using MAX, there is only one  serial port initiation so the Arduino doesn't reboot with each communication. 

You could add a few lines to the Arduino app to make it send a message after it boots and have LabVIEW wait for the message to arrive by monitoring bytes at the port. . Alternately you could use a VISA property node to monitor the LabVIEW serial port and wait until DSR is set, then send your message.

JohnCS

[Dennis_Knutson]

What is in the the arduino code that would cause it to reset on a DTR? I'm not convinced that DTR is even asserted by the configure serial port and the code that doesn't call the configure port does not work either.

[JohnCS]

First, I should have looked at my notes before I dashed off that reply. Actually, it's CTS!  

I believe that the code which causes the reset is in the USB to TTL converter's firmware.

A quick look at the Arduio's schematic will show that CTS of the USB to TTL chip is hard-wired to the RESET of the ATMEL328. This is there to allow the IDE to access the boot loader. Regardless of the serial port settings on the Arduino, the UNO boot loader  always expects 115200-8-1-None. Any time the serial port is initialized or changed, the USB chip momentarily pulls its CTS low (a cap pulls it back high right away) which in turn RESETs the ATMEL328. If the IDE caused this, the firmware gets downloaded. Otherwise the boot loader waits for a few seconds, ready to receive new firmware. After the download or time-out, the USB chip returns to its previous serial configuration. The ATMEL328 reboots and is ready to run the app. When VISA initializes the port, the chip treats this the same way and the Arduino reboots. This is the expected behaviour.

This activity may be visible in the Serial Port Monitor.vi if one reduces the While Loop delay. 

The OPs vi doesn't wait long enough.

JohnCS

[zebraa]

Putting the command in a while loop makes it work. But I am not happy about it. Why can't single write even followed by wait (if u like) work? As seen in the serial port activity, who is 'cancelling the requests' and deleting the buffers?

[dkfire · Accepted solution]

---

@zebraa wrote:

Putting the command in a while loop makes it work. But I am not happy about it. Why can't single write even followed by wait (if u like) work? As seen in the serial port activity, who is 'cancelling the requests' and deleting the buffers?

---

First of all, the wait should be before the VISA write, not after. Try to set the wait to 2 sec.

Second, there is nobody to "cancel" a request. On a normal RS232 (COM) line you can send data without anything on the line. The serial communication does not have any way to know if someone has recieved the data being send. You have to program a retry if you do not receive a reply according to your protocol. This a nothing to do with LabVIEw, it is the nature of serial communication.

[zebraa]

Thank you dkfire! Wait time>= 1600ms worked! I never tried waiting before visa write. Why should you wait before writing? Could you please explain how waiting befor sending a command makes the command get through? Thanks a lot..   

[dkfire]

The reason for having the wait timer before the write is what JohnCS talked about is message 26.

After you configure the serial port, your Arduino board is rebooting. It will not be able to listne to any serial message before it has finished rebooting and is runing your program again.

The VISA write will write your data on the serial bus, not matter if the Arduino is ready for data or not. So if the Arduino is rebooting while you are writing to the serial bus, your Arduino program will never see that data.