LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Creating arbitrary pin order on PXIE-6363 DAQ DO

Solved!
Go to solution

Hello,

 

I am using the digital output feature of the PXIE 6363. I understand that I can order the pins of a channel forward or backwards (i.e. specify Dev1/port0/line0:7 or line7:0 in the Line(s) control) but can I create an arbitrary order? I tried to create an arbitrary channel string using the Flatten Channel VI from an array of strings and the output of that VI looks good but when I feed that into the Line(s) input on subsequent VI's my result is not what I expect. In the example below, port0/line0 still acts like the least significant bit (when bursting the pattern) even though the array of strings should place it as bit 7.

 

Am I doing what I want in the correct way?

 

Thank you,

svl123

0 Kudos
Message 1 of 16
(3,641 Views)

svl123,

 

If you attach a string indicator to the output of the DAQmx Flatten Channel String VI, does the output match the order that you would expect? Also, out of curiosity, what is the reason for needing the lines to be in the order you specified, instead of increasing or decreasing order?

Applications Engineering
National Instruments
0 Kudos
Message 2 of 16
(3,573 Views)

@svl123 wrote:

Hello,

 

I am using the digital output feature of the PXIE 6363. I understand that I can order the pins of a channel forward or backwards (i.e. specify Dev1/port0/line0:7 or line7:0 in the Line(s) control) but can I create an arbitrary order? I tried to create an arbitrary channel string using the Flatten Channel VI from an array of strings and the output of that VI looks good but when I feed that into the Line(s) input on subsequent VI's my result is not what I expect. In the example below, port0/line0 still acts like the least significant bit (when bursting the pattern) even though the array of strings should place it as bit 7.

 

Am I doing what I want in the correct way?

 

Thank you,

svl123


arb%20pin%20order%20question

 

Never tried that myself with DO lines and I do not have that hardware to test it but maybe...

 

How about;

 

Wire ONLY the first line spec to an instance of the "Create Channel" and THEN wire the task to a shift register of a For Loop. Inside the For Loop use another "Create Channel" and bring the rest of the line specs in through an indexing tunnel and then passing the Task to the Shift Register.

 

The intent is to first create a task with a single line and then add the other lines to the existing task inside the For Loop.

 

See the help for the "Create Channel" VI if what I posted does not make sense.

 

Ben 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 3 of 16
(3,565 Views)
Solution
Accepted by topic author svl123

This is one of those times I would do th following.

1 drop a task constant

2 create new task to launch the DAQ Wizard

3 select the lines in the order you want them msb to lsb

4 expand the channel list and check the order (move lines up or down as needed)

5 close the wizard 

6 select the task constant and right click...generate configuration.

7 Pat myself on the back

 

The colon operator assumes a descending order anyway you write the boundaries.  Sometimes annoying 

 

Alternatively you can do it Ben's way but that's a nightmare 


"Should be" isn't "Is" -Jay
Message 4 of 16
(3,564 Views)

I *think* the OP's problem may arise from some "special behavior" in the API for DO.

 

When you use the DO 1D U32 1ChanNSamp version of DAQmx Write, the bits in the U32 map *directly* to the physical line #'s of the DO port.  This is what is meant by "port format" when selecting your polymorphic version of the function.  The attempt to change channel order during the config is being ignored.  (Another special behavior is that the # bits in the datatype will need to match the board's physical port size -- 32, 16, or 8 bits).

 

You might get your desired bit-mapping behavior if you use the Multichannel 1D Digital Waveform version of the function.  I'm not in a place I can test and see right now.

 

 

-Kevin P

 

 

P.S.  Conceptually, an alternative workaround that would continue to use the U32 port format would be to define a mapping matrix.  Then you could do a matrix multiply to transform your data into the right format just before sending it to DAQmx Write. 

 

Actual implementation probably isn't gonna look so elegant though, as you operate on 1 bit at a time, extract its value and map it to its desired "port format" position.  Do-able, but be sure to test your algorithm carefully!

 

 

-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 5 of 16
(3,552 Views)

Jeff, I am trying your suggestion and it seems straightforward except I cannot figure out how to "drag and drop" the channel names to make the order that I want. Do I have to right click and "change physical channel" for every channel in the list and then the topmost channel becomes MSB, etc.? I am trying to "drag" the physical entries in the list but cannot do so (see attached screenshot.)

 

Thank you all for your replies,

svl123

0 Kudos
Message 6 of 16
(3,535 Views)

See that ">>" Show Details Button 

Click it! the + X buttons change to Up and Down arrows

Capture1.PNG

And here is the generated CODE (Configuration) after clicking the DO0.0 Line down twice

Capture2.PNG


"Should be" isn't "Is" -Jay
Message 7 of 16
(3,525 Views)

Jeff,

  

To finish this out, how do you then convert the OP's 1D array of U32 data into the right format to write it to the task buffer?  I fiddled around a little trying to illustrate this conversion, but the right sequence of steps wasn't clear to me and I don't have hardware available for trial-and-error testing.  Apparently I'm not particularly knowledgeable about the "digital waveform" datatype -- in practice I've only used the 1D array of unsigned ints in "port format" for timed DO tasks.

 

The task is being constructed according to "one channel for each line" with a special ordering of the lines.  Since the OP wants to do finite hw-timed acquisition, the task needs to be multi-channel multi-sample.  So isn't the only viable DAQmx Write option to write a 1D array of digital waveforms?.  All the other options require "port format", which I *think* won't respect the bit-ordering you carefully set up.

 

But now here's the problem:  the OP's 1D array of U32's converts directly into a *single* digital waveform.  When graphed on a digital waveform graph, it shows all samples of all lines.  In other words, a *single* digital waveform already seems to cover multiple lines and multiple samples.  It also isn't clear to me that the attempt at channel ordering is being respected.  The labels suggest that the graph directly maps from bit # to physical line #, just like the "port format" problem.  I'd expect DAQmx write to do the same direct mapping -- users wouldn't want their graphs to display something different than what the hardware was going to do.

 

Further, since DAQmx Write wants a 1D array of these waveforms, it seems I have to pass this single waveform through "Build Array" to make a 1-element array.   But that seems like a weird step to have to do.

 

Hopefully there's a simple answer I'm missing.  If not, I think the OP is stuck with "port format" and the need to map the U32 bits into different bit positions before calling DAQmx Write.   Thoughts?

 

 

-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 8 of 16
(3,513 Views)

Well Kevin- Lets Try it!

Following Task creation with the wizard and randomly shuffling some lines around I get this

Capture2.PNG

Easy enough to hit save

then Rightclick>> Traverse

Capture1.PNGGrab a sip of coffee and

Config:

Config.png

Looking like Ben suggested we hand type and with Ben's Typing, we are asking for a whole lot of headache  (Sorry Pal, I couldn't resist)

The example

Example.png

and the innards of generating data

Generate.png

Where they create an array of nChannel Digital Waveforms 

in this case, 100 Col x 1 Row gets converted into a waveform of 0 1/Rate and 100 samples of 1 line for each active channel (all Chanels in this task have 1 line as we saw in the config)

 

Nifty

 


"Should be" isn't "Is" -Jay
Message 9 of 16
(3,501 Views)

Agreed, that's a pretty nifty config wizard NI has provided!  

 

However, lacking actual hw to test, it still isn't clear whether the desired mapping is done.  I fiddled around by following your steps and then making a recognizable data pattern as input.  I also sent the 1D array of waveforms to a Dig Wfm graph since I couldn't test actual DO hardware.

 

The pattern showed up on the graph as though the values mapped directly to the physical bit # rather than mapping to other bits based on the channel order.  After running once, I reconfigured the global task to change the order of a couple bits.  After saving the task and rerunning the example, nothing changed on the graph.  It kept acting as though the lowest bit in the original data pattern always mapped to Line 0 on the graph, no matter where line0 was in the DAQmx Task channel order.

 

 

-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 10 of 16
(3,495 Views)