Arduino resets when looping through flat sequence structure

[masaad]

Hi everyone,

I'm a biologist trying to use LabView and Arduino to make a setup for testing animal behavior. Briefly, the setup involves two levers (active and inactive) and when the animal presses the active lever the requisite number of times, he is automatically given a reward (e.g. a food pellet). During this time the lighting in the box is changed from red to white and the levers are automatically retracted until a preset timeout period (say 1 minute) passes. At that point the lights change back and the levers are deployed once again for another trial. The levers, lights, and food dispenser are all controlled via TTL triggers, as is the data coming in indicating when a lever is pressed, so I just have everything hooked up to an Arduino Uno and that board connected to the computer via USB so I can control everything with LabView.

I'm new to LabView, but the way I decided to do all this was to use a flat sequence structure where the first frame controls the food delivery period, the second frame retracts the levers and changes the lights, and the third frame just contains a time delay to set the time out period. The whole thing is inside of a for loop. However, whenever the for loop iterates it causes the arduino to reset giving out a voltage spike on the pins, which also means that a food pellet is delivered at the start of each new trial rather than just at the end.

I've tried moving around where the Arduino Initialize and Close blocks are with respect to the flat sequence but most changes just end up causing errors and not fixing anything. Is there a way to rewire things so that I only have to initialize and close things once? I've copied my code below. It contains a lot and probably isn't as efficient as it could be if I had more experience, but the main problem I believe is the relative positioning of the for loop, while loops, sequence structure, and Arduino initialize/close blocks.

(Also, a similar but distinct problem I've been having is that when I run the VI the Arduino typically doesn't initialize properly. The current workaround I'm using for this is to just press the reset button on the board after I run the VI in LabView and that seems to fix it, although it also causes a voltage spike so it's less than ideal and I was wondering if anybody had any insight into this issue as well.)

[Kristoff2]

Hello Masaad,

The Arduino will reset every time you call the Init VI.  Therefor init should only be called once per program.  Instead of re-calling the Init VI simply pass the Arduino reference cluster out of one frame into the next (you probably don't even need frames in this case).

Also you should not branch / split the Arduino reference wire.  While it will usually not cause problems it's possible that the return data will be out of order and the returned value could potentially be incorrect.

Finally a great place to get started with LabVIEW training is the Self-paced online training found here.

Let us know if you have any questions about any of this.

Thanks!

-Sam K

LabVIEW Hacker

Join / Follow the LabVIEW Hacker Group on google+

[Kristoff2]

I also though I should mention the LabVIEW example finder in case you were not aware of it.  In LabVIEW click Help>>Find Examples.  If you click the search tab and search for 'Arduino' you'll find a bunch of LIFA examples.  There are also many other good examples in there for almost anything you can think of.

Thanks!

-Sam K

LabVIEW Hacker

Join / Follow the LabVIEW Hacker Group on google+

[masaad]

Thanks for the help Sam, but I'm still a bit confused. I understand that I should only call init once, but I can't figure out how to do that. I tried moving it out of the sequence structure, as well as out of the for loop entirely, but neither seemed to work. I also tried using one init block and passing the cluster to the second frame as well but that doesn't seem to help. Maybe the problem has to do with the close blocks, typically when the program crashes those blocks are the ones that are flashing. Should they be moved out of the for loop as well? It seems they need to be called before the sequence strucutre can move onto the next frame, but perhaps I'm misunderstanding how this all works.

Or is there a better way to do this where I can get around needing to use a sequence structure at all?

[Kristoff2]

Hey Masaad,

Can you post your updated code.  Also check out the LabVIEW example finder (Help>>Find Examples) and search for Arduino.  Almost all of the examples use a while loop and show how to initialize the connection before the loop, do stuff in the loop, then close the connection at the end.

You may be able to avoid using the sequence structure using data flow to force things to execute in the order you want by wiring them in order.  Typically the error wire helps with this since most VIs have an error in and error out at the bottom.

Thanks!

-Sam K

LabVIEW Hacker

Join / Follow the LabVIEW Hacker Group on google+

[masaad]

I don't have any updated code as what I originally posted seems to be the best version so far. It's the only one that actually runs as I want it to, with the only issue being that the arduino resets when the for loop re-iterates. All the alternatives I've tried have involved only using one init and passing its information to the second frame of the sequence structure, moving the init block out of the sequence structure (or out of the for loop), and moving the close block out of the sequence structure (and various permutations of all those things). But they all seem to give out errors and not even run the second frame properly.

Normally a red LED turns off and white LEDs turn on as part of the second frame of the sequence structure, but when I get the errors the red turns off but the white doesn't turn on, which is strange because both should happen simultaneously in the same while loop. Also strange is that, as I mentioned, the errors tend to make the close blocks of the second frame (when the LEDs are supposed to switch) flash.

I looked through the examples and I have no problem using LabView to control the arduino normally, but none of them address this problem of needing it to do two different tasks in a sequence. They put one init block outside of the while loop, and one close block per pin outside as well, with everything else running within the while loop, which is what my code does as well.

Basically my setup is supposed to work in three stages (first is animal response, second the animal receives a reward, third is a delay period, this it repeats). I tried to think of alternative ways to do it like by using case structures like if statements to trigger the next stage of the experiment, but I believe that that will end up being more complicated than using a sequence structure, especially since it has to repeat (but I could be mistaken).

I know this might be too complicated of an issue to solve, but I appreciate any suggestions. As I said, I don't really know LabView's language that well and it's pretty different from most programming that I'm used to.

[Kristoff2 · Accepted solution]

Hey Masaad,

The LIFA VIs are going to execute sequentally no matter what so there is no reason to split the Arduino reference wire.  Instead do everything in a single sequence.  I made a sample VI using LINX (the successor to LIFA) since I didn't have LIFA installed on this computer.  This example should give you an idea of how your program should look at a high level, you'll need to add your own code to the various stages and loops, but let me know if you have more questions about this.

(you can get LINX here if you want to start using it, but you'll have the same restrictions as your code above using LIFA).

Thanks

-Sam K

LabVIEW Hacker

Join / Follow the LabVIEW Hacker Group on google+

[masaad]

Hi Sam,

Restructing my code more like your example fixed the problem, thank you so much!

I do have a different problem that's happening now though that I've never experienced before. For some reason the arduino board doesn't seem to function properly anymore a lot of the time. For example, it will run the code properly maybe once or twice, but on subsequent runs it just doesn't work. For example, in the begining of my code the levers are supposed to be deployed, but when the board is acting strangly it won't do that. And when I unplug it from the computer the LED and ON lights on the board stay dimly lit, even though there's no power being supplied to the unit. I try exiting LabView and reuploading LIFA_Base but the program says that the COM port is already in use. Restarting the computer seems to fix it temporarily, as does reinstalling the drivers (sometimes). I also tried using a different board (still and Uno) and it happened again. I know this isn't an Arduino forum, but I've never seen anything like this before and I think it might have to do with the LabView interfacing.

Does this sound like the kind of bug that might be better if I switched to LINX? Have you seen anything like this before?

Thanks,

masaad

[Nathan_B.]

It sounds like either you are not using the LIFA Close VI after the loop has finised or you are using the abort button (the red stop sign button) which you should try to avoid doing.  If you do need to abort or do it by accident, you should be able to open the LIFA Close VI and simply run it to clear the COM port then you can run your VI again or connect via the Arduino IDE as needed.

If you have further issues, you might consider posting the latest version of your VI.

[Kristoff2]

Masaad,

As I read your latest post my first thought was what Nathan suggested above.  If you do not call the Arduino Close at the end of your application (or you hit abort and the Close does not execute) the COM port will remain reserved and will likely generate errors the next time you try to run your code.  Proper error handling such as ORing your stop condition with the error cluster should make the error obvious (all of the LIFA examples should use this method).

Are you powering the board externally (ie not through USB)?  From your description it sounds like you completely disconnect the board from the PC (and power?) and the lights remain dimly lit.  This can happen if the board is drawing power from other connected wires (such as digital lines).  This is almost always a bad thing and means that something is connected incorrectly or is connected to a bad circuit.

Thanks

-Sam K

LabVIEW Hacker

Join / Follow the LabVIEW Hacker Group on google+