banksey255

@JRys Returning the devices would be our last resort as, in theory, they should be more than capable of meeting our requirements. I have even tested them acquiring at their maximum 200 kHz on all channels for a few hours without an error 29 occurrence. You wrote that the USB-1808X FIFO holds up to 4000 samples: Is that the aggregate of all channels, or per channel? Are you sure about this value? Continuing to investigate, I used Wireshark to assess the variation in the interval between subsequent USB BULK IN transfers (that is, the time interval between receiving data from the devices). Significant variation in this would indicate communication problems and is the only indicator I have as we do not have a hardware USB sniffer. The three plots below are for our three devices when simultaneously acquiring all 8 channels at 200 kHz: Is this amount of variation expected? These intervals make no sense to me as I would expect the FIFO to either fill up to 20 ms if it was limited to 4000 samples per channel, or 2.5 ms if it was limited to 4000 samples all channels combined, both of which are exceeded by a significant number of the intervals, yet no error 29 occurred. The only two explanations I can come up with is either that the USB-1808X FIFO holds significantly more than the 4000 samples you mentioned, or the Wireshark timestamp is quite imprecise (but then still the average intervals were 4ms, 3.5ms, and 3.5ms for the three devices, respectively).

@JRys Is there any new information on solving our error 29 problem?

@JRys As it appears to me that the CPU utilisation doesn't appear to reveal any issues, is there any way we can check the communication quality between the USB-1808X and the computer? Like a special debug version of the driver that you can provide that will report transmission errors? Basically, I'm wondering whether the signal-to-noise ratio in the communication between the USB-1808X devices and computer is so poor that there are lots of communication errors transferring the data causing transfer to slow significantly to the point where intermittently it isn't able to read the data off the devices quickly enough before being overwritten on the FIFO memory. I have no idea how to prove this with certainty unless the driver can report the number of communication errors with the devices, or if you instruct me in what to look for using USB sniffing software like Wireshark, etc.

@JRys We have experienced error 29 again, and the currently reliability is unacceptable as the system we are commissioning will be required to acquire data for periods around a month. I have run your program and below is a screenshot of the task manager results (the CPU utilisation is approximately 15%). We need a solution.

@JRys I will run your program at the first opportunity. Currently users are running my application that interfaces with the USB-1808X hardware and I will have to wait for them to finish. However, in the meantime, since it may be more useful anyway given the error was reported when using my application, here is a screenshot from device manager showing the resource usage when my application is running that shows the CPU usage is only 6%:

@JRys We have only experienced error 29 on one occasion, which required restarting our application to resolve (simply clearing and recreating tasks to restart acquisition without restarting the application continued to produce error 29), so when you tell me that you haven't experienced that error, it is not surprising. Reducing the sample rate is not an acceptable solution and is a surprising suggestion since we are using a 10kHz sample rate, which is only 1/20th (5%) of the USB-1808X capability: Are you saying that these devices cannot even reliably operate at 5% of their rated ability? I would point out that our sampling of 8 channels at 10kHz corresponds to at most a data throughput of only 625 kB/s assuming the worst-case scenario of 64-bit values, which is miniscule. The USB-1808X uses USB 2.0, which we plug into either USB 2.0 or 3.0 ports, providing the full device bandwidth equal to at least 100 times what is required for our 10kHz sample rate. Therefore, there are no hardware bottlenecks (our DDR5 RAM and Intel Core i5-13500 CPU, of course, have far greater bandwidth than USB communications). I guess the FIFO memory is on board the device? If hardware bandwidth between the device and the computer is not a limitation, what would cause the FIFO memory to overrun? Does this indicate faulty hardware, in which case we should return our USB-1808X for replacement?

@JRys I have investigated more. I want to highlight the following to help you diagnose the problem: If I take longer to read than what would take 1048576 values to be accumulated (which in our application corresponds to about 13 seconds worth of data), only then do I get error code 10017, which I find has an identical error message as error code 29 (see screenshot below). My suspicion is that the source of these errors is different, for example, error code 10017 is generated by the ULx LabVIEW driver, whereas perhaps error code 29 is generated by the hardware itself? Why would there be different error codes for the same thing? Moreover, after error 10017, we can recover by stopping, clearing, recreating, and starting the task, however when we experienced error code 29, stopping, clearing, recreating, and starting the task resulted in more error code 29 as soon as we tried reading, despite reading within a fraction of a second, which is well below the 13 seconds worth of data that the buffer should be able to hold. Something must be fundamentally different between these two error codes: My question is, what is it? I can see error code 29 appears to come from UL for Windows, however the help file effectively says this should never occur, unless the file input functions and methods are being used or if SINGLEIO is being used, and I presume the ULx LabVIEW driver does neither as it would be highly inefficient, but perhaps this suggests there is an issue in the ULx LabVIEW driver:

Hi JRys, As part of my investigations, I restarted the LabVIEW application and found that the error no longer appears to occur (previously it appeared that we were getting this error message as soon as we started acquisition). This, of course, is not a satisfactory resolution as we do not know what the cause was, nor have any changes been made, therefore I presume it will recur at some point. I am communicating with end users to try to better understand what led to the error to see if a method to reproduce the error on demand can be identified.

Hi JRys, We are setting the Samples Per Channel parameter to the equivalent to 10 seconds worth of data whilst reading all data available in the buffer approximately 50 to 100 times per second (we do not rate limit the loop, but we do iterate on each ULx read until each returns something which is one thing that effectively limits the overall loop rate), and therefore it should be impossible to overrun due to an inadequate samples per channel value. In any case, as mentioned in my original post, according to the ULx for LabVIEW help, the Samples Per Channel has no effect on the buffer size when acquiring continuous samples, and I subsequently confirmed this behaviour. One notable difference between your code and our code is that, when reading we use ULx Read (Analog 2D DBL NChan NSamp), we don't wire the number of samples per channel to read which causes it to default to -1 corresponding to reading all data available in the buffer, and we don't wire timeout as it is ignored when passing -1 for the number of samples per channel to read. In the way you have written your code, unless all devices run at the exact same clock speed, which will not occur as there is nothing synchronising the devices, you will eventually get an overrun error as samples will be getting acquired at slightly different rates by the different devices yet you read the same number of samples from each device per iteration causing the iteration rate to be limited by the slowest acquiring device, eventually causing the fastest acquiring device to overrun its buffer.

The ULx for NI LabVIEW help states for the input task buffer size: "When you acquire a continuous number of samples (the ULx Timing VI's sample mode input is set to ContinuousSamples), ULx calculates the buffer size based on the number of channels, the sample rate, and the device's packet size requirements." How, precisely, is this calculated? I ask as we are getting the following error despite calling the ULx Read VI approximately 50 to 100 times per second and asking it to read all the samples currently available in the buffer: Error 29 occurred at ULx Read (Analog 2D DBL NChan NSamp).vi Possible reason(s): Measurements: Samples in the buffer were overwritten before they were read. Reading the data more frequently, or specifying a fixed number of samples to read instead of reading all available samples might correct the problem. In NI DAQmx, which the ULx driver appears to try to provide an identical interface to, it allocates a buffer at least as big as the value of the samples per channel attribute/property, and so in this respect it appears the ULx and DAQmx drivers differ in behaviour, and, based on the ULx driver help, I apparently have no control over the buffer size. Am I mistaken? Edit: I managed to discover that the buffer size created by ULx for LabVIEW appears to have 1048576 elements, and since we are using a 10kHz sample rate with eight input channels, the buffer should be able to hold about 13 seconds of data, which makes me question whether that is the problem. In case it is relevant, we are attempting to continuously stream from three USB-1808X at once using three separate tasks. To reiterate, we are reading each task 50 to 100 times per second. I came across another post where it was indicated that reading from multiple devices can be problematic: https://forum.digilent.com/topic/26880-how-do-i-get-two-analog-inputs-from-different-devices/#comment-81595. If so, is this only an issue with ULx for LabVIEW? That is, if I used LabVIEW to directly call UL for Windows or UL for .NET, then would this problem not occur? If so, which is higher performance, UL for Windows or UL for .NET? For example, it appears UL for .NET calls UL for Windows (CBW) under the hood, suggesting it would it be better if I call the latter from LabVIEW?

I am adding support for Measurement Computing hardware to a LabVIEW application that I want to be compatible with any device supported by ULx. How do I programmatically determine the sample rate limits for any given task for any given ULx for NI LabVIEW supported hardware? So far, the only way I have found to somewhat accomplish this is using the current version of ULx for NI LabVIEW by passing infinity as the rate to "ULx Timing (Sample Clock).vi", which then generates an error whose message contains the maximum sample rate rounded down to the nearest integer, and then pass zero as the rate and get an error whose message contains the minimum sample rate to three decimal places. However, I am not satisfied with this precision. The only alternative I have identified that does not lose precision requires modifying ULx for NI LabVIEW, however I would prefer not to have to resort to this. Have I overlooked a way to get these limits?

Hi John, You appear to be addressing something else. I am aware there are limitations with your hardware with respect to acquiring data from channels with mixed measurement types, which is described in the ULx for NI LabVIEW help in the known issues section. Having said that, your help document does state some of your hardware supports composite tasks, and I have noted that composite input and composite output options exist as polymorphic instances of the ULx Create Channel VI. In any case, I do not believe the hardware I am testing my application development with has such capability (USB-2416-4AO), however I have observed that your DAQami application is able to acquire data from multiple measurement types from the hardware I currently have available, albeit perhaps it achieves this by creating separate parallel tasks (it's not something I have looked into, but I can see in DAQami that the sample rate limits differ for analog, digital, and counter, which suggests that it does create separate parallel tasks). To try to clarify, my forum post is motivated by wanting to create a user interface that can work with any I/O types as I will not know this information apriori (that is, it must be customisable). At present, it appears (although please correct me if I'm wrong) that the only way I can do this is to have one physical channel control for every concievable I/O filtering option. It would be much simpler if I could programmatically create my own equivalent of your ULx I/O Name Filtering dialog so that the user can change the filtering in the deployed application to match their physical setup as that would permit a single physical channel control to be used, rather than requiring many physical channel controls. To try to be more clear, here is a screenshot from what my current user interface looks like (refer to the central column), where my idea would be the appropriate I/O type filtering of the Physical channels control is programmatically set based on what option the user selects in the Measurement Type control (the user specifying channels is completely separate from where I actually configure hardware, and I separate channels into groups as necessary in between, for instance, to satisfy any hardware constraints on composite tasks): Best, Stephen

@ajerno, perhaps try creating a composite task using the ULx Create Channel VI by selecting Composite Input -> Analog -> Voltage when adding voltage inputs to the task, and Composite Input -> Analog -> Temperature when adding temperature inputs to the task. Edit: I've subsequently realised that is what you originally tried.

Hello, Is there a way to programmatically modify the physical channel control I/O filtering? DAQmx, which ULx appears to be modelled on, offers this capability through property nodes (see screenshot below), yet ULx does not appear to. If this capability does not exist, can it please be added? Without it, it requires one physcal channel control per I/O type and port/line filtering, which can amount to requiring many controls (ULx filters between 18 different I/O type and port/line filtering, thus, at present, it requires up to 18 physical channel controls). It would be much simpler if a single physical channel control could be used whose I/O filtering can be programmatically modified.

I have discovered the problem: I overlooked step 2 in building an application installer (that is, including ..\Program Files\National Instruments\Shared\ULx directory and contents). After copying this folder to the computer the application is deployed on, the drop down list on the ULx for LabVIEW physical channel combo box now is enabled and populated. Thanks.

I have found I can make calls to the cbw64.dll library to determine valid device identifiers and analog channels, which provides an alternative approach.

Jeffrey, in your LabVIEW project, you also have a virtual folder named ULx. What else are you bundling with your project in there? Can you please save your LabVIEW project for version 19.0 and upload it here? I can then build your project and deploy it, completely eliminating what I am doing. Thanks.

Hi Jeffrey, The control's default value is not the issue. As mentioned in my original post, I can manually type in "Dev0/Ai0:4" or similar into the physical channels control and everything works (see screenshot below of my attempt to replicate your code, which shows I am reading measurements). To reiterate, the problem is that the physical channels control's drop down menu is disabled and greyed out (which I've drawn a red box around in the screenshot), which means that the user has no way of knowing that Dev0 is a valid device identifier and which Ai channels are valid.

Thanks, Jeffrey. Sorry for not being clear enough in my original post resulting in your misinterpretation. I went through everything in the help document you cited, yet I didn't identify anything to be missing. Specifically, on the system connected to the USB-2416-4AO: Microsoft .NET® Framework 2.0 is installed (2.0.50727.4927 to be precise) through SP2 being included with the .NET 3.5 SP1 installation in Windows 10 InstaCal and Universal Library 6.73 is installed Everything else in that help file appeared to just be generic instructions for creating a executable and installer. Have I missed something?

Hi Jeffrey, It is still not working for me. I updated to the latest version of ULx, and have tried removing and readding the USB-2416-4AO in InstaCal. However, my built LabVIEW application still shows the button for displaying the drop down menu as disabled and greyed out, which hopefully you can see in the following screenshot: When I run my built application on the computer I am developing it on (the computer that the hardware is connected to is a different computer), the button for displaying the drop down menu is enabled, and although I have no hardware connected, at least when I click it I get the menu shown in this screenshot: I have built the application using LabVIEW 2019 SP1 64-bit, then deployed it to the computer connected to the hardware by building an installer. I also tried building your LabVIEW example "ULx Cont Acq&Graph Voltage-To-File(Binary)" and deploying it, and the same problem occurs (button for displaying the drop down menu is disabled and greyed out). Please advise.

Is the physical channels drop down menu supposed to populate in LabVIEW? That is, the ULxIORefnumTagName control I can create by right clicking the physical channels terminal on the ULx Create Channel VI and selecting create control. I can manually type in a physical channel using the proper syntax and create/run a task without issue, but the combo box doesn't populate to allow the users to easily select channels. How do I get this combo to populate? This post suggests it is possible: