LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Possible to branch off task for a specific physical channel?

Solved!
Go to solution

Hey all, 

 

I'm using an event + case structure state machine to simulate various sensors/ actuators/ etc.

 

When the vi is started, I automatically initialize the physical channels on my cDAQ module (daqmx, not daq assistant) using it's own case statement, and then save then bundle the channels/ task separately.

 

Each button on the front panel then cooresponds to a separate case where I write the appropriate data to that particular channel (14 channels total).

I.e. VI starts --> cDAQ module initialized --> user presses 'Open Valve A' --> Event for valve a executes --> Case statement for valve A (only one channel) writes x-volts to that channel --> re-bundle to task which contains all 14 channels --> wait for next event.

 

I'm running into an issue where I am unable to branch my task to reference specific channels. For instance, I am forced to use the task which references ALL 14 of my channels, but I only want channel 0.

 

I've tried using various combinations of arrays, but it doesn't seem to like that very much. My latest approach is:

Create physical channel reference with all 14 channels --> create virtual channel --> bundle that task as 14 separate tasks in a single array. Still getting issues with mismatched data types though.

 

I'm wondering, is this possible? I'd rather not make an individual physical channel/ 'create virtual channel'/ task fourteen times, but I'm thinking this might be the only way.

 

Open HITL Primary - WORKING COPY. The case "Init_ni9264" is where I create my necessary channels. On the following case ('HITL_SVBB_SHT') I want to write a voltage only to channel 0.

 

Thanks for the help!

0 Kudos
Message 1 of 4
(2,902 Views)
Solution
Accepted by topic author PFour

Hi P4,

 

when you define a DAQmx task with 14 channels then you get a DAQmx task reference for that task. There is no way just to read or set just one of those 14 channels in the task, you need to read/write all of the channels.

 

But why is this a problem for you?

Why don't you use some kind of buffer (like a shift register, FGV, AE, globals, whatever) to keep the current value of all channels and provide a way to set/read just one of them?

You seem to have created a state machine with this loop: store the current values for all channels in a shift register. When you want to update just one channel: update that one channel in the array stored in the shift register and output the full array using DAQmxWrite…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 2 of 4
(2,847 Views)
Solution
Accepted by topic author PFour

Gerd's advice is solid, but there's another alternative if this all operates in human-operator time rather than precision-electronics time.

 

It wouldn't *necessarily* be so bad to create 14 separate 1-channel tasks.  Since it sounds like all the outputs are on-demand software-timed signals, they can all be configured *and* started without interfering with one another.   You could do this once before your main loop so they're already all in run mode, thus avoiding the overhead of config-run-clear that concerned you.

 

Note that here are much more serious restrictions when tasks are hardware-timed with buffers -- most devices only allow 1 hw-timed AO task to be running at a time.  (Same for DO on devices that support hw-timed DO at all).   As a matter of fair disclosure, since I habitually do hw-timed tasks where all channels *need* to be in one common task, I would probably tend to approach your app Gerd's way rather than the alternative I described.

 

 

-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).
Message 3 of 4
(2,834 Views)

Gerd: Thanks for the input. Yep, maintaining previous values and updating only the channel-of-interest is the solution I ended up going with. Good to know that it is not possible to split up tasks! Thanks!

 

Kevin: Also a great solution, however I was trying to avoid creating config sequences/ case statements for 14 channels... because that is nightmare fuel. Thanks for the input! 

0 Kudos
Message 4 of 4
(2,824 Views)