|Product Performed to Expectations:||9|
|Specifications were sufficient to design with:||9|
|Demo Software was of good quality:||9|
|Product was easy to use:||10|
|Support materials were available:||10|
|The price to performance ratio was good:||10|
|TotalScore:||57 / 60|
This is my roadtest review for the Keysight DAQ970A data acquisition fitted with a DAQM901A, 20 channel multiplexer card. Within this roadtest article, I aim to concentrate on the two engineering tasks I had put forward in my application, namely the contactor and synchronising tests. More information on my application can be viewed in the following separate blog.
I also have my introduction into using the DAQ970A, that contains general information on it, market comparison, teardown, etc at the following blog.
So as to not detract from the DAQ970A, the information on the contactor and synchroniser test results are kept to a minimum.
The first application is to conduct performance tests on electrical contactors. I have used contactors such as these over many years, but there are always uncertainties about contactor ageing and when replacement is required. I have three 125A rated contactors for initial testing.
The first one is new and unused that I aim to use as the base data for comparing the other two contactors to.
The second has seen around 20 years service in a direct online starter, with around 15 starts per year. A visual inspection of this contactor, shows that whilst there is wear apparent on the contacts, they are still perfectly serviceable.
The third contactor has seen service for 10 years as the ‘star’ contactor in a star-delta starter and has seen in the region of 100 starts per year and 300 hours in operation. Based on my previous experience on the visual condition of this contactor, I would say that this is approaching the end of its life.
I aim to measure the temperature and contact voltage drop at different load currents to ascertain the electrical performance of these contactors, utilising the results obtained from the data acquisition unit, as a challenge to my experience.
There is a slight change to the test setup from the original plan. Initially, I had proposed to inject an AC test current through the contacts and measure this current using a current transformer connected to one of the current channels of the DAQM901A multiplexer.
However, a review of the multiplexer card revealed that each current channel is protected by a 1.6A HBC fuse. Connecting a fuse into the secondary of a current transformer is a strict no-no for me as if it blows a high voltage will be generated across the current transformer terminals, that would likely damage the DAQ and endanger me.
For this reason, I have changed to DC current injection and measuring the current via a shunt resistor, built into the DC test set.
For the new contactor, I could build a mechanism that would connect to the moving contacts, so that the contact pressure could be represented at different coil voltages. I could not fathom out how to do this on the used contactors as they were of a different design, and since the test data did not really produce any findings, I omitted this aspect for the later tests.
The DAQ was set up to monitor six K-type temperature measurements, the voltage drop across each phase the contactor, the total test current provided, the voltage and current to the coil of the contactor and the pressure applied to the contacts. A computed channel was then used for each phase to calculate the DC resistance across the contacts.
These were set up in the BenchVue DAQ application without any issues. The following 3 minute video goes through the channel setup in more detail.
For the display aspect, I used a strip chart for the temperatures and four digital displays to show the resistance across each phase and the test current injected as shown in the screenshot below.
Power to the contactor coil was supplied by a BK Precision 9801 AC source that was manually controlled to turn the contactor on and off and also vary the coil voltage as required.
Initially I used a current clamp to measure the current to the coil, but this did not produce accurate results for reasons I still have not determined. As the current to the coil was less than 1A, I utilised one of the current channels to accomplish this and achieved much better results.
Five tests were carried out on each contactor;
1. Measure contact temperature and voltage drop with 25A test current for 10 minutes
2. Measure contact temperature and voltage drop with 50A test current for 10 minutes
3. Measure contact temperature and voltage drop with 75A test current for 10 minutes
4. Measure contact pressure, voltage drop and coil voltage / current whilst varying coil voltage between 0.8 and 1.1 x nominal voltage.
5. Measure contact pressure, voltage drop and coil voltage and current whilst cycling the contactor on and off for 10 minutes
Initially, the scan interval was set to 500ms, this was then lowered to one second and then two seconds in an attempt to overcome mis-readings of the test current. This mis-reading seemed to be erratic and caused the channels calculating the phase resistance to produce a zero-ohm reading as seen below.
For the final contactor, I connected the DAQ via a LAN interface instead of the USB. Other than needing a network hub, there was no real difference in setting up between LAN and USB. Sometimes instruments are detected automatically, sometimes I had to enter them manually by retrieving the TCP/IP or USB address from the instrument and entering it into the Keysight Connection Utility.
After converting to a LAN connection, more stability was seen and the number of mis-readings reduced. There were still some, but these were at the beginning as the test voltages were applied to the contactor and were more with the Phase Resistance calculation and were corrected by increasing the range setting on the voltage drop channel. Phase C in the picture below shows the error seen.
The following plot shows the level of occurrence of these errors. Tests 1 and 2 were all USB connections and Test 3 were all with a LAN connection.
Despite these occasional errors, results were successfully obtained and were exported into Excel for comparison and analysis. As per my introduction, I found this methodology more versatile than analysing the data within the DAQ application.
Plots were created for the temperature rise across each set of contacts and at the different loads allowing easy comparison of the performance of the contactors.
From the data obtained whilst varying the coil voltage between the manufacturer’s defined limits, I was able to ascertain that the pressure on the contacts remained the same. This probably due to the spring tension design of the contact mechanism, but does show the reliability of contactors to ride through voltage dips. As the coil voltage was lowered, coil current also lowered and then started to rise again as the coil voltage was increased.
Test 5 was an extra test I added after observing changes in the contact resistance during the initial load testing. This test is purely a demonstration of how stable the contact resistance is during cyclic operation of the contactor.
For this test, I injected 10A through the contacts and manually opened and closed the contactor, whilst the DAQ continuously scanned through the measurement channels.
Admittedly, this was probably not the best way to do this as the DAQ recorded whilst the contactor was open and closed, so I had to filter out the open contactor readings within the Excel file in order to be able to analyse the data. With a DAQM903A card, I believe I could have turned the contactor on and off and synchronised it with collecting readings to save on subsequent data manipulation.
Quite a large variance in contact resistance was seen over the operations carried out. This is easy to explain for a new contactor as there will be a period of time for the contacts to bed themselves in due to the arcing of the contacts as they are made and broken. Comparing the pressure reading to the contact resistance did not produce any correlation between the two, as a lower contact pressure was expected to increase the contact resistance.
More test results and in-depth analysis can be found at another blog I have created on testing the contactors.
Could either my Hioki 8808-01 HiCorder or Omicron CMC356 carry out this test?
The Hioki only has four analogue channels and eight logic channels, so in this application it cannot compete with the DAQ970A.
The Omicron has 10 universal channels for use with the Enerlyzer software, but I actually utilised 13 channels, so I would have had to have dropped three of the measurements. However, six channels were for temperature measurement and the Omicron can only read this as a raw mV measurement, so it would have been more awkward to utilise.
Admittedly, the Omicron could also have injected the test current, so I would not have needed the DC injection test box.
Overall, I think that the DAQ970A provides the better test scenario than either of the current instruments I have at my disposal.
The purpose of this test was to try and study the operation of a synchroniser used to control a turbine / generator to allow it to connect to the Grid in an efficient and safe manner. A synchroniser will send out control pulses to the generator voltage regulator and turbine governor to control the voltage level, frequency and phase of the generator output. Whilst the test set I have responds to these commands it does not record and analyse them, so I wanted the DAQ to record the pulses as the duration of them affects the control of the generator.
This test also required the use of the Keysight counter to measure the phase difference between the two voltages which is introduced a bit further into the testing, as I decided to start with just recording with the DAQ.
For the initial synchroniser testing I used a Megacon KSQ104F synchronising module. This is a relatively simplified synchroniser used for small diesel generator set rather than the larger turbogenerators used in conventional power stations and does not control the generator voltage, just the turbine speed.
The DAQ was set to measure the voltage and frequency to both of the inputs to the synchroniser. Separate channels were then set up to measure the signals for controlling the frequency and the breaker closure, these were DC voltage channels. Two computed channels were then set up to measure the difference between the two voltages and frequencies. Two minutes of video of the words above!
The inputs to this synchroniser are 400V, which gave me an immediate problem as the both the Omicron test set, used for simulating the voltages, and the DAQM901A can only handle voltages up to 300V. To overcome this I used a multi-tap transformer to provide 400V to the synchroniser and 15V to the DAQ. I could have measured the voltage with the DAQ direct from the test set, but using a winding from the transformer, meant that the phase relationship measured was the same as that seen by the synchroniser.
Before setting this up, I utilised the DAQ to get a ‘real’ value for the winding ratio of the transformers used. The DAQ was set up to measure the input voltage and the output voltage of each of the three taps. Computed channels were then set up to calculate the winding ratios as the input voltage was increased.
One minute 23 seconds of video, showing the transformer ration measurements in progress.
The input voltage was controlled manually, whilst the DAQ was set to record values every 4 seconds. Due to this separation between the DAQ and the injection test set, it was found that occasionally, a miscalculated ratio would be generated due to the voltages being measured during one of the ramps. These recordings were discarded as data outliers. This is another scenario where the actuator card for the DAQ could have been useful to give better control during the test.
Having obtained winding ratio values for each transformer, these were entered as scaling factors for each of the voltage signals, to provide the equivalent voltage the synchroniser was actually seeing.
The DAQ was set up to scan at its fastest rate possible for the multiplexer card fitted. This is specified as 80 channels per second by the manufacturer. However, as I was only using 7 channels to take actual measurements and two computed channels, I presumed that the scanning would be proportional to the channels in use.
Initial tests were not good. Whilst the synchroniser module was seen to send out frequency adjustment pulses and a close command pulse when the phasing matched, the DAQ channels did not pickup these signals consistently.
I therefore reduced the number of channels being monitored to just the three digital signals for the frequency control and close command.
With this arrangement, I could start to see the pulses appearing on the frequency commands and the synchronising command pulse at the end of the sequence.
The screenshot above shows the frequency control pulses, but they do appear to be of different widths. There is also a smaller pulse just infant of the sync command pulse in the red trace. Below, the sync pulse can be zoomed in on BenchVue for closer analysis with the one set of markers and exported to Excel, where more markers can be created.
To see if further monitoring improvements could be made, I reduced this even further to monitoring just the synchronising command. This gave me sufficient scanning abilities to record the pulse and define a duration for it. This could be successfully exported to Excel for a detailed plot I could use in a report.
It therefore seemed that the DAQ could not scan fast enough with the DAQM901A card to be able to record all of the signals I required for synchroniser monitoring. Below are histograms of the scan intervals for the three tests carried out.
With seven signals being scanned there is a larger spread of the scan interval, varying between 2.6 and 2.9 seconds. Reduced to three signals, the scan interval is now between 125 and 315ms. Cutting down to just the synchronising command and the scan interval is between 40 and 41ms.
Turned up to its maximum pulse duration, the synchronising command was 614ms long. Ideally a data acquisition system needs to sample at five to ten times the fastest signal. From the data I was obtaining, I could scan fast enough for one to two signals, but beyond that, the system was just not fast enough. However, it would not be uncommon to have synchronising signal with a 100ms duration, implying that the DAQM901A card just isn’t fast enough for this type of application.
From the manufacturer's datasheet, the DAQM901A can scan at up to 80 channels / second for DC and 50 channels / second for AC. The DAQM902A is a reed relay card that can scan DC signals at 250 channels / second, but drops to 90 channels / second for AC signals. The DAQM900A can scan DC signals at up to 450 channels / second, but also drops to 90 channels per second for AC signals. I assume though that the system can only scan as fast as the slowest channel irrespective of the signal.
Given the prices of these cards, I do not see any benefit in obtaining a reed relay card and may as well go straight for a DAQM900A FET card with the better capabilities.
Unfortunately for UK delivery there seems to be a four to eight week wait for either of these cards, except for one supplier that has an elevated price. Therefore, I could not progress this aspect of the test for the review and I will have to return to it when a card becomes more available.
I decided to limit the DAQ to monitoring only the synchronising command and introduced the counter into the scheme to monitor the phase difference between the Grid and Generator voltages. This was done by utilising the BenchVue Flow aspect of the software.
There seemed to be two main ways to program BenchVue Flow, one utilising the specific instrument applications and the other using SCPI commands. For the initial attempt at programming, I used the instrument applications. When launched, these applications allow instructions specific to the instruments to be dragged over to the BenchVue Flow window, making programming exceptionally quick and easy. Below is the BenchVue Flow program utilising the application commands.
In order to get the data for the phase angle from the 53220A counter synchronised to the close command monitored by the DAQ, a reading was taken from each instrument within a “repeat until” loop, one of the building blocks available within BenchVue Flow.
The criteria for the loop was met when the voltage read from the DAQ was less than 1 volt, i.e. a closed contact for the synchronising command.
Using just this one loop, I found that the full synchronising pulse would not be recorded. I therefore set up a second “repeat until” loop, which was time based, to allow monitoring to continue for a further three seconds after the sync command had closed.
The final element, automatically exported the data collected to an Excel file.
When running this test program, two feedbacks are provided, the first is the data collected being displayed on a line plot next to the test program window. The second is the program stepping through its functions and providing feedback on the values being monitored for the loop control.
The test program proved to be a little intermittent in detecting the sync close command from the synchroniser and would then halt within the first loop and eventually time out as seen below.
The data from the Excel file showed a relatively slow scanning rate, slower than when the DAQ was run on its own. Trying to collect phase difference and two frequency values using the 53220A and the three control signals from the DAQ resulted in a scan rate between 1.2 and 2.2 seconds. Reconfiguring this to collecting just the phase difference signal on the 53220A and sync command on the DAQ gave a scan rate between 320ms and 530ms.
Histogram of scan rate using 53320A to capture phase only and DAQ970A to capture sync command only.
Histogram of scan rate with 53220A capturing phase and frequency and DAQ970 capturing sync control.
BenchVue Flow also has an SCPI function block that allows the instruments to be controlled by command line. For this, the instrument applications must be closed down. Previously, in my introduction, I had believed that these instrument applications were needed for communication with BenchVue, but this is not the case and using SCPI commands, BenchVue Flow is able to connect directly to any SCPI compatible Keysight or non-Keysight instrument.
Programming BenchVue Flow with SCPI commands is easily achieved by dragging the command box over to the program. The SCPI command box gives a drop down list for the instruments available and then it is a matter of entering the command text. Using the SCPI commands allows each channel of both instruments to be queried within the control loop.
I could not figure out how to get the control loop to monitor the sync command as I did when using the DAQ application module. I therefore converted this to a time based loop based around the operating time of the synchroniser, which is reasonably consistent. The first video, just over three minutes long, goes through the test setup of the synchroniser and then demonstrates a test where the sync pulse is missed. The second video is half the time of the first and demonstrates the sync test working correctly.
Excel data analysis when BenchVue Flow missed the sync command signal.
Excel data analysis when BenchVue Flow captured the sync command signal.
These slow scanning rates affect the data collected. Looking back at the tests that collected just the digital signals with the DAQ application software, a sync pulse width of 614ms could be deduced using the DAQ application strip chart that conferred with the data exported to the Excel file.
The signal collected when using BenchVue Flow was not as accurate as this in either the DAQ application or Excel as depicted in the two screen shots below. A pulse with of 847 seconds was taken from the DAQ application and 855ms from Excel.
I am disappointed with the results for the synchroniser testing. There is still some learning for me to go through to see if I can speed up the data acquisition within the DAQ itself that may improve the current setup - my suspicion is though that ultimately it would be more prudent to invest in an FET card.
Reading some documentation on the older 34970A, there are other tips for improving scanning rates, such as reducing the PLC and scanning direct to the instrument first, but I haven’t learnt how to do these from BenchVue yet.
I am still unsure why the scan rates when using both instruments through SCPI are so low and if this aspect can be improved. However, I could not find any other way in which to have the phase, voltage and control signals all scanned into one file.
Could either my Hioki 8808-01 HiCorder or Omicron CMC356 carry out this test?
This was one of the original issues that justified the purchase of a Hioki 8808-01. With its 4 analogue and 8 digital channels, it has enough capacity to record all of the signals in one hit. The analogues are displayed as waveforms, so there is a lot more manipulation required to extract, voltage, frequency and phase values.
The Hioki 8808-01 is now coming on for ten years old. It requires an old Windows 95 computer with a serial port in order to get the data downloaded for manipulation and analysis.
The updated model from Hioki is the MR8880-20 which retails for around £2,500 in the UK. The DAQ970A comes in at slightly less than this, and has so much more versatility, so for me, it is worthwhile seeing if its performance can be increased to be more in line with my needs for this application.
The CMC356 could carry out this test for a synchroniser installed in a panel being used in a live synchronisation of a generator. However, when testing the performance of synchronisers on a bench, because it is then used to provide the voltage signals and monitor the synchroniser control to adjust them, it then doesn’t have the spare capacity to monitor the pulse widths. I could carry out multiple tests, swapping channels between them to obtain the results.
It is also worth noting that a CMC injection set actually has to have two upgrades to be able to carry out this type of monitoring. The first is a £900 hardware option and the second a £4,500 software program. Options significantly more than investment into a DAQ970A. If the set does not have the hardware option, it has to be sent to Austria for installation, which then also requires a calibration, adding a further £700 to the bill.
I did mention in my application blog that testing electrical transducers is anther common aspect that I believed the DAQ970A could assist with. Given all the problems with the synchroniser testing, I decided to investigate this a little and also spend some time getting to know LabVIEW.
Transducers are common place in industrial installations converting many different parameters into signals compatible with control systems, two common ones being '0 to 10V' or '4 to 20mA'. This particular transducer I am going to test, is from Sineax and takes 0 to 1A AC current and converts it to 4 to 20mA DC current, a very common transducer found in electrical panels.
The Omicron injection test set will provide the 0 to 1A input. I will use both current channels on the DAQ, one to measure the input and then the other to measure the output. The software setup would have been quite simple, but the trial license for the DAQ Application within BenchVue has now expired. My only method in BenchVue now to communicate with the DAQ are manually entered SCPI commands.
An empty command block is dragged over from the blocks menu into the program area. I have a command to read each of the current channels. These are encased within one loop to make the measurements and then a second loop, that defines how many measurements are to be made encases the first loop. By converting the return type to a 'double' for each measurement, the graph on the output monitor will be updated.
Just under 5 minutes of video showing the BenchVue Flow programming for transducer testing.
Just over two minutes of video that records the transducer test in BenchVue Flow.
Programming within LabVIEW took me much longer, in fact, it took me a day to get the output seen in the following screenshots. Actual connection to the DAQ was relatively simple using the Keysight instrument block, seen below.
It was creating the array table and plot, seen in the program block diagram below, and convincing the readings to fill them that took all of the time.
The front screen of the LabVIEW program is also very basic and needs a lot more work doing to it.
The program does work and collects data, although I had more problems synchronising LabVIEW with the injection test set than I did with BenchVue. I still have a horrendous amount of learning to do with LabVIEW to get the program into a more useable state. This final three minute video shows the LabVIEW program and a test of the current transducer with it.
The two different test methods produced very similar results, with the largest deviation of 0.12, that is likely due to experimental deviations.
Against the transducer tolerances, which is a Class 0.5, the largest difference of 0.504% was seen at 0A input. However, the actual input measured was not quite zero, which will account for some tolerance.
Overall, I am pleased with the results of the transducer testing. There is a program within the Omicron suite that will carry out transducer tests. It too, utilises the ELT1 hardware option and costs in the region of £2,000 in the UK. The DAQ970A and DAQM901A multiplexer card come in a little cheaper than this, so is a very viable option. It also allows for transducer testing with a more basic injection test set.
However, I feel that there is room for further improvements with this scheme. An adaptation of my current amplifier to allow a DAQM907A multi-function card to control it, would enable me to produce a more automatic test function that would not even need an injection test set. Seems like another project to add to the winter 'to do' list.
This is a high-quality instrument from Keysight, that currently only really has the Keithley DAQ6510 as a comparable competitor. I have found that there is a lot more to using the DAQ, with more thought required in connecting up the instrument and the assignment and configuration of channels. This is very similar to the Omicron CMC set that I use, but a different concept to using a standard bench multi-meter, that you can quickly hook to a test circuit and start making readings.
In my previous introduction blog, I used the DAQ970A to monitor my current amplifier, and I could not really fault its performance. It replaced a multi-instrument setup, efficiently recording a number of different electrical parameters that improved the analysis of the circuit. It certainly highlighted frequency deviations, that I had not observed with the previous tests with an oscilloscope and bench meter.
The burden created by the current channel, did cause some issues during these tests. It was not so much that there was a burden, it was more that it changed as the channel moved from being scanned to un-scanned. A consistent burden would have been better in this instance. However, it was easily overcome by measuring the current using a clamp connected to a voltage channel. It would be great for me to see current channels that are unfused for use with current transformers and voltage channels that are CAT 3 rated, although I accept that this is probably of limited interest to other users of this type of apparatus.
Analysing the contactors was also very successful. There were a few minor blips along the way that may have been down to the use of the USB interface instead of the LAN. That is an issue I have had with other data acquisition apparatus in the past. The remaining errors were resolved by increasing the voltage range on the channel, although the signal level should not have needed this.
Results were easily recorded using the DAQ970A and the DAQ Application software. Whilst preliminary observations can be made with this software, I found that exporting the data to Excel, gave much more capability. It does provide some intriguing test results and I certainly hope to be able to get hold of more contactors and repeat the tests to verify the initial findings.
I can't deny that the results of the synchroniser testing was disappointing, and I need to do much more work on the scan rates to see if improvements can be made, as I still believe that the DAQ970A offers a more cost effective, technically efficient solution, than the options I currently have, so it would be great to see it up and running. In this context, it would be interesting to take a look at the Keithley DAQ6510 unit, to see how it functions and if it is faster scanning rates are better for this application.
On the plus side, the transducer testing was another very successful application. Although I opted to test with BenchVue and LabVIEW, it could also easily have been achieved as standalone monitoring. I feel that there is quite a bit of room to expand this test scenario and ultimately try and dispense with a big bulky injection test set all together.
The DAQ970A has come across as a powerful and versatile piece of test apparatus and certainly opened my eyes to alternatives to the more expensive specialist test apparatus that is used predominantly within my industry. Seeing if a more general purpose piece of test apparatus could compete with my specialised equipment was one of the targets of my application, and I believe that in the some circumstances, the DAQ970A can compete and give me an alternative. I also wanted to see if the software was up to providing results for reports, but for me, I don't think it was. I gained a lot more by exporting the data to Excel that has much better options for formatting, analysis and display.
Many thanks to Keysight and Randall for selecting me for this roadtest, it has been a great learning experience that still has some way to go. I do hope that other manufacturers of such instruments come forward and offer their units for roadtest, so that other members of the element14 community can benefit from them.