Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

Help with time delay between subsequent DAQmx Write commands...Switching digital out high/low states throughout a task with NI 9401?

Solved!
Go to solution

Hello, I am hoping someone can help point me in the right direction..

 

I have a 9401 module that I am using to write some high/low signals on each of the 8 lines. The VI creates a channel and writes a boolean array of high/low values out of the port0 of the module. This is inside of a "for" loop and can be stopped manually. The task continues on to the next Write command inside of another "for" loop.

 

I want to change from one boolean state to the next without having to click stop buttons on the previous "for" loop. I haven't found any DAQmx functions that allow me to insert a time delay between each Write command. My only thought is to use a Timed Sequence structure, but I don't have the experience to know if that's a step in the right direction.

 

Can anyone please provide their input here? Any help is greatly appreciated. I'm trying to learn the ropes of DAQmx.

0 Kudos
Message 1 of 8
(3,242 Views)

Hi,

 

the VI structure shows three While loops. The way they are wired, means that initially, only the first will be running and the others will be frozen. Only when you hit the first "stop", will the second while loop start and so on...So they will not run in parallel, in case you are wishing this.

 

There is no timing inside the loops and the DAQmx blocks seem to be configured, to create one sample (in this case one array) at once in one channel. This means that the loops will try to run as fast as possible and perhaps not. I suggest you either:

 

  • Add timing information (like a Wait.VI or a Wait till next multipl.VI) or
  • You change the DAQmx write mode to multiple channels (depends, how long each pattern should "stay" on the NI-9401 outputs) or
  • You use a Timed Structure; they are actually straight forward, and have good troubleshooting features.Especially if you run your programm on hardware featuring an embedded controller this would be one an option. Depends if you have real-time requirements or not.


Message 2 of 8
(3,206 Views)

Lysandros, thanks for the reply.

 

I wired these write commands into loops because it is the only way I could get it to work this far. The problem is how to separate each of the DAQ Write commands so that they operate one after another. If you took the loops out of the VI I would have the same problem.

 

- I don't see how adding timing information for each loop would help. Am I misunderstanding how it works? I've used a Wait.VI in the first loop in the past, but this doesn't tell the program to move on to the next DAQ Write command. Is there a way to tell the first loop to iterate for a specified amount of time and then have the code move on to the next loop? I wish there was a DAQmx function that could tell the task to wait for (____ ms) before moving forward, but there doesn't seem to be one that exists.

 

- I could change DAQmx to write to multiple channels, but what I need is one 8 line configuration that changes to the next configuration. I think splitting it up into each of the 8 lines/channels would make things more confusing for me unless you have a recommendation. So far, controlling the entire port with a Boolean button array has been the easiest and most successful method I've tried.

 

- I'm going to attempt to use a Timed Sequence VI. Unfortunately there aren't many examples out there for this VI and I'm not sure if it is what I need, but I'm willing to give it a try.

 

It would be idea if a Timed Sequence would allow me to:

 

1) first frame - run the first DAQ Write command for 2 seconds

2) second frame - run the second DAQ Write command for 2 seconds

2) third frame - run the 3rd DAQ Write command for 2 seconds.

4) fourth frame  - end the task

0 Kudos
Message 3 of 8
(3,198 Views)
Solution
Accepted by topic author JAB2019

You can use insert a Wait Until next VI and feed it with a value of e.g. 4000 ms. This would mean that the loop would iterate once in an overall duration of 4 seconds. The you also wire the iteration terminal of the while loop to a compare block and comapare the i value e.g. with 3. If the iteration value is higher than 3 then the boolean output is be wired to the Stop condition of the while loop. This means that, after 12+4 seconds your loop will stop and the program will proceed according to the direction of error wiring.

 

Indeed, splitting the boolean array into individual booleans would not make sense. I mean that you could output multiple arrays, for example the same array for 10000 times.

Good luck



0 Kudos
Message 4 of 8
(3,174 Views)
Solution
Accepted by topic author JAB2019

Here's an imperfect example of a very simple way to do it.  I'd still recommend you try to learn about state machines as I suggested in a related thread, but the approach below will work for your 1 very specific app right now.  (A state machine would be harder to implement the first time, but would be much easier to maintain, modify, and adapt.)

 

There's a cluster that bundles the digital state (1D array of booleans) with timing info (how long to wait after writing the new digital state).  I made an array of that cluster which is auto-indexed in a For loop.  Each iteration will increment through the array, writing the digital state then waiting for the proscribed time delay. 

 

 

-Kevin P

 

do update and wait.png

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 5 of 8
(3,147 Views)

Based on these replies I built two programs that do what I need to do, 1 using a for loop with the recommendations for controlling it, and one using a sequence structure with Wait.vi in between write commands. It was also useful to create some test programs to see how fast the DAQmx write can run this way and it appears to be limited to 20ms.

 

Kevin, I like that your loop simplifies the input data. I hadn't thought of doing it this way because I've never used those functions before, so thanks for the example. I'm figuring out how to recreate it.

0 Kudos
Message 6 of 8
(3,142 Views)

To "recreate it", you could start by saving the .png snippet file I attached, then dragging it into an empty block diagram.  It'll turn back into real LabVIEW code!  That's what snippets do!  (Note: it was saved from LV 2016 so you'd need to be running LV 2016 or later).

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 7 of 8
(3,136 Views)

Wow, that is incredibly useful. Thank you very much for your help and patience.

0 Kudos
Message 8 of 8
(3,134 Views)