LabVIEW Interface for Arduino Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Using the "write digital port" function with Arduino Mega

Solved!
Go to solution

I am currently using an Arduiino Mega as digital I/O interface in a system including a PXI frame (DMM, NiScope, NiSwitches, NiDCPower, SMU), multiple DC power sources, and an electronic load. The system is targeting automated testing for DC-DC applications and uses LabVIEW 2013. Until now I was using only the "write digital pin" function, but the more I/Os I need to control, the longer the waiting time...

There is a function working on Arduino Uno for writing an entire port using a single VI, which obviously works significantly faster. I am trying to build an equivalent VI for Arduino Mega, but this research tends to get longer than a couple of hours, so I would kindly ask for guidance. The main issue I got stuck with was creating the right data packet which must contain the addresses of the ports I want to write to. I am not good with programming, but I have been able so far to work quite well with LabVIEW.

Thanks in advance,

Catalin

0 Kudos
Message 1 of 15
(9,314 Views)

Wrote this a while back (almost a year ago I think) but I couldn't find where I posted it so here it is again.  Requires the included custom firmware.

EDIT:  Change the firmware function so that it ignores pins 0 and 1 (the original still WriteDigitalPort function still writes to pins 0 and 1 though).

EDIT2:  Added a function to write to 8 digital pins at once, Digital Write Byte.vi.

EDIT3:  Fixed the Digital Write Byte function in the Arduino firmware.

0 Kudos
Message 2 of 15
(5,784 Views)

Thank you Nathan,

As far as I understand, I need to update the firmware of the uP on the Arduino board.

Does this firmware work well with all the existing VIs available with the standard LIFA "package"?

One thing I couldn't yet understand related to all the VIs like "writedigital port ": where is it localized the piece of information that specifies the address of the port(s) where the individual bits' values are written? My ultimate goal would be to be able to write to a series of digital pins, say 32 to 39 (one byte). What I saw so far is that when the packet is built, the first portion consists of a hex number, but I couldn't find what does it actually represent. Is there a simple way to "encode" the start/stop pins where the bits' values are written?

All the best,

Catalin

0 Kudos
Message 3 of 15
(5,784 Views)
Solution
Accepted by topic author catalin23

The files that I gave you are for the latest version of LIFA and will work with all existing functions.  I.e. The firmware is basically identical but with one extra function added to it.  It writes all the digital pins at once.  To select a subset of the digital pins dynamically, a new function would need to be written specifically for that.

If you only need eight consecutive digital pins to be set at one time, then it should be fairly easy to write a custom function for that (new custom firmware and new LabVIEW functions).

About the packet structure:

The first element of the array provided to the "Send Receive" VI is a reference to the function (which is handled by a case statement in the firmware).

0 Kudos
Message 4 of 15
(5,784 Views)

Hi Nathan,

Thanks again! Now I have a better understanding of how it works. I'll load the new firmware and see how fast it works this all-at-once digital write VI. If fast enough, I may not need to address a specific byte, but just write all bits at once. One last question: should I just ignore the first two pins (those which carry out the communication between Arduino and LabVIEW), or set them to zero and only account for their presence in the data array (to preserve the location of my written bits)?

Catalin

0 Kudos
Message 5 of 15
(5,784 Views)

The original Digital Write Port writes to pins 1 and 0 so I didn't change that part.  But, I have now.  Re-download the attachment above.  It should ignore the values that would normally be written to 1 and 0.  Therefore, the order and pin numbers are preserved and will match the array index.

0 Kudos
Message 6 of 15
(5,784 Views)

I just wrote a VI (and edited the firmware) that adds the ability to write a byte of information to digital pins (i.e. write to 8 digital pins).  If you only need 8 or 16 digital pins, this might be better for you (pins must be consecutive but you can start at any pin).

Let me know if this one works because I was not able to test it.

0 Kudos
Message 7 of 15
(5,784 Views)

Hi Nathan,

This is great! Thanks a lot! I'll test it tomorrow and see how it works. Since I don't see any other attachments, I assume you replaced all the new files in the same zip.

All the best,

Catalin

0 Kudos
Message 8 of 15
(5,784 Views)

Yep.  Both functions are in the original zip file.

0 Kudos
Message 9 of 15
(5,784 Views)

Hi Nathan,

Thank you for your effort. Good news and bad news so far. I loaded the new firmware and all the old VIs seem to work fine. The program I have developed (including Arduino usage) performed exactly as before. I tried then to use the VI that writes a byte at once. Here it's what happens: the LSB is always wrote correctly, but all other bits remain zero. I opened the VI and placed an indicator on the output of the "build array" VI that feeds the "Write" sub-VI. The array is built from 3 elements: a hex number (the constant you used - its value reads 253 - which I assume is correct), the start pin (which in my case is 32 - and is displayed correctly), and the number corresponding to the byte value (which is correct as well - have placed another indicator to monitor all data fed to the VI from my side of the code). However, only pin 32 works. I cannot positively tell if any signal propagated somewhere else, but since the application worked well otherwise, I assume no other output was changed accidentaly instead of the desired one (I use many other pins as outputs and the whole program would go crazy if some wrong outputs are exercised). At this point, I cannot find any issue with the VI itself (I also checked the error wire - the VI does not generate any error), so my first guess would be that the new function in the firmware is not able to use correctly the "write" VI and pass on all the data. If it helps in debugging, please let me know what other tests I can perform. Thanks again for helping me on this.

All the best,

Catalin

0 Kudos
Message 10 of 15
(5,784 Views)