ni / nimi-python

Python bindings for NI Modular Instrument drivers.

Overall Status

master branch status
GitHub status

Info	Python bindings for NI Modular Instrument drivers. See GitHub for the latest source.
Author	NI

About

The nimi-python repository generates Python bindings (Application Programming Interface) for interacting with the Modular Instrument drivers. The following drivers are supported:

• NI-DCPower (Python module: nidcpower)
• NI-Digital Pattern Driver (Python module: nidigital)
• NI-DMM (Python module: nidmm)
• NI-FGEN (Python module: nifgen)
• NI-ModInst (Python module: nimodinst)
• NI-SCOPE (Python module: niscope)
• NI Switch Executive (Python module: nise)
• NI-SWITCH (Python module: niswitch)
• NI-TClk (Python module: nitclk)

It is implemented as a set of Mako templates and per-driver metafiles that produce a Python module for each driver. The driver is called through its public C API using the ctypes Python library.

nimi-python supports all the Operating Systems supported by the underlying driver.

nimi-python follows Python Software Foundation support policy for different versions.

NI-DCPower Python API Status

NI-DCPower (nidcpower)
Driver Version Tested Against	2024 Q2
PyPI Version
Supported Python Version
Documentation
Open Issues
Open Pull Requests

NI-Digital Pattern Driver Python API Status

NI-Digital Pattern Driver (nidigital)
Driver Version Tested Against	2024 Q2
PyPI Version
Supported Python Version
Documentation
Open Issues
Open Pull Requests

NI-DMM Python API Status

NI-DMM (nidmm)
Driver Version Tested Against	2023 Q4
PyPI Version
Supported Python Version
Documentation
Open Issues
Open Pull Requests

NI-FGEN Python API Status

NI-FGEN (nifgen)
Driver Version Tested Against	2023 Q4
PyPI Version
Supported Python Version
Documentation
Open Issues
Open Pull Requests

NI-ModInst Python API Status

NI-ModInst (nimodinst)
Driver Version Tested Against	2024 Q2
PyPI Version
Supported Python Version
Documentation
Open Issues
Open Pull Requests

NI-SCOPE Python API Status

NI-SCOPE (niscope)
Driver Version Tested Against	2023 Q4
PyPI Version
Supported Python Version
Documentation
Open Issues
Open Pull Requests

NI Switch Executive Python API Status

NI Switch Executive (nise)
Driver Version Tested Against	2023 Q1
PyPI Version
Supported Python Version
Documentation
Open Issues
Open Pull Requests

NI-SWITCH Python API Status

NI-SWITCH (niswitch)
Driver Version Tested Against	2023 Q4
PyPI Version
Supported Python Version
Documentation
Open Issues
Open Pull Requests

NI-TClk Python API Status

NI-TClk (nitclk)
Driver Version Tested Against	2024 Q2
PyPI Version
Supported Python Version
Documentation
Open Issues
Open Pull Requests

Installation

Driver specific installation instructions can be found on Read the Docs:

• nidcpower
• nidigital
• nidmm
• nifgen
• nimodinst
• niscope
• nise
• niswitch
• nitclk

Contributing

We welcome contributions! You can clone the project repository, build it, and install it by following these instructions.

Usage

The following is a basic example of using the nidmm module to open a session to a DMM and perform a 5.5 digits of resolution voltage measurement in the 10 V range.

import nidmm
with nidmm.Session("Dev1") as session:
    session.configure_measurement_digits(nidmm.Function.DC_VOLTS, 10.0, 5.5)
    print("Measurement: " + str(session.read()))

Other usage examples can be found on GitHub.

Support / Feedback

For support specific to the Python API, follow the processs in Bugs / Feature Requests. For support with hardware, the driver runtime or any other questions not specific to the Python API, please visit NI Community Forums.

Bugs / Feature Requests

To report a bug or submit a feature request specific to Python API, please use the GitHub issues page.

Fill in the issue template as completely as possible and we will respond as soon as we can.

Documentation

Documentation is available on Read the Docs:

• https://nidcpower.readthedocs.io/en/stable
• https://nidigital.readthedocs.io/en/stable
• https://nidmm.readthedocs.io/en/stable
• https://nifgen.readthedocs.io/en/stable
• https://nimodinst.readthedocs.io/en/stable
• https://niscope.readthedocs.io/en/stable
• https://nise.readthedocs.io/en/stable
• https://niswitch.readthedocs.io/en/stable
• https://nitclk.readthedocs.io/en/stable

License

nimi-python is licensed under an MIT-style license (see LICENSE). Other incorporated projects may be licensed under different licenses. All licenses allow for non-commercial and commercial use.

gRPC Features

For driver APIs that support it, passing a GrpcSessionOptions instance as a parameter to Session.__init__() is subject to the NI General Purpose EULA (see NILICENSE).

nimi-python's Issues

command_history.bat/.sh contains system path information

We generate command_history scripts for client convenience in order to "replay" the build. Every time I build, the files change if the last machine where they were created is different. Large part of the changes stem from the fact that full paths are used in the scripts:

For example this:

python3 -m build --template  /mnt/d/GitHub/nimi-python/build/templates/enums.py.mako --dest-dir  /mnt/d/GitHub/nimi-python/bin/nidmm/nidmm/ --metadata  /mnt/d/GitHub/nimi-python/src/nidmm/metadata 

Becomes

python3 -m build --template  /Users/kirsch/Developer/nimi-python/build/templates/enums.py.mako --dest-dir  /Users/kirsch/Developer/nimi-python/bin/nidmm/nidmm/ --metadata  /Users/kirsch/Developer/nimi-python/src/nidmm/metadata 

I think we should change the generation so that the script only includes relative paths from the mimi-python directory. Clients can invoke:

./generated/command_history.sh

APIs should deal in unicode and not str

This came up in a conversation the other day that the API is not ensuring unicode strings are being used, even if the API only supports ASCII.

nixnet is in the same boat and used unicode everywhere, see https://github.com/ni/nixnet-python/blob/master/nixnet/_funcs.py#L738

Add code coverage check to NI-FAKE unit tests

We need to add code coverage check to NI-FAKE unit tests that fail the build if we don't fully exercise the generated Python bindings.

build.py does not work on Linux

Command:

python3 build.py clean make --metadata ./src/nidmm/metadata/

Response:

Traceback (most recent call last):
File "build.py", line 217, in
main()
File "build.py", line 211, in main
metadata = load_build(m)
File "build.py", line 121, in load_build
metadata = path_import(m)
File "build.py", line 66, in path_import
module = importlib.import_module(os.path.basename(absolute_path))
File "/usr/lib64/python3.4/importlib/init.py", line 109, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 2249, in _gcd_import
File "", line 2201, in _sanity_check
ValueError: Empty module name

Generated code is not available in repo for browsing

A client that wants to look at the generated code, but doesn't want to install nor clone and build, has no way to do it today.

@epage suggests putting the generated code in the repo for this purpose.

Update Todos in readme

The readme does not show correct information on python compiler and operating system support. There is also missing information marked with "TODO". We need to keep this updated as it affects documentation on read the docs http://nimi-python.readthedocs.io/en/docs-build_docs/index.html .

DMM Python does not work on linux

• Bad so name (should be "libnidmm.so")
• There is no 32-bit support on linux
• Error reporting when dll not found could be improved

Python code in the build module should have better unit test coverage.

ex: helper.py is not unit tested

We can probably break this up file into smaller modules, and really need a few unit tests.

Codebase using is / is not for string comparison

We should use == and !=.
'is' tests for object identity, which happens to work for small strings due to implementation details of the Python runtime. But we cannot rely on it.

Cannot build on windows machines

The current build tools use build.sh. This works great on Linux, but you cannot build it on windows. If a customer wants to update code and test it locally.

We should create something like build.py that enables a user to build it in python. Build.sh (used by TravisCI) can then call build.py so they share common code.

Methods suppose to return enum is returning Int

read_status method suppose to return acquisition status as enum type . Instead it is returning Int.

with nidmm.Session(args.name) as session:
     print(session.read_status())
     print(type(session.read_status()[0]))
     print(type(session.read_status()[1]))
 
>>> 
(0, 4)
<class 'int'>
<class 'int'>

Update systemTest to accept device name at runtime

As of now SystemTest will be running on first device found by niModInst. There should be an easier way to specify the device name while running system tests.

(Suspected) Spurious exceptions with multi-threaded calls

DAQmx at least ran into this where two threads tried to assign argtypes at the same time and got strange exceptions.

See ni/nidaqmx-python@82f7ee5

DAQmx previously re-assign argtypes on every call. nimi-python does this once. This leaves the race to be between the check and the assignment.

    def niDMM_close(self, vi):  # noqa: N802
        if self.niDMM_close_cfunc is None:
            self.niDMM_close_cfunc = self._library.niDMM_close

1. Thread A performs if-check
2. Thread B performs if-check
3. Thread A assigns
4. Thread B assigns

https://github.com/ni/nimi-python/blob/master/generated/nidmm/ctypes_library.py#L101

Functions returning wrong type

get_self_cal_supported function is supposed to return value of type Boolean instead it returns Integer.

with nidmm.Session(args.name) as session:
        print( session.get_self_cal_supported() )

>> 1

Enable pep8 validation

Right now pep8 validation is being skipped by tox

Error handling does not work with ViStatus_ctype

Exception about wrong type when error happens

Bad names for generated attribute methods

This is the name of the generated methods in Session for attribute access:

_get_attribute_vi_int32
_get_attribute_vi_real64
_get_attribute_vi_string
_get_attribute_vi_boolean
...

The IVI types are ViInt32, ViReal64, and so forth. One could argue that the generated methods should be in the form:

_get_attribute_ViInt32
_get_attribute_ViBoolean
....

One could also argue that the names as-is are correct, or that because these are private and should not be called by clients of Session it's not worth the added complexity to generate in a different form... in which case please chime in.

NI-DMM System Tests Fail for Simulated Modules

"test_take_simple_measurement_works": assumes that nothing is connected (0 Volts). This causes failures on simulated devices which returns simulated data.
"test_warning": assert false fails.
"test_ViBoolean_attribute": assumes device is not simulated
"test_ViString_attribute": assumes device has a serial number

Support default parameter values in generated APIs

We want some of the generated methods to have default values.
We need to add support for this to our code generator through functions_addons.py.

Examples:

ViStatus _VI_FUNC niDMM_InitWithOptions(ViRsrc resourceName, ViBoolean IDQuery, ViBoolean resetDevice, ViString optionsString, ViSession *newVi);
IDQuery, resetDevice could have defaults. Maybe a bad example because we are going to handcode constructors anyway.

ViStatus _VI_FUNC niDMM_GetDevTemp(
   ViSession   vi,
   ViString    reserved,
   ViReal64    *temperature);

Reserved should be omitted or at least defaulted to something for the Python user.

There may be other examples.

NI-ModInst does not have any System Tests

build.bat / sh calls "python" which is python2 by default in linux

Enum error reporting does not include namespace

"
TypeError: Value mode must be of type <enum 'EnabledSetting'>
"

When I update the type to "EnabledSetting.ON" it says

"
NameError: name 'EnabledSetting' is not defined
"

If possible, it should have reported
"
TypeError: Value mode must be of type <enum 'nidmm.EnabledSetting'>
"

Unable to Configure Trigger for nidmm

Configure_trigger throws error " AttributeError: module 'nidmm' has no attribute 'Terminal' ". As per sessions.py configure_trigger should have input of Terminal Type.

Run following code :
with nidmm.Session(device_info['name']) as session: session.configure_trigger(nidmm.Terminal.IMMEDIATE, 1)

test_system_nidmm.py's test_acquisition is broken

src\nidmm\system_tests\test_system_nidmm.py:108: NameError
______________________________ test_acquisition _______________________________

device_info = {'name': '4070', 'sn': '00D82BA5'}

    def test_acquisition(device_info):
        with nidmm.Session(device_info['name']) as session:
            session.configure_measurement_digits(nidmm.Function.DC_CURRENT, 1, 5.5)
>           with session.acquisition:
E           AttributeError: 'Session' object has no attribute 'acquisition'

src\nidmm\system_tests\test_system_nidmm.py:122: AttributeError
===================== 4 failed, 7 passed in 4.92 seconds ======================

Some public enum values start with _

NI-DMM has a few enum values that start with a number: i.e. NIDMM_ATTR_ID_2_WIRE_RESISTANCE
Currently in Python this is nidmm.Function._2_WIRE_RESISTANCE
But leading _ is reserved for private which is not the case here. We should look for alternatives.

Other MI drivers have similar problems:

NIFGEN_ATTR_5450_OSCILLATOR_PHASE_DAC_VALUE
NISCOPE_ATTR_5102_ADJUST_PRETRIGGER_SAMPLES
NISCOPE_ATTR_5V_OUT_OUTPUT_TERMINAL
NISCOPE_ATTR_5102_ADJUST_PRETRIGGER_SAMPLES
...

DAQmx API spells out the numbers. This would work for NIDMM_ATTR_ID_2_WIRE_RESISTANCE but be really awkward for things such as NIFGEN_ATTR_5450_OSCILLATOR_PHASE_DAC_VALUE.

Wrong calling convention on windows when using 32-bit Python 3.5.1

Cannot find dll on windows when using 32-bit Python 3.5.1

command_history.sh is not executable as built

After building:

Kirsch0:nimi-python kirsch$ ./generated/command_history.sh

-bash: ./generated/command_history.sh: Permission denied

I suppose we could add a build step to chmod. But we're putting the files under source control so when someone without make pulls the script, it won't be executable right away (or does Git pull permissions?)

I suppose the likelihood of needing the script is pretty low for a Unix user since they tend to have GNU Make in the system.

pytest errors: ModuleNotFoundError: No module named 'nimodinst.ctypes_types'

Z:\>pytest
============================= test session starts =============================
platform win32 -- Python 3.6.1, pytest-3.0.7, py-1.4.33, pluggy-0.4.0
rootdir: Z:\, inifile:
collected 12 items / 2 errors

=================================== ERRORS ====================================
________ ERROR collecting bin/nimodinst/nimodinst/tests/test_simple.py ________
ImportError while importing test module 'Z:\bin\nimodinst\nimodinst\tests\test_simple.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
bin\nimodinst\nimodinst\tests\test_simple.py:2: in <module>
    import nimodinst
E   ModuleNotFoundError: No module named 'nimodinst'
_____________ ERROR collecting src/nimodinst/tests/test_simple.py _____________
ImportError while importing test module 'Z:\src\nimodinst\tests\test_simple.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
src\nimodinst\tests\test_simple.py:3: in <module>
    import nimodinst.ctypes_types
E   ModuleNotFoundError: No module named 'nimodinst.ctypes_types'
!!!!!!!!!!!!!!!!!!! Interrupted: 2 errors during collection !!!!!!!!!!!!!!!!!!!
=========================== 2 error in 0.70 seconds ===========================

System tests broken

Z:\>pytest
============================= test session starts =============================
platform win32 -- Python 3.6.1, pytest-3.0.7, py-1.4.33, pluggy-0.4.0
rootdir: Z:\, inifile:
collected 12 items

bin\nidmm\nidmm\tests\test_simple.py .
src\nidmm\system_tests\test_system_nidmm.py .....F....
src\nidmm\tests\test_simple.py .

================================== FAILURES ===================================
___________________________ test_ViString_attribute ___________________________

    def test_ViString_attribute():
        with nidmm.Session("Dev1") as session:
>           assert "1A67CAC" == session.serial_number

src\nidmm\system_tests\test_system_nidmm.py:57:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
bin\nidmm\nidmm\session.py:46: in __get__
    return obj._get_attribute_vi_string(self.channel, self.attribute_id)
bin\nidmm\nidmm\session.py:648: in _get_attribute_vi_string
    if(errors._is_error(error_code)): raise errors.Error(self.library, self.vi, error_code)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

error_code = <ViStatus_ctype object at 0x000001B203793E48>

    def _is_error(error_code):
>       return (error_code < 0)
E       TypeError: '<' not supported between instances of 'ViStatus_ctype' and 'int'

bin\nidmm\nidmm\errors.py:15: TypeError
===================== 1 failed, 11 passed in 1.00 seconds =====================

Z:\>

build.py errors when building in python27

C:\Users\Administrator\Desktop\Git\nimi-python>python27 build.py clean make --metadata .\src\nidmm\m
etadata
Traceback (most recent call last):
File "build.py", line 217, in
main()
File "build.py", line 199, in main
codegen = path_import(codegen_path)
File "build.py", line 66, in path_import
module = importlib.import_module(os.path.basename(absolute_path))
File "C:\Users\Administrator\AppData\Local\Programs\Python\Python27\lib\importlib_init_.py", li
ne 37, in import_module
import(name)
File "C:\Users\Administrator\Desktop\Git\nimi-python\src\codegen_init_.py", line 2, in

from src.codegen.generateTemplate import configure_logging

ImportError: No module named src.codegen.generateTemplate

Example does not build on Python27 due to invalid syntax

File ".\src\nidmm\examples\nidmm_measurement.py", line 23
print(e, file=sys.stderr)
^
SyntaxError: invalid syntax

Cannot use 4021 through nidmm module

Function is not part of Session because it doesn't belong there (does not require an open NI-DMM session in order to use it).

Workaround: client can use ctypes private library object used by Session.

Unable to find enum EnabledSetting

configure_offset_comp_ohms() , configure_adc_calibration(), configure_auto_zero_mode() methods use enum EnabledSetting. There is no enum EnabledSetting defined in enum.py

CableCompensationType , ADCCalibration, AutoZero are defined in enum. But unable to use them since function.py is throws error when not matching enumtype EnabledSetting.

def configure_auto_zero_mode(self, auto_zero_mode):
        if type(auto_zero_mode) is not enums.EnabledSetting:
            raise TypeError('Parameter mode must be of type ' + str(enums.EnabledSetting))
        error_code = self.library.niDMM_ConfigureAutoZeroMode(self.vi, auto_zero_mode.value)
        errors._handle_error(self, error_code)
        return

Disallow inserting attributes into an instance of Session

Say you have this code:

def test_take_simple_measurement_works(device_info):
    with nidmm.Session(device_info['name']) as session:
        session.rannge = 50 # Coerces up!
        value = session.read(1000) != 0 # Assumes DMM reading is not exactly zero to support non-

Interestingly, this appears to work, but notice the typo when setting the range property! The range property was never set on the session and no error occurred.

Given that:

• Our Python bindings are abstractions on top of pre-established APIs
• We'll release as 0.1 and there's a chance that attribute names will get tweaked (as happened in #95)

I propose that we disallow inserting any attributes into an instance of Session. How to do that is TBD.

get_library() creates a new object on every call

Every time you open a session to the API, get_library is called. This returns a new object.
It should be smarter and return a delay-created singleton, for efficiency.

VI_NULL should be used as the first parameter to GetErrorMessage

See lines 232-235 of session.py

The first parameter to each call of GetErrorMessage should be VI_NULL (or the Python equivalent).
If the session handle is invalid, GetErrorMessage will return a fatal status, which would then be used as the buffer size.

When building, it errors if bin folder does not exist

"
C:\Users\Administrator\Desktop\nimi-python-master>python35 ./build.py
codegen_path = C:\Users\Administrator\Desktop\nimi-python-master\src\codegen
Traceback (most recent call last):
File "./build.py", line 103, in
main()
File "./build.py", line 72, in main
shutil.rmtree(OUTPUT_DIR)
File "C:\Users\Administrator\AppData\Local\Programs\Python\Python35-32\lib\shu
til.py", line 488, in rmtree
return _rmtree_unsafe(path, onerror)
File "C:\Users\Administrator\AppData\Local\Programs\Python\Python35-32\lib\shu
til.py", line 370, in _rmtree_unsafe
onerror(os.listdir, path, sys.exc_info())
File "C:\Users\Administrator\AppData\Local\Programs\Python\Python35-32\lib\shu
til.py", line 368, in _rmtree_unsafe
names = os.listdir(path)
FileNotFoundError: [WinError 3] The system cannot find the path specified: 'C:\
Users\Administrator\Desktop\nimi-python-master\bin'

C:\Users\Administrator\Desktop\nimi-python-master>mkdir bin

C:\Users\Administrator\Desktop\nimi-python-master>python35 ./build.py
codegen_path = C:\Users\Administrator\Desktop\nimi-python-master\src\codegen
"

make produces warnings

After running make in master:

Kirsch0:nimi-python kirsch$ make
Creating enums.py
Creating library.py
Creating session.py
Creating errors.py
Creating ctypes_library.py
Creating mock_helper.py
Creating __init__.py
Creating ctypes_types.py
Creating python_types.py
Creating session.rst
Creating enums.rst
Creating test_session.py
Creating setup.py
Creating README.rst
Running unit tests
Creating Wheel distribution
zip_safe flag not set; analyzing archive contents...
Creating Source distribution
warning: check: missing required meta-data: url

warning: check: missing meta-data: if 'author' supplied, 'author_email' must be supplied too

Updating generated files
Creating library.py
Creating session.py
Creating errors.py
Creating ctypes_library.py
Creating mock_helper.py
Creating __init__.py
Creating ctypes_types.py
Creating python_types.py
Creating session.rst
Creating test_modinst.py
Creating setup.py
Creating README.rst
Running unit tests
Creating Wheel distribution
zip_safe flag not set; analyzing archive contents...
Creating Source distribution
warning: check: missing required meta-data: url

warning: check: missing meta-data: if 'author' supplied, 'author_email' must be supplied too

Updating generated files

We should be able to make the following lines disappear and reduce noise from build output:

• zip_safe flag not set; analyzing archive contents...
• warning: check: missing required meta-data: url
• warning: check: missing meta-data: if 'author' supplied, 'author_email' must be supplied too
• zip_safe flag not set; analyzing archive contents...
• warning: check: missing required meta-data: url
• warning: check: missing meta-data: if 'author' supplied, 'author_email' must be supplied too

Pytest only passes if device is named "PXI1Slot2"

Unit tests aren't re-run if they fail in next make

Say you run

make

...and the unit tests fail.

Then next time you run

make

the unit tests won't be re-run and the build will complete successfully.

This is probably because the make rule uses file test_results.log alone as a target in order to determine if it needs to execute.

Build output gives no indication of which driver it's working on

It'd be nice to have clear visual indication of which driver (i.e. NI-DMM or niModInst) is currently being built.

Example build output from master:

Kirsch0:nimi-python kirsch$ make
Creating enums.py
Creating library.py
Creating session.py
Creating errors.py
Creating ctypes_library.py
Creating mock_helper.py
Creating __init__.py
Creating ctypes_types.py
Creating python_types.py
Creating session.rst
Creating enums.rst
Creating test_session.py
Creating setup.py
Creating README.rst
Running unit tests
Creating Wheel distribution
zip_safe flag not set; analyzing archive contents...
Creating Source distribution
warning: check: missing required meta-data: url

warning: check: missing meta-data: if 'author' supplied, 'author_email' must be supplied too

Updating generated files
Creating library.py
Creating session.py
Creating errors.py
Creating ctypes_library.py
Creating mock_helper.py
Creating __init__.py
Creating ctypes_types.py
Creating python_types.py
Creating session.rst
Creating test_modinst.py
Creating setup.py
Creating README.rst
Running unit tests
Creating Wheel distribution
zip_safe flag not set; analyzing archive contents...
Creating Source distribution
warning: check: missing required meta-data: url

warning: check: missing meta-data: if 'author' supplied, 'author_email' must be supplied too

Updating generated files

Provide way to lock a session

Drivers have LockSession and UnlockSession functions. It allows clients to do multiple calls to the session that are guaranteed to be serialized.

We aren't exposing that in the Python APIs. Perhaps we should. Something like:

with nidmm.Session('dev1') as session:
spawn_thread_that_uses(session)
with session.lock()
# Guaranteed that no other thread can call session in between do_stuff() and do_more_stuff()
session.do_stuff()
session.do_more_stuff()

Of course clients have workarounds for this and can do their own synchronization in Python at a higher layer, so I am not sure we should add this functionality.

Have system tests pick any available device rather than hardcode its name

Use NI-ModInst for this. That way developer doesn't have to make sure that the device has the name that the test expects it to have.

@texasaggie97 and I keep going back and forth on the name (he's testing on a USB-4065).

Update Readme to display last version of the driver that Python was tested against.

build.py not exporting in correct path

example is expecting:

sys.path.append(os.path.join(sys.path[0],'../../../bin'))

However now when we build the actual files are in bin/nidmm/nidmm.

It seems that we created the file with an extra level of nidmm.

test_system_nidmm.py test_ViSession_attribute fails

Test expects session.io_session = 5 to raise TypeError.
This test used to work, although someone could argue that we should allow setting a numeric value on a ViSession.

__________________________ test_ViSession_attribute ___________________________

device_info = {'name': '4070', 'sn': '00D82BA5'}

    def test_ViSession_attribute(device_info):
        with nidmm.Session(device_info['name']) as session:
            try:
                session.io_session = 5
>               assert False
E               assert False

src\nidmm\system_tests\test_system_nidmm.py:108: AssertionError

Unit tests run every time you make, even if nothing changed

Introduced by #133 which fixes #124 (this new issue is less severe).
We need a bit more smarts in our makefiles so that we don't re-run unit tests if nothing changed and last unit test run passed.

System test test_ViString_attribute fails

================================== FAILURES ===================================
___________________________ test_ViString_attribute ___________________________

    def test_ViString_attribute():
        with nidmm.Session("PXI1Slot2") as session:
>           assert "1A67CAC" == session.serial_number

src\nidmm\system_tests\test_system_nidmm.py:51:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
bin\nidmm\nidmm\session.py:45: in __get__
    return obj._get_attribute_vi_string(self.channel, self.attribute_id)
bin\nidmm\nidmm\session.py:699: in _get_attribute_vi_string
    error_code = self.library.niDMM_GetAttributeViString(self.vi, channel_name.encode('ascii'), attribute_id, buffer_size, ctypes.pointer(value_ctype))
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = <nidmm.ctypes_library.nidmm_ctypes_library object at 0x0000019D80D8B3C8>
vi = 11, channel_name = b'', attribute_id = 1150054, buf_size = 0
value = <nidmm.session.LP_ViString_ctype object at 0x0000019D80D5FAC8>

    def niDMM_GetAttributeViString(self, vi, channel_name, attribute_id, buf_size, value):
        if self.niDMM_GetAttributeViString_cfunc is None:
            self.niDMM_GetAttributeViString_cfunc = self._library.niDMM_GetAttributeViString
            self.niDMM_GetAttributeViString_cfunc.argtypes = [ViSession_ctype, ViConstString_ctype, ViAttr_ctype, ViInt32_ctype, ViString_ctype]
            self.niDMM_GetAttributeViString_cfunc.restype = nidmm.python_types.ViStatus
>       return self.niDMM_GetAttributeViString_cfunc(vi, channel_name, attribute_id, buf_size, value)
E       ctypes.ArgumentError: argument 5: <class 'TypeError'>: wrong type

bin\nidmm\nidmm\ctypes_library.py:493: ArgumentError
===================== 1 failed, 9 passed in 1.15 seconds ======================

Need init with options

• Need init with options to simulate a device

Build.py give bad magic number error

C:\Users\Administrator\Desktop\Git\nimi-python>python build.py clean make --metadata .\src\nidmm\met
adata
Traceback (most recent call last):
File "build.py", line 217, in
main()
File "build.py", line 199, in main
codegen = path_import(codegen_path)
File "build.py", line 66, in path_import
module = importlib.import_module(os.path.basename(absolute_path))
File "C:\Users\Administrator\AppData\Local\Programs\Python\Python36\lib\importlib_init_.py", li
ne 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 978, in _gcd_import
File "", line 961, in _find_and_load
File "", line 950, in _find_and_load_unlocked
File "", line 655, in _load_unlocked
File "", line 674, in exec_module
File "", line 888, in get_code
File "", line 455, in _validate_bytecode_header
ImportError: bad magic number in 'codegen': b'\x03\xf3\r\n'