LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Arduino Uno+Labview 8.5

Solved!
Go to solution
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.
0 Kudos
Message 21 of 31
(3,119 Views)

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

0 Kudos
Message 22 of 31
(3,101 Views)

@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.

 

0 Kudos
Message 23 of 31
(3,086 Views)

 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

0 Kudos
Message 24 of 31
(3,056 Views)
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.
0 Kudos
Message 25 of 31
(3,042 Views)

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

Message 26 of 31
(3,027 Views)

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?

0 Kudos
Message 27 of 31
(2,994 Views)
Solution
Accepted by zebraa

@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.

0 Kudos
Message 28 of 31
(2,976 Views)

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..   

0 Kudos
Message 29 of 31
(2,960 Views)

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.

0 Kudos
Message 30 of 31
(2,949 Views)