Using DAQ Assistant to write to multiple digital outputs

[Catriona]

Hi guys,

Firstly, I am a total beginner, thrown into the deep end by being asked to write a test program for batteries.I have 10 batteries that will all be connected via relays to a single load and voltage measuring channel.  I will also have a single load current and temperature measuring channels.  I've attached my block diagram for reference.

Each battery will go through a load sequence where during the batteries measuring cycle the load will be connected to increase the current from a simulated quiescent current to an active current.  The basic sequence is as follows:

1. connect battery 1 to measuring channel via relay 1

2. turn on relay 12 to pre-set the load to the required current

3. turn on relay 11 to connect battery 1 to the load

4. turn off relay 11

5. turn off relay 12

6 turn off relay 1

7 repeat steps 1-6 for relays 2 to 10 then start back at relay 1

because I'm using simulated channels at the moment I'm using array indicators to try and track the digital outputs.  I have no way of knowing at this stage if this program will actually write to the digital outputs with the way I have set them up.

My first question is, is it OK to have multiple DAQ assistants which are set to the same channels?  If you look at my diagram each DAQ assistance labeled as R11-R14 are all set to the same digital outputs.  I have searched for days trying to get an answer to this question but I haven't found anything!

Secondly, when I run it, it seem to work fine for a while then I get an error "Error - 200587 occurred at DAQmx Start Task.vi:7220062.  I have attached screen shots for the whole message.  Can anyone tell me what the cause and solution to this is?

As I say, I'm a beginner so a lot of this is over my head and I'm just muddling through.  Any quick and simple examples of solutions would be greatly appreciated! 

[Bob_Schor]

The Dreaded DAQ Assistant (a.k.a. DDA) is wonderful for allowing beginning LabVIEW Programmers to "byte off far more than they can chew".  For doing one (very) simple task, they are fine (though MAX is much easier to use!).  But any time you want to do something a little more complicated, you want to go straight to DAQmx, which is not as difficult as it sounds to learn and use.  There are some excellent Tutorials and White Papers from NI -- one of my favorites (which really sold me on DAQmx) is called "Everything I Wanted To Know About Data Acquisition With DAQmx, But Was Afraid to Ask" (I'm only kidding -- here is the link to "Learn 10 Functions in NI-DAQmx and Handle 80 Percent of your Data Acquisition A...).

Now let's think about what you want to do, and why you should strive (especially when starting out with LabVIEW) to not use a Sequence Structure (there will come a time, when you've used LabVIEW for a year or two, that you'll have a place that a Sequence is a Good Idea, maybe ...).

You have 10 Test Channels (controlled by Relays 1 to 10).  You want to run a test with each Test Channel in turn, then "do it again until I tell you to stop".

1. What LabVIEW structure is appropriate for "Do it over-and-over until I tell you to stop"?
2. What LabVIEW structure is appropriate for "Do such-and-such for Test Channels 1 through 10"?
3. What is the (logical) relationship between the Structure for (1) and the Structure for (2)?

The Test involves a sequence of operations (how many?) involving the Test Channel and possibly two other Channels.  Generally, a better structure for a Sequence of Operations is something called a State Machine, usually constructed as a While or For loop (stepping through the States) surrounding a Case Statement (that "selects" the Case).  While it is true that your problem could be done with a Sequence, you might as well learn "better design" early.  So what are your "States"?

1. Turn on the Relay for the chosen Test Channel.  Wait some period of time.
2. Turn on the Relay to pre-set the load to the required current (whatever that means).  Wait for some period of time.
3. Turn on the Relay to connect the Test Channel to the load.  Wait some period of time.
4. Turn off the Relay from Step 3.  Wait some period of time.
5. Turn off the Relay from Step 2.  Wait some period of time.
6. Turn off the Relay from Step 1.  Wait some period of time.

Note that some of the above States might be combined, particularly if they can be done more-or-less at the same time.  Do you see an easy way of going from State to State?  Hint -- is there anything that "counts" in a While or For Loop?

Because you attached a picture of your code (instead of the actual code), I can't "peek inside the code" to see if I can figure out what hardware you are using.  I presume you know how to make your hardware turn on (or off) a specific relay -- you only have to put that "Relay On-Off" function inside the relevant States of your State Machine.

And if you don't know about "Shift Registers" (which are LabVIEW's "memory of values you need while a Loop is running"), this is a very good time to learn about them.  I'll bet a Web Search can help you find out about them if you have the need.

Bob Schor 

[Catriona]

Hi Bob,

Thank you you for your comprehensive reply.  I’m afraid I’m well aware my lack of understanding and lack of time to learn is causing all the issues.

ive tried to limit the sequence structure as much as possible and I did kind of manage to do this with the first 10 relays by using the loop counter.  I’ve not heard of the relay on off function so I’ll definatly have a look at that. 

Do you have an idea what might be causing my error message, or would you need me to post my VI? I’m going to try and get rid of my local variables and see if that helps as I’ve heard they can be a pain for runaway conditions.

[Bob_Schor · Accepted solution]

---

@Catriona wrote:

Do you have an idea what might be causing my error message, or would you need me to post my VI? I’m going to try and get rid of my local variables and see if that helps as I’ve heard they can be a pain for runaway conditions.

---

Yes, do what you can to "neaten" and "tighten" your code.  It certainly helps if we have the VI(s) to examine, edit, and run.  The more information you can provide, the more likely that someone will have a "useful insight" (as opposed to an "optimistic guess").

Bob Schor