Someone spoon feed to me how to handle a handful of digital IO without causing my program to run extremely slow

[BertMcMahan]

My dude, your problem is that you're using a full programming language with an incredibly flexible piece of hardware (that you didn't specify until just now), and saying "How do I make this work?"

To speak PLC, your question is "I have a PLC, and I'm way overdue on a project- I can't share my code, but why is my IO timing slow?"

We have no idea. We do not have crystal balls. We asked questions and gave you good advice, and you're lashing out. We are more than happy to help you, but you're not asking specific questions.

The DAQ hardware you have can be configured for a massive amount of different tasks. You said, in your first post, "I am struggling to understand everything that's required to properly configure the IO". We do not know what you want the IO to do.

I have written programs to use this hardware for ultra high speed, single photon detector sampling for physics experiments. I have used it for weeks-long sampling to notice an event that happens once every month, and must be timed to the hundredth of a second. And I have configured IO to turn a light on when the test is done. All of these things require different setups.

So, lets back up, and ELI5 the questions we need answered.

1- How many IO's are you looking to create?

2- How often do they need to update?

3- How accurate does the timing need to be? Does it need to happen within seconds? Milliseconds? Microseconds?

4- Can you provide ANY example code to show what you've tried? We do not care about the business logic; just the IO logic. Even a screenshot of just the IO portion would be helpful, though it's extremely hard to debug a picture...

What it SOUNDS LIKE to me, with over a decade of DAQmx experience and a lot of trying to parse out what people are "actually trying to do", is that you want to have your program control multiple outputs- somewhere around 20 or so (?)- and you want to do that from different places in your code. It doesn't seem like they all need to update synchronously. You don't want a single call to DAQmx Write to update all of your outputs at once, you want multiple ones throughout your code so they can update as needed.

Is all that right? If not, please correct me.

BTW- you're dealing with some of the most knowledgeable DAQmx users on the planet*, giving you their time for free, of their own volition, so when they ask questions it's not because they're just talking for the fun of it, it's because your answer matters, and we're shooting in the dark here. It's not fair to us to try to pry out your requirements from you. I know you think we're not being helpful, but trust me, the posts you've received ARE trying to help you.

*I'm certainly not vain enough to include myself in this list, but I do count at least 5 people in this thread who can solve your problem in their sleep, and they're all struggling to figure out what exactly you're trying to do, so please throw us a bone and be more descriptive.

[nathan_t]

Your understanding is correct. You were able to surmise my overall need, just as I said you should. Good job. I stated that the problematic IO is digital (specifically photoelectric sensors, limit switches, LED indicators, solenoid valves, etc.).

Specific question I asked in a previous reply - "Basically, how can I put multiple digital outputs on a single task and control them each individually using DAQmx Write VIs?"

Thank you for actually making an effort to help, I truly appreciate it.

[nathan_t]

And to answer your questions - There are 8 DO and 7 DI. 2 pulse gen counter outputs, 2 rising edge counter inputs (although I would like for one of those to be frequency but Labview doesn't function when I do that, for some unknown reason). Update time should just be the time of the main loop (so 10-50ms, doesn't really matter). Update every loop iteration.

I figured out how to use an array to put all the DO & DI on their own task. Testing that today.

[BertMcMahan]

You still haven't answered the timing aspect of it. How fast does all of this need to happen? That's the critical part we've been trying to get to the bottom of.

Edit: Ah OK, you answered the timing part! Awesome.

So, the short answer is you can't just write to one IO from a task. When you have a task, all get written or none get written. The good news is that your timing is slow enough that you don't need the hardware timing capabilities, so just one task per IO should be sufficient. If you can combine them all that would make your wiring neater, but if you want to write to JUST ONE then it'll have to be separate tasks. (Now, you COULD update your whole IO array and update each main loop cycle, but you said you want to write to one at a time, so that's what I'm sticking with).

Anyway, what you're looking for is called "software timed IO". You'll want to run Create Virtual Channel outside of the loop, feed the task input into the loop, and call DAQmx Write each time you want to change the output (or read the input). Use a shift register, which will send the output of DAQmx Write "back around" so it's read in the next time the loop iterates. When your main program closes, call "DAQmx Close" on the task reference.

Just FYI, your program will be more efficient if you do all of your IO "at once" at the beginning and end of the loop, using arrays. Also, it's not super intuitive, but you can select multiple IO ports in the "select channel" box by shift-clicking each one you want. The input to select the IO pins lets you select any number you like, and you don't have to use another Create Virtual Channel to add each channel to the task.

[santo_13]

---

@nathan_t wrote:

Specific question I asked in a previous reply - "Basically, how can I put multiple digital outputs on a single task and control them each individually using DAQmx Write VIs?"

---

By design, when there are multiple channels in a DAQmx Task, you MUST write data to all channels in the task (no exceptions).

If you want to be able to update only specific channels, you can workaround by creating a wrapper to retain the last updated values of all channels, update only the channel of interest, and write back the update superset of values of all values.

[altenbach]

---

@nathan_t wrote:

(although I would like for one of those to be frequency but Labview doesn't function when I do that, for some unknown reason).

---

Again "not function" is way too vague. (broken run arrow? unexpected result? no result? program locks up? computer on fire? etc. etc.).

Frequency is typically used for analog signals. Are you talking about counts per time-unit?

[nathan_t]

When placed in the main processing loop, nothing else happens. Eventually errors out (time out) due to no signal being read.

[GerdW]

Hi Nathan,

---

@nathan_t wrote:

When placed in the main processing loop, nothing else happens.

---

I guess your code just follows the basic THINK DATAFLOW! mantra of LabVIEW.

This is very basic LabVIEW stuff and you should understand its meaning…

---

@nathan_t wrote:

Eventually errors out (time out) due to no signal being read.

---

Errors either occur - or do not occur. "Eventually" is quite ambigous.

Errors in LabVIEW always come with an error number, you failed even in providing this basic information about your "timeout error"…

[nathan_t]

I literally said the error is a timeout lol. Of the DAQmx Read VI since I guess that wasn't implied.

I understand data flow well enough that my control logic works perfectly fine. Explain why data flow is preventing DAQmx Read from working parallel to the rest of my program in the frequency acquiring case, but not the edge counting case.

[Kevin_Price]

---

When placed in the main processing loop, nothing else happens. Eventually errors out (time out) due to no signal being read.

---

... and now you're seeing one of the reasons I was suggesting 2 separate loops for the 4 counter tasks serving the 2 motors (msgs #4,6).

I'm on the verge of bowing out of this thread.  Many of us have spent more time & effort trying to extract needed info from you than you seem to be spending to provide it.

Do you want awesome help fast?  Spend time writing up a clear list of requirements and your best attempt at a minimal example of your I/O code.   (And please note: a sequence of function calls to the publicly-available DAQmx API does *not* constitute a protected trade secret.)   Save the code for an earlier LV version such as 2019 and post it along with your clear requirements.

There's a bunch of good problem solvers here, but they need to know in greater detail what problem needs to be solved.  You may think you've described everything necessary, but you're wrong.  You haven't.   And that's understandable as a newbie to LabVIEW & DAQmx - you simply don't know what you don't know.  But there's a purpose behind the questions we ask and a reason that we like to see actual code which often helps reveal things that words had missed.

-Kevin P