Jeffrey

The DAQami program does have support for Windows 11 but, there is a catch. Installed by itself does not work and this is because it installs an older copy of InstaCal. Why does that matter? Because InstaCal installs tools that DAQami uses to make your hardware device available to use. With Windows 11 now out, our testing found that InstaCal was not compatible. This was corrected with the release of InstaCal 6.73, however the DAQami installation has yet to be updated to include InstaCal 6.73. Because of this, it is recommended to install both DAQami and the new version of InstaCal. InstaCal doesn't need to be removed ahead of time because the installation program will remove old components and replace them with new. If you already have DAQami installed, all that is need is to update InstaCal. One last note, this only applies to the single DAQami download on the Measurement Computing download page. If instead, the MCC DAQ Software CD is used, its version installs the update version of InstaCal that is included with the CD.

That is the norm.  InstaCal does not nor has ever provided digital IO testing for the PCIM-DAS1602/16.
Unfortunately there are no 'canned' apps supporting digital IO testing for this board, however using the UL examples you can create your own diagnostic app.
To test the DIO on the 37 pin D connector, you would use ULDI04 or ULDI05 for input, and ULDO04 or ULDO05 for output.
To test the DIO on the 40 pin header, you would use ULDI01 or ULDI02 for input, and ULDO01 or ULDO02 for output.

Right click on the name of the app, and select "Run as administrator."

Hello @Joerg Hampel
I suggest you have your customer run the LV-link3 examples:
DtAinSingle.vi and/or DtAinMultichannelSingleU32.vi or similar example.
I ran these two example more than 20 times each, there were no errors.
 

You the man Jeff!  I found another copy of cbw32.dll in System32.  After deleting, I get past the error.
Thanks a million.
Sincerely,
Jon Morris

The 26 character key is what sets the features for the various versions of DASYLab (Lite, Basic, Full, Pro, or Runtime).
certainly.
this folder:  https://mcc.download.ni.com/#Archive/DASYLab/DASYLabV13/
this is the download I recommend:  https://mcc.download.ni.com/Archive/DASYLab/DASYLabV13/DASYLab 13_0_0a.exe
Depending on the MCC driver you used (check your development computer, DASYLab 13 configurator, installed drivers):
https://mcc.download.ni.com/#Archive/DASYLab/DASYLabV13/MCC-DRV all V13/MCC-DRV_13_4/
or
https://mcc.download.ni.com/Archive/DASYLab/DASYLabV13/MCCDAQ-Classic Driver/mcc-classic.13.0.0.632.en.dlp
to be clear, to make the runtime run like the original, use the MCC DASYLab driver used on the DASYLab 13 installation.
Easy way to tell is to run DASYLab 13, go to the modules >> inputs/outputs. 
If the folder name is MCC-DRV use  https://mcc.download.ni.com/#Archive/DASYLab/DASYLabV13/MCC-DRV all V13/MCC-DRV_13_4/
if the folder name is MCCDAQ (or similar) use https://mcc.download.ni.com/Archive/DASYLab/DASYLabV13/MCCDAQ-Classic Driver/mcc-classic.13.0.0.632.en.dlp
still not sure?  Send me a picture of the configurator, Packages tab with Data acquisition tree expanded so I can see the list of drivers you have installed and their rev numbers.

Hello @Jennifer3798
as requested...
153862B.STEP

Yes, that is MCC's recommendation.
 

Have you seen this:
https://www.mccdaq.com/pdfs/manuals/Mcculw_WebHelp/ULStart.htm
if has the most comprehensive information on the hardware supported features, but it is mostly for the Universal Library (syntax programming).

The second from the last picture is 'ringing'.  it is most often caused by a bad ground somewhere.
There is something amiss with your Pi Zero2W. You stated previously, you have 2 different models of Raspberry Pi computers, one shows the problem the other does not.  If the same problem was seen on both Pi's I would say the issue is the MCC 172, but since it does not. I have to conclude it is the Pi Zero2W, and  recommend you contact the vendor of the Raspberry Pi Zero2W.
Regards,
Jeffrey

Hello Tatsuro,
The onboard micro on the 172 handles the SPI communications to the ADC and buffers the data, so it is not affected by the Pi processor load.  As long as you don’t get overruns the data should be considered valid.  Do you see the same spikes if you measure something without IEPE?
I posed your issue to one of our hardware engineers.  After reviewing the schematic of the Raspberry Pi Zero2W, here is his response
The MCC 172 is powered by 5V passed directly from the micro-USB connector, but due to its small size there is not much room for capacitors on 5V.  You may have better luck if you find a way to add additional capacitance to the 5V net right at the Raspberry Pi (between the GPIO header 5V and GND pins would be a good location.)  Pi CPU activity may be causing supply spikes.  I suspect more bulk capacitance would help (47uF – 100uF), but you would need to experiment with different values.
Regards,
Jeffrey

Hello @tnag
Based on the information you provided above, You have proven the MCC 172 performs admirably when operated with the Raspberry Pi 3B.  The noise occurs when you use the Raspberry Pi zero 2W. 
Meaning the problem is not the MCC 172.  Suggestions:
Try a different RPi Zero 2W;
Try a different power supply than the one you used with the RPi Zero 2W or check it's output for noise;
Contact the vendor of the Raspberry Pi Zero 2W and provide them you test results.
Regards,
Jeffrey

Hello @Mohammad Royvaran
No it is not possible to sync 2 WebDAQ 504s.
I don't know to what server your computer is sync'd.
Webdaqs use NTP to synchronize their clocks and calculate clock drift.  They connect to pool.ntp.org, which are public NTP servers.  We cannot spec the timing accuracy or synchronization of multiple units because it depends on the latency of the internet connection, number of hops to the NTP server, etc.  This can vary for each of the units on the same network because things constantly change on the internet.
Regards,
Jeffrey

The USB-1608FS does not have an analog trigger, just digital trigger. TracerDAQ uses an algorithm where it sorts through the data looking for the first instance where the trigger value meets the analog input data value, and starts to display the data from that point forward.
To be clear, there is no undocumented method, just a sort through the acquired data to find the first match.

Hello Robert,
Here is a general purpose op-amp based comparator schematic for multiple channels:

There are many choices for Op-Amp selection.  LM741, LM747 (dual LM741) are just a couple.  A quick Google search for "General purpose Op amps" will return a good selection.
Here are a couple links to app notes you may find helpful:
https://www.edn.com/using-an-op-amp-as-a-comparator-here-is-what-you-need-to-know/
https://edn.com/wp-content/uploads/AN-849.pdf
User's manual for the USB-3114:  https://www.mccdaq.com/pdfs/manuals/USB-3114.pdf  See page 14 or 23 for pin out.
For information on how to program the USB-3114 using the Universal Library, https://www.mccdaq.com/pdfs/manuals/Mcculw_WebHelp/ULStart.htm
From Hardware Reference, click Analog Output Hardware >> USB-3100 Series.  the library function to output a User defined value is cbAOut()/AOut()/a_out() for Win32, .NET, or Python for windows respectively.
The above information is by no means complete.  Measurement Computing offers suggestions only for additional circuitry.  It is the User's responsibility to verify the design of provided circuitry.
Regards,
Jeffrey

Hello Robert @Montelius,
Unfortunately no, as the documentation states the USB-1616HS-BNC can only be analog triggered using the first channel in the scan.
Thinking outside-the-box, you could set up some number of op-amps, configured as comparators (one for each analog channel you want to use), with each comparator's threshold set to your desired value, wire OR the outputs together, and connect that output to the digital trigger input.  In this way you can satisfy your multi-analog input requirement.
To control the thresholds programmatically, you could utilize a USB-3114 (16 analog outputs  https://www.mccdaq.com/pdfs/manuals/USB-3114.pdf)
Regards,
Jeffrey

Thanks for the very helpful feedback Jeffrey. It pointed me in the right direction to solve the issue. 
Since our IT network only supports Windows 10 PCs, a few days back I had taken the involved new Windows 7 Pro industrial PC  home to have all latest Windows 7 Pro updates installed. Then I brought it back to the office and did the MCC6.53 installation without an internet connection being available at install time (same when I installed 6.73) and also when the USB-TC module was plugged in. That is how we got into this issue of the USB-TC module being detected as a USB-2020 module.
After getting your feedback, I took the involved Windows 7 industrial PC back home together with the USB-TC module. I provided an internet connection this time. Uninstalled MCC 6.53 and also deleted the 'C:\ProgramData\Measurement Computing' folder with all its contents. prior to re-installing MCC6.53. When installation completed I rebooted it. Then connected the USB-TC module. This time Instacal also reported it as a USB-TC module.
So it looks like at install time it is critical to have an internet feed available so the proper driver gets installed by Windows 7 Pro. 
After solving this, I was able to but the ATS system back into production line use. So thank you very very much for pointing me in the right direction.
Thanks. Best regards,
Everardo

Hello @malanskas
Those vi's are part of the now obsolete Universal Library for LabVIEW.  It was discontinued about 2008 and was designed to operate in 32 bit versions of LabVIEW.
Of course you can still download and use those vi's, however they are no longer supported.
Here is the link:  https://mcc.download.ni.com/#Archive/UL-LabVIEW/LabVIEW legacy 6.0-8.2.0 (unsupported)/
Be sure and read the ReadMe.txt for additional installation information.
Notes: 
The UL for LabVIEW will not install on 64 bit versions of LabVIEW. You can use Windows 32 or 64 bit versions. You do need to have installed InstaCal (6.73 is the latest version). The UL for LabVIEW has not been tested with any versions of LabVIEW newer than 8.2, Windows XP, or any MCC products released after 2006 Measurement Computing offers NO support.   
Regards,
Jeffrey

Hello @Francois Ouellette,
I recommend you set one task to external clocking and the other task to internal clocking.  Since input follows the output, I would set/start the input task with external clocking so that it waits for the output task to start first.
you will need to install a physical wire (not a virtual one  ) from the USB-1808X's OCLKO to ICLKI prior to running your vi, starting the output task then the input task.
If that does not resolve it for you, then please save a copy of your vi, and then strip out anything not required for me to see to the issue you are referring.
Regards,
Jeffrey

Hello @Vishank Battar
Unfortunately, you do need to have access to the hardware to add the devices to InstaCal and then to use them in LabVIEW.
Regards,
Jeff

As requested...
Vendor_Questionnaire_COV_Info_MCC_172.docx

Measurement Computing does not offer a recommendation for Raspberry Pi version, nor the amount of on board RAM. However, I have successfully used models version 3, 3B and 4B with MCC DAQHats.  I have found the newer models such as the Raspberry Pi 4B is my preferred model with 4 GB RAM. My reasoning has nothing to do with MCC DAQHats performance, but rather the software development packages I can fit on the device.  For development I use PyCharm and CodeBlocks for Python and C respectively.  Both IDEs fit comfortably on the RPi 4B, with room to spare for all the misc. files I use and/or generate.

Hi,
I'm Jeff, I am new to this forum, but I have been working at Measurement Computing for over 20 years.  I have answered calls and emails for countless customers.  We are migrating support here to better serve our customers.  Just so you know, you can expect the same high quality support you have received on the phone and by email from MCC, just now on this forum.  
I look forward to working with you!
Regards,
Jeff

Hi,
I'm Jeff, I am new to this forum, but I have been working at Measurement Computing for over 20 years.  I have answered calls and emails for countless customers.  We are migrating support here to better serve our customers.  Just so you know, you can expect the same high quality support you have received on the phone and by email from MCC, just now on this forum.  
I look forward to working with you!
Regards,
Jeff