Jeffrey
-
Posts
306 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Posts posted by Jeffrey
-
-
Hello @ajerno
Normally I would set this up and test it for you, but the one device(s) I don't have in my collection of MCC devices is a USB-TC-AI or USB-TEMP-AI.
But I do believe this is what you need to do:
Note I am just using ULx create channel vi as AI Voltage and AI Temperature where you are using Composite mode (Compl AI Voltage, etc.) for both.
Also the USB-TC/TEMP-AI's cannot be clocked so don't use a ULx Timing vi, rather just use the "Wait until next ms multiple" vi native to LV and set it to an appropriate rate. the max update rate on the USB-TC-AI is 2 Hz so 500 mS is as short as you can go.
Regards,
Jeffrey
-
Hello @SPL
Unfortunately, the USB-230 series is not supported on the Linux OS.
Here is a link to the list of Linux supported devices: https://www.mccdaq.com/PDFs/Manuals/Linux-hw.pdf
Perhaps the USB-1608G or USB-1608GX would be a good fit? https://www.mccdaq.com/usb-data-acquisition/USB-1608G-Series.aspx
The USB-1608G series is supported on Linux.
-
Hello @RicoE
Sorry there is no way we are aware of to use Openlayers.Base.dll in a .NET Core 6 windows app.
At there present there are no plans to update this.
Regards,
Jeffrey
-
-
Hello @Tracie Gordon
Due to the sharing of personal information needed for an RMA, your posting will be responded to via a private messaging post.
-
Due to the personal data transfer required, this post to be responded to in private chat.
-
Hello Cameron0,
There is no USB B connector on a WebDAQ. It can only be accessed via network connection either direct connect or via your network. So I think you are using the wrong software.
To access a WebDAQ you use the REST api. it is located https://www.mccdaq.com/downloads/WebDAQ/REST-API/1.0.0/
-
Hi John,
Installing InstaCal should not be that hard.
You have something wrong on that computer. perhaps run a virus scan, windows update, or go to an earlier restore point.
My recommendation is that you uninstall all MCC software. then search the system (starting at c:\ ) for cbw32.dll delete all copies of this. as it is only used by MCC there is no harm in deleting it. But, if it makes you feel better, just rename it to something like cbw32.old for example. it would be interesting to know how many copies you have on the system, and what rev's they happen to be but, if you don't capture that don't worry.
you might also consider purging the registry of any left over keys. you may want to work with your IT folks on that if you are not comfortable editing the registry.
Once all software and registry entries are removed it will be like MCC software nor DASYLab has ever been there.
Go to our download site and download fresh copy of mccdaq.exe https://mcc.download.ni.com/downloads/MCCDaqCD/mccdaq.exe
if you need fresh copy of DASYLab 2020: https://mcc.download.ni.com/#Archive/DASYLab/DASYLab2020/DASYLab_2020.0.0.339/
Another option, just for the sake of testing and verifying that the USB-1608Gs you just received operate correctly is to download and install the mccdaq.exe on a different computer, attach a USB-1608G and confirm it functions.
-
Hello @GordonFreeman,
Assuming your code does not include a request to the device for its name of device id (most folks do not include this library call).
Yes the code written for the PMD-1208LS will also work for the USB-1208FS-PLUS
-
All you need do is download and install the latest MCCDAQ.exe.
All drivers are included.
-
Yes, the physical channels drop down menu does populate in the ULx Create channel's Physical channels vi
for this to work correctly, with LabVIEW completely closed (VERY important), run InstaCal to add and configure your MCC device, and then close InstaCal.
Now run LabVIEW. I recommend you open an ULx for NI LabVIEW example appropriate for the MCC device you have and click the drop down of the Physical channels.vi.
these examples are found on your system at, for example:
C:\Program Files\National Instruments\LabVIEW 2021\examples\ULx\Analog In
-
Delete your .amicfg file(s) before you run DAQami.
This will remove any existing configuration(s).
-
Hello @Kaitlyn Lawrence,
Sounds like you have a bad installation or are missing some of the Windows 7 updates. After running Windows update for Windows 7 (there are a lot of updates), download and install this version of the mccdaq.exe
https://mcc.download.ni.com/Archive/MCCDAQ_CD/Archive_6.72/mccdaq.exe
Note: The USB-2416-4AO MUST show up in device manager as a DAS Component before you can access it in InstaCal or DAQami.
-
Hello @minche
DAQami saves your configuration as an .amicfg file
These files and your data files are saved in your C:\Users\YourUserName\Documents\Measurement Computing\DAQami folder.
You can delete them if you need.
But it is possible this is not the problem you are having.
USB-TC temperature inputs are static sensitive. When changing the thermocouple wiring, you need to observe proper safe static handling. This means prior to installing or changing the wiring of the USB-TC you need to ground yourself to discharge any static that may have built up on you, and you should NOT change the wiring while the USB-TC is connected to the computer (via the USB cable). To be clear, from the previous sentence 'changing the wiring' means not only changing a TC, but moving, installing, or removing. Failure to do adhere to these rules may damage the static sensitive inputs of the USB-TC.
You may ask, "Why are the TC inputs of the USB-TC not better protected from static sensitivity?" The answer is they are a protected as we can make them without sacrificing measurement sensitivity. With more static protection, the less accurate the temperature measurement.
I have found the best way to test to see if you have impacted the performance your USB-TC (i.e. how to discern if you have a damaged device) is to test the USB-TC using the InstaCal app already installed on your system. Attach one USB-TC with existing TC wires in place, and run InstaCal (Start >> Measurement Computing >> InstaCal). During the app launch should it hang up or get stuck until you unplug the USB-TC, the device is damaged. Or, should it hang at anytime while you configure the device or test the device in InstaCal, the device is damaged.
-
Using the WaveForms SDK and a supported IDE such as Python or C, You can toggle a digital bit.
The Digital Discovery includes 16 channels (or bits) of digital IO.
See https://digilent.com/reference/test-and-measurement/digital-discovery/reference-manual, section 9.2 and foot note 6.
Included in the WaveForms SDK, see python examples DigitalIO.py and DigitalOut_Pulse.py, or see C example digitalio.cpp.
Note that as these are static IO, they are software controlled. Depending on the length of the pulse, a repeatable pulse duration may not be achievable.
Though not the Digital Discovery, I have done some testing using the digital IO of the Analog Discovery 2. The pulses range anywhere from approximately 4 kHz to 20 kHz. This is due to latencies caused by the Windows OS.
You will want to verify performance on your own system.
-
Per the published specifications found https://digilent.com/reference/test-and-measurement/analog-discovery-pro-5250/specifications
Under the heading of Spectrum analyzer, it states the frequency range is "DC to maximum bandwidth of the scope."
Under the heading of Mixed Signal Oscilloscope, Bandwidth is 100 MHz.
-
Do not run the examples as root (i.e., don’t call ‘sudo bin/single_value_read’, just call ‘bin/single_value_read’). The lockfiles used for synchronization for the hats do not work well for root.
Also, this daqhats_read_eeproms issue is new to bullseye (maybe only on the slower processors.) The script calls modprobe i2c_dev to load the I2C bus driver, then detects the available buses. It seems that bullseye changed modprobe so it returns before the load is complete, so the first time you call daqhats_read_eeproms it won’t see the i2c bus. The second time you call it, modprobe has already finished and the bus is visible.
A change has been made to daqhats_read_eeproms to wait until i2c_dev is loaded before detecting the buses and it fixes the issue on a Pi Zero. Please download a fresh copy of DAQHats software and let me know if that resolves the problem.
-
1 hour ago, Sid_1 said:
So, how do I use a_in() to get return code ?
Take a look at example ULAI01.py.
the UL function call to a_in() is enclosed in a Try/else/Except. Note that in the Except clause is where the error code is trapped.
1 hour ago, Sid_1 said:Can you please tell how to do this ? Is it using scanoptions.background ?
yes, all you need do is launch background scans for analog in or analog out. the driver handles concurrent operations.
1 hour ago, Sid_1 said:I have observed that ul.a_in() stops when I run ul.a_out().
these are static library calls in that they only return a single value. they don't "stop" when you call the alternate, you simply cannot call them both at the same time.
Threading is not recommended when using MCC devices, each time you instantiate a new thread for the device, you are re-initializing the device. Sometimes it can recover, sometimes it cannot. I have no data on when either scenario will occur.
1 hour ago, Sid_1 said:...But very rarely I get the 'FIFO went empty...' error.
That is a very different problem. when the fifo goes empty, error 29 for input and error 78 for output, it means the system was too busy to service the driver's fifo flag(s). it could be caused by multi threading or you just have too many other apps running at the same time. But it doesn't mean the device dropped off line.
-
Hello @Anatoliy
Unfortunately we do not have the mccdaq.exe in any other formats.
you can use 7zip or similar to extract the individual installers that make up mccdaq.exe, but they are still installers.
-
Hello @Sid_1
44 minutes ago, Sid_1 said:I must run this status check (polling method) in a separate thread, so that any other DAQ operation remains unaffected.
You don't need a separate thread, The USB-231 is capable of concurrent operations, including analog input scan, analog output scan and GetStatus() for both types of scan.
But why do you need "...to have a feature in my software which can show whether the connection to DAQ is alive or not."?
Have you seen instance(s) where the USB-231 drops off line? There are few ways that can manifest itself. Most common is if your computer it set to allow it to turn off power to the USB port. There is a setting for that in your computer's Device manager, USB Root hub power. Or, if the USB-231 receives a signal beyond its input range as listed in the published spec.
If you really want to implement this, I recommend you periodically call a_in() and check the return code.
If it is 0, there is no error, the device is working correctly.
if it is > 0 there is a problem. For example error 5: Dead A/D, "The A/D device on the specified board is not responding. Either the board was installed incorrectly or the board is defective. Run the configuration program and make sure that the correct boards was installed."
For a complete list of errors the device / UL can return, see https://www.mccdaq.com/pdfs/manuals/Mcculw_WebHelp/ULStart.htm
-
The FIFO transfer is irrelevant. You have no access to that. That would be akin to figuring out your automobiles' speed by looking at engine RPM.
It is the buffer transfer that is important. Prior to calling AInScan() you would have created a buffer using WinBufAllocEx() or ScaledWinBufAllocEx()
You/ your app makes this happen when you call the UL library function WinBufToArray().
Using another UL function, GetStatus(), you find out where your scan is writing data to the local buffer. When it is above the mid point you copy the lower half of the buffer to local array and when it is below the mid point you copy the upper half of the buffer to the local array.
Just for the sake of this example, let's say you are acquiring data from 1 channel, at 1 kHz. In your app you create a buffer using WinBufAlloc() for 1000 samples. You set your app to take a time of day (TimeOfDay) reading just before you start your app.
Immediately following the scan start, you start a timer/or sleep to periodically call GetStatus(). FYI, I recommend you call it every 250 mS. Among other parameters, GetStatus() returns CurrentIndex. This lets you know where the the driver is in writing to the buffer. When CurrentIndex is above the mid point, (in this example, 500) you can copy the lower half of the buffer to local array(). Array(0) is your initial sample. That sample was taken as close as the collective system can to your TimeOfDay reading so that is the time stamp for Array(0). Since this example is set to acquire data at 1 kHz or a new sample every 1 mS, Array(1) is TimeOfDay +1 mS and so on.
You might ask, "What do you mean, 'That sample was taken as close as the collective system...' ?"
There is an operating system delay in setting up scan. it can be between 20 mS to 80 mS. To be clear, there is little you can do remove or minimize that time delay. Windows is a non-deterministic system and at time Windows needs to service a higher priority than your app such as memory refresh, Screen refresh, Mouse movement, etc.
The only way I have found to negate or reduce the scan setup time is to use the External Trigger option of AInScan(). In this way, your scan sets up and waits for the external trigger. You can use a digital bit set to output tied to the digital trigger, take your TimeOfDay reading and toggle the digital bit On then Off (rising edge). All subsequent samples would follow the same time stamp rule as above.
-
Hello @Adam1973
I cannot speak for other companies, but Digilent does not offer an annual calibration service.
For calibration, I recommend you send it in to a local NIST traceable calibration service. if the unit fails to meet the published performance specifications, you (or the Cal house) can send it in for repair.
-
Included with the daqhats software is a control panel called the MCC DAQ HAT Manager. It is installed in the Accessories of the Raspbian start menu.
Please run it. When it pops up, click on Read EEPROMs button, and follow the onscreen prompts. Click OK
Then click on the List devices button. It should show you your MCC 118 and other information. Click OK.
Now, click on the MCC 118 App button. It should show you the number of devices found or the address of the device. If a device is found, click on Open button. The display will show you the data being read by your MCC 118. Does it?
If not, Something to check:
Click on the “Start Raspberry”,
Click on Preferences >> Raspberry Pi Configuration,
Click on Interfaces tab,
Are SPI and I2C enabled? If not, enable them and click OK.
Try running single_value_read.py again.
Did resolve the issue?
If not, do you have any other HATs or software running in your Pi Zero 2W? If so, for the purpose of testing, please remove the HATs and terminate the apps while working this issue.
-
Hello @MikeT
The USB-1608G series does not include a real time clock feature. so there is no way for it to time stamp the data.
You can accomplish this depending on your sampling method:
1. If taking individual samples using the UL library call AIn() or VIn(): Use an IDE built in time of day function call just before or after you call AIn or VIn.
2. if streaming analog data in using AInScan(), Again, use the IDE's built in time of day function call just before the scan begins. Since the AInScan() is hardware clocked, you know how much to offset each collected sample after the scan starts.
Note that all supported programing IDEs such as C/C++, Python, VB.NET and C#.NET have built in functions to read the current time, regardless of Windows or Linux.
USB-1208FS-Plus, Digital Input Event Handler & Counter Input Debouncing Setup
in Measurement Computing (MCC)
Posted
Hello @jp07
Sorry no, the event handler is only to be used with an analog input scan.
not a feature, to know the state of any of the digital inputs, you poll them in a loop.
You would need to add an RC filter or capacitor to filter out the debounce.
The amount or size of the capacitor will depend on the frequency you measure with an oscilloscope.
There are many good sources for helping you with this on the internet, here a couple links:
https://www.circuitbasics.com/switch-debouncing/#:~:text=Switch bouncing is not a,changes in the switch signal.
https://www.digikey.com/en/articles/how-to-implement-hardware-debounce-for-switches-and-relays