implement DAQmxWriteDigitalU32

[hvraven]

called the function write_32, beacuse I couldn't think of a better name.

it is mostly a copy of the write function. If you have some better ideas on how to implement them (there are also U8 and U16) I'm happy to make changes

[hoechenberger]

Hi @lorem-ipsum, thanks for the contribution! I would suggest the following backward-compatible API change to DigitalOutputTask.write():

Current API:

def write(self, data, 
          auto_start=True, timeout=10.0, 
          layout='group_by_channel'):

Proposed API:

def write(self, data, 
          auto_start=True, timeout=10.0, 
          layout='group_by_channel',
          write_type='channel',
          dtype=np.uint8):

with

write_type : {'channel', 'port'}

    `channel`: write to each digital line in the task.
    `port`: write to the entire port.

dtype : {np.uint8, np.uint16, np.uint32}

    In case of `write_type='channel'`, `dtype` will always be set to `np.unit8`.

Notes
-----

In case of `write_type='channel'`, `DAQmxWriteDigitalLines()` will be called.
In case of `write_type='port'`, `DAQmxWriteDigitalUx()` will be called, with `x`
depending on the specified `dtype` (8, 16, 32).

We could then

• merge your suggestion into the existing DigitalOutputTask.write() method, and
• easily add support for DAQmxWriteDigitalU8() and DAQmxWriteDigitalU16 as well.

Does that make sense? Did I overlook something? :)

CC @pearu

[hvraven]

Hi @hoechenberger.

It took me a while to come back to this, but yes, this appears to be a better interface. I am currenlty lacking hardware to test the changes, but should get some within the next month(s). I will adjust it and test it once I have it.

[hoechenberger]

Thanks, this would be great!

[hvraven]

Came around working on the code again, but please don't merge as is. It is completely untested and I want to clean up the history. I just have a question regarding the API. I dropped the explicit dtype parameter, instead I pull it out of the data.dtype. This removes the need to specify an already specified parameter. It forces users to get data into the correct data type, but I think this should always be the case for the port variant. No changes for the channel variant as the dtype is just set to np.uint8.

Is that fine with you, or do you have any comments?