How to find the index of a changed array control

[cbutcher]

In the "Digital_Out: Value Change" event, you don't actually need a case structure - you can use a select node instead and just have the two strings (or use the Append True/False String node under Additional String Functions and wire "DO_", "ON", "OFF"). There's a bit more but I don't have the OpenG toolkits installed and I'm not sure how a Variant Into String is needed here for what looks like an index to string - probably you could consider the Format to String with %d or something (but maybe there's something I'm missing there).

I'm then missing both the GOOP toolkit (although I think I can guess the queue handling stuff) and the DO_ON.vi, but I guess it's similar to the Digital_On case in the DAQEngineV4.2.vi?

If so, you can do what you're doing there and pass the index to change, but you'd then need an array of tasks, or a copy of all the data (duplicate data when not needed usually bad - just send the full array in that case). If you have the array of tasks, it should be fine.

[cbutcher]

---

@Gaffinator wrote:

I believe i should have all my analog inputs as a Task. And i had though to do the same for my DO

(Right now in my project my AO AI DO DI are all tasks)

---

One DAQmx task per "task" - AO, AI, DO, DI etc seems perfectly reasonable. If a task contains multiple channels, you can't write to only part of the set of channels, so then you'd want to pass the set of new values (an array with an element per channel). This also simplifies the handling, because you'd then be able to combine the On and Off cases (since the 'off' case would just have a false boolean as the new value).

Hopefully someone else can give more GOOP specific advice - I use LVOOP every day but have never looked at the GOOP toolkit.

[Gaffinator]

There isn't a particular reason I'm using variant to string. Someone had told me that's what they just use by default. So i thought to do the same.

You are right that I am pretty much doing the same thing in the MainV1.2.trash. But I don't want to turn all of channels on if one of the switches is flipped. I would like to turn on a singular channel

[Gaffinator]

So to clearify ( More so to make sure I understand)

I originally was going to pass the index of the changed control so that i could identify the proper channel to "Turn on/off". That isn't the best way to go about it.

I already have a task for my DO, So instead of just passing the index of the control I should pass the array of values.

But the problem I see is that I want to only turn on a singular channel of the particular task. How would I go about doing that?

Also thank both of you guys for humoring my questions

[Gaffinator]

For instance if i pass the array [TTFT]

it would turn on 0,1,3

but if i then turned on 2 [TTTT]

because of how im comparing the old and new array by != this would also turn off 0,1,3 and turn on 2

[altenbach]

---

@Gaffinator wrote:

For instance if i pass the array [TTFT]

it would turn on 0,1,3

but if i then turned on 2 [TTTT]

because of how im comparing the old and new array by != this would also turn off 0,1,3 and turn on 2

---

The inequality comparison is only used to detect what changed, not what should be ON. You probably don't even need it and just send the new array to the device whenever one of the values changes.

[Gaffinator]

You are so right. Thank you so much!!

[Kevin_Price]

I'm gonna express a minority view here.  While 1 task for multiple DO "channels" (a.k.a. "lines" or "bits") is viable, and it's even *necessary* for buffered hardware-clocked tasks, I'm not so sure it's the right choice for what it sounds like you're doing.  (Sorry, can't look at code so I'm kinda guessing.)

If you stick with on-demand software-timed tasks, you can have many distinct DO tasks, 1 for each individual channel.   Similar for DI.  This is the way I would personally prefer approaching things.

Right now you seem to have a structure that reads in lots of DI lines that are grouped together in 1 task.   So you have to search to see which line changed.  Then you want to set 1 specific bit out of many in your DO task.   So you'll need to keep track of the last state you output so you can maintain state on most bits while toggling 1 of interest. 

Yuck.  (I exaggerate.  It's not so bad *really*, but it seems like a lot of wasted bit-fiddling.)   I would have a generic function that monitors 1 DI line (in its own dedicated task) and reacts to changes by setting 1 DO line (also in its own dedicated task).  Since the DO task only has 1 DO line in it, you can't accidentally affect any of the other DO lines.

There's still a need to associate which DI and DO go together, but you end up doing it just once when configuring things rather than redoing it over and over every read/write iteration.

-Kevin P