From what I can tell, there is one master DaqException that is used for everything that goes wrong. This makes checking for certain exceptions extremely difficult, as you are now limited to checking the error message for certain strings. This is fragile.
Please provide typed exceptions in the .NET DAQmx library. For example, if a task times out, it should throw a "TaskTimeoutException", which might be a child of DaqException. Or if the timing setup is invalid, the library would throw a "InvalidTimingConfigurationException".
Yes, I realize it's a bit of busy work to create a bunch of typed exceptions, but it makes error handling for consumers much easier.
Currently with a multislot chassis, the system will operate at the requested sampling rate even if that rate is above the maximum supported by the module. In this case, the chassis will replicate the additional required data points from the previous sample, and will not return an error in NI MAX. With a single slot chassis, this is not an option. However, it would be helpful if this feature was also supported with the single slot chassis so that data could be replicated at a higher sample rate without returning an error message.
Hello. I'm working on an app to interface with a couple of ANT devices (Garmin Vector, Garmin heartrate monitor). I've seen a couple of posts on this topic but nobody has posted code. I talked to Frank Lezu at an NI day in DC a month or so back and he recommended I post about it here.
Anyone else looking for ANT/ANT+ support? I'd be happy to share my code when it's not in a ridiculously embarrassing state but for now see this post for a braindump of my progress.
It is not possible to build Kernelmodule nirlpk 2.0 on Kernel >= 3.10
nimhddk_linuxkernel/LinuxKernel/nirlpk/objects/nirlpk.c:1076:5: error: implicit declaration of function ‘create_proc_read_entry’ [-Werror=implicit-function-declaration] if (create_proc_read_entry(nNIRLP_kDriverAlias, 0, nNIRLP_procDir, nNIRLP_procRead, NULL)) ^
create_proc_read_entry appears to have been deprecated in kernel 3.10.
It would be nice to have the ability to spawn a “Child” Task based upon a “Parent” Task local virtual channels. Today, this can be accomplished with global virtual channels, but not easily with local virtual channels within the Task. Today, we dynamically generate Tasks based upon the physical channels and save it to an external file. There are many variations of this, but all require a decent amount of programming for complete automation. The external calibration interface in MAX has greatly improved over the years and now it is easy to calibrate multiple sensors at the same time. Not only that, but it is nice to have device setup and calibration information in one location.
Currently we are using LabWindows/CVI with a 96 bit DIO card (PXI-6509).
What we have found and NI support confirmed is that with the following the software needs to be aware of the bit offset during a write to one or more lines on a port.
Virtual Channel Physical Channel
dataEnable dev1/port0/line 2
Our assumption was that writing to 'dataEnable' a value of 1 using DAQmxWriteDigitalU8() would write to the virtual channel 'dataEnable'. What we found is that is not the case. We need to write a value of 0x04. But that the bits that are set to zero in this value written to 'dataEnable' have no affect on other lines on the port that are already set. This gives us the impression that the driver has knowledge of what bit position we are trying to write too.
So based on this why is it not possible that when I call from LabWindows/CVI to do a write to a virtual channel I cannot just do something like this:
Virtual Channel Physical Channel
Line 2 = dataEnable
Line 3 = dataClk
write( dataEnable_Clk, 1) // to set enable line high
write( dataEnable_Clk, 3) // to keep enable line high and raise clk line
write( dataEnable_Clk, 1) // keep enable line high and lower clk line
write( dataEnable_Clk, 0) // lower enable line
** assumption is that seperate lines on another port are used to present the data to the external hardware and are not shown here. The data would have bee setup before the sequence above and then change data and repeat sequence as needed.
Here I don't have to keep in mind that Enable is on line 2 and Clk is on line 3 or have to setup values of 0x04 for hte Enable and 0x08 for the Clk. If I have to do this I would rather have direct access to each port to just write the values directly. i know there is the register level I can use but doing this at a higher level is better.
In our code when a internal function is called to write data we would like to just write a value out to the virtual channel and not have to figure out the bit alignment to shift over the value to use one of the current functions.
I know it is possible to listen for multiple DI lines when performing a Change Detection (with a pxi 6511, for example), however it appears to not be a feature to know which channel was the cause of the event trigger without building your own comparison logic around the DIO reads.
I would like to see an additional property, either under 'Timing', or under 'Channel' that would allow me to ask, for the specific channel / line in the task that caused the change-event instance rather than having to search for it manually in a 1D boolean array.
While in the development environment it is easy to get a reference to a Fieldpoint IO channel - just drag and drop it from the target in the project file. Things are much more cumbersome if you need to create such a refnum dynamically. (If you are making software that should be possible to just copy onto different controllers (without involving LabVIEW) and then configure to match the available/required IO, static refnums are not usable. )
To dynamically get access to an IO point in a built general purpose application you currently have to save and download an iak file to the controller from Measurement and Automation Studio and then open that iak file in your code (Using FP Open) to get the server reference you need as an input to the FP CreateTag function. The need for FP Open and the iak file to create a server refnum is the main problem.
If FP Create Tag could do its job without any iak-file (e.g. just with the IP of the controller as an additional input)...OR even better - if there was a Create Fieldpoint IO Refnum VI avilable (no such today!?) that took the controller IP (use local if not wired), device name (or ID number) and channel name (or ID number)..then things would be much more flexible and intuitive.
There is one function that allows you to address channels just by the use of slot and channel numbers - and that is the Input Range function (which should not be called the input range either by the way as it could be an output...), so another good solution would be to offer that same functionality for the IO read and write functions.