Migration to NIDAQmx python wrapper

[Soungai00]

Plugin updated with NIDAQmx viewer based on NIDAQmx python wrapper.

For this first release with NI, Analog Input are coded and working with cDAQ & NI-USB devices.
Measurements available are current, voltages and temperatures:

• voltages tested & working with cDAQ-9174 and NI-9205 module
• temperatures tested and working with Thermocouples sensors plugged on NI-9211 module (still on cDAQ-9174)

.toml config files are used to get the configuration of the manip and scalable group parameter are created during init_detector to get the configurated analog inputs

[loicguilmard]

@jerlfan @aurore-finco @seb5g
Anyone is reviewing or ? :)
This first release is an asynchronous version using nidaq python library for Acquisition (Viewer).

[aurore-finco]

We can try to have a look at it and test it in the lab in January, sure!

[seb5g]

I added Jérémie and Aurore as reviewers as they might be the one currently using those features

[seb5g]

Browsing the files I could see you actually reimplemented many enums and class I had with previous implementation using pydaqmx. I thought nidaqmx was more pythonic, is there then a need to expose these again and not use nidaqmx functionalities directly?

[loicguilmard]

our main goal was to implement the ni task management for asynchronous call. I don't think we had an enum "strategy". My understanding is that nidaqmx is more a wrapper to get close to the C objects. Most of the enums are about tasks and chanels constants/setup.
I'll look into it. If you pin point the one(s) that you noticed, i'll be right on it.
@aurore-finco that would be nice to test it if you have a 9205 or a 9211. I notified the university of Bourgogne about this release : they use a 9211 module.
Otherwise, Sebastien G. will test a counter in january with @jerlfan.

[seb5g]

well for instance you redefined these:

while they are already enums! if the declaration of the method names, values etc is something you need, you could cretae a small mixin class exposing them:

class EnumMixin():

    @classmethod
    def names(cls):
        return [name for name, member in cls.__members__.items()]

    @classmethod
    def members(cls):
        return [member for name, member in cls.__members__.items()]

    @classmethod
    def values(cls):
        return [cls[name].value for name, member in cls.__members__.items()]

then create simply your enum on steroids with:

class UsageTypeAI(UsageTypeAI, EnumMixin):
    pass

which should do the job (well, test it first ;-) )

[seb5g]

move_abs !!!

[seb5g]

move_rel

[seb5g]

move_home

[seb5g]

by the way enums are actually more conveniently used with:

DAQ_NIDAQ_source.Analog_Input.name
```
like this you're sure to not call things that are not member of the enum (but again here because the enum already exist in the nidaqmx module, one should directly use it. I did all this to transform at the time the not really pythonic pydaqmx library. Execpt that maybe something similar to DAQ_NIDAQ_source is not present in the nidaqmx module?)

[seb5g]

should use the fstring formating which make things more readable

[aurore-finco]

@loicguilmard We have only some 6323 and 6333. We'll have a quick look anyway, but it might indeed not be compatible.

[loicguilmard]

@seb5g
It turns out it's not that easy to mixin an Enum that already has values defined or subclass UsageTypeAI.
I started cleaning the unnecessary redefining enums that already existed but i have a choice between 1:
a. redefining nothing but termination.auto is termination.default which is less explicit for the end user because it's used to build params
b. or using aenum.extend_enum to add auto as an alias
and 2
a using undocumented, private methods ie: Edge.member_names
b or using MethodType(members, Edge)

which ones do you prefer ?

[seb5g]

@seb5g It turns out it's not that easy to mixin an Enum that already has values defined or subclass UsageTypeAI. I started cleaning the unnecessary redefining enums that already existed but i have a choice between 1: a. redefining nothing but termination.auto is termination.default which is less explicit for the end user because it's used to build params b. or using aenum.extend_enum to add auto as an alias
Option b?

and 2 a using undocumented, private methods ie: Edge.member_names b or using MethodType(members, Edge)

Don't know the second one... Do as you think it's the best

Also I saw you imported using star. It's really bad practice.... Please import things you'll use

Thx

[loicguilmard]

I already removed the constants * import :) I won't tell who wrote that :p
I am using init to modify the constants for the all hardware package.

@aurore-finco we are using the NI cdaq-9174 chassis with the modules 9205 and 9211. From what i've experienced changing chassis is pretty transparent just the device name change, but modules have a lot of different task parameters. I'll join our toml as an example to ease the customization.
config_daqmx.toml.txt