Introduction
This is the last set of experiments I am using the 3 Series MDO with as part of my roadtest. The objective is to carry out further partial discharge testing on some cable samples, however, this test process will allow me to set up faults within the cable insulation to verify the pattern of the pulses for specific types of faults. This requires the use of a manual high voltage test set to create the voltage applied to the cable samples, so will need to be conducted to rigid test procedures.
I have two types of cable samples, a 132 kV rated single core cable and a 3.3 kV rated 3 core cable available to carry out tests on.
Test Setup
The test setup diagram is taken direct from my application. A high voltage source is used to charge the cable with an AC voltage up to a maximum of 40,000 Volts. The oscilloscope will be used to monitor the partial discharge activity in the cable.
I plan to use both a capacitive coupler and a radio frequency current transformer (RFCT) to capture the pulses. The capacitive coupler is limited to 15,000 Volts, so I will not be able to utilise this for all of the tests. I have access to a PDflex program written by the team at the High Voltage Laboratory within the Electrical Sustainable Power Laboratory within The Electrical Engineering, Mathematics and Computer Science Faculty of the Technical University of Delft, in the Netherlands. This program is non-commercial and only used for research purposes, it was chosen as it is designed to read the 'wmf' file format created by Tektronix oscilloscopes, which should make the life of a non-programmer easy. The software can also read Matlab or bin files.
PDFlex Software
To capture all the activity, I was going to save the data from the oscilloscope into the native 'wfm' file format for Tektronix scopes. To get a time stamp reference against the AC sine wave, PDflex utilises a sawtooth signal from 0 to 4.94 Volts. I aimed to produce this using the built in waveform generator within the oscilloscope. I then end up with two 'wfm' files, one for the data and one for the timing.
I decided to initially set this up whilst testing with the TGA-B and could easily produce the timing signal alongside the partial discharge data collected as seen in the two screenshots below.
Then one of the main issues for this aspect of the tests came to light. Tektronix have two native file formats for their oscilloscopes, 'wfm' and 'isf' formats. The 3 Series MDO will only save to 'isf' format and does not recognise the 'wfm' format, that appears to be the domain of the 4 Series.
To attempt to overcome this, I utilised TekScope Anywhere software from Tektronix, that does recognise both native file formats and can be used to convert between the two. Whilst strictly not part of this roadtest, I must take the opportunity to say that the TekScope Anywhere software is really, really nice. It functions in much the same way as the Tektronix scope does, giving the ability to add measurements and signal analysis to waveforms saved on the oscilloscope.
The problem with this methodology was that the PDflex software will not recognise the files. Going the opposite way, I also found that previous 'wfm' files that will load into PDflex, would not actually load into the TekScope Anywhere software.
Data file save options in 3 Series MDO |
{gallery} wfm file loading |
---|
PDflex data loaded from example wfm file |
Converted wfm file from TekScope Anywhere fails to load in PDflex |
Example wfm file from PDflex not recognised by TekScope Anywhere |
License Expired in TekScope Anywhere |
The license for TekScope Anywhere was only a 30 day trial, which has now run out, so any further investigation within this is now no longer possible. Cost of the software ranges between £733 to £6,550, so could be a sizeable investment.
Some brief communication with technical support from Tektronix and I learned that the header file format of the 'wfm' file has been changed from the older 4000 Series oscilloscopes that PDflex was utilised with. Tektronix could not offer any support to convert the files back to the older format and I was advised I could export the data as a 'csv' to load into Matlab, collect the data from the oscilloscope via the USB or LAN ports in a bin format, or utilise a 4 Series MSO that natively supports the 'wfm' format.
At this moment in time, neither of those options are an immediate choice for me, I am not a programmer and do not use Matlab, this is a roadtest on a 3 Series MDO, not 4 Series MSO, so that is also out. The only option that leaves me with is trying to extract the data in bin format via the USB. I do have a copy of LabView and with this being from National Instruments, I figured that it is more likely to put out a 'bin' file compatible with the PDflex software.
Computer connection
The 3 Series MDO has both LAN and USB connection options installed, initially I went with the USB connection. LabView requires the Tektronix instrument driver tkdpo4k driver installed that can be downloaded from the National Instruments website, this element of the installation was easily achieved and the driver duly appears below the two Agilent drivers already installed.
However, I failed to connect to the instrument via USB. LabView refused to see the instrument. This was tracked down to a bad USB installation within Windows Device Manager, even though no error is reported, the events tab of the driver shows the issue. At the moment, I have not been successful at resolving this issue. Re-installation of the driver does not resolve the problem.
I therefore moved over to the LAN connection, which was physically set up via a router. This still failed to resolve the connection issue between the computer and the oscilloscope.
The network seems to be set up correctly and both devices appear to connect to the router, but they will not talk.
At this point, I tried the OpenChoice Desktop software from Tektronix. This is a basic package to connect to the oscilloscope that is free from Tektronix. I could not get this to work with either USB or LAN connection with either the original RoadTest unit or the demo unit supplied, to complete the RoadTest with.
Within OpenChoice Desktop, the instruments are found with USB connections, I could never get the LAN connection to appear.
When selecting the USB connection though the software comes back with the error above.
I am convinced that this is an issue with my Windows 10 computer, either within Windows itself, or the driver download / install. Reading up on the 'USB driver requires further installation' error seems to point to an ultimate solution of a clean install of Windows 10.
The reality is that I will not get this done within the RoadTest timeframe, so I will move this to a longer term goal. Whilst I have carried out preparations for testing the cables, I do not want to carry out the high voltage testing, until I get the issues with the computer connection and PDflex software functionality resolved.
Update to computer connection 30/01/2020
So I have now managed to make a connection between the computer and the 3 Series MDO utilising the LAN port, connection via the USB still remains illusive to me. The break through was made utilising OpenChoice Desktop. I found an extra Conflict Manager program installed alongside OpenChoice Desktop that allowed some management of the visa drivers installed. By using this to turn off other drivers and forcing OpenChoice Desktop to use Tektronix visa, the connection appeared within the instrument selection.
With the connection via LAN established, two more extra programs, the Instrument Manager and a Talker Listener program allows the connection to be tested and basic commands sent to the oscilloscope to show that the connection is functional.
Whilst the auxiliary programs made the connection to the instrument, it was found that OpenChoice Desktop does still not like the connection. I have version 2.6 of the software downloaded from the Tektronix website, and as far as I know this is the latest version.
Looking through the list of supported instruments on the webpage and I could not actually see the MDO34 included in this list, so it doesn't look like is had been designed to work. Unfortunately this goes against the information within the 3 Series MDO brochure that seems to imply that the software would work.
Putting this discrepancy to one side, I successfully made a connection via LabView to the oscilloscope. The tkpdo4 driver for LabView contains several examples for connecting to the oscilloscope, the particular one in the block diagram below shows the program for a data collection from Channel 1.
The program successfully capture the data played back into the oscilloscope from the waveform generator as seen in the screenshot below.
From here I can now move on to expanding the LabView program to output the data into a 'bin' file that the PDflex software will hopefully be able to understand.
80 pF capacitive coupler preparations;
132 kV cable preparations;
This will also give me more time to source the correct tooling for the 132 kV cable that would benefit from having the semi-conductive coating removed at the connection end. This is the black ring of insulation seen in the cable section above. It is designed to suppress partial discharge and I found that it was bonded onto the XLPE insulation, instead of just peeling off like the first three layers did. This means it has to be cutoff using special tooling.
Trigger Modes
There is a further outstanding issue that I cannot look at until I have resolved the communication and / or file compatibility with PDflex. When capturing data for PDflex, a 'Window' trigger mode is generally used to limit the amount of data collected, otherwise the PDflex software may struggle to analyse the whole signal. This 'Window' trigger acts a bit like a pre-filter allowing the oscilloscope to trigger on a partial discharge event and limit the data collected across a time span. The following extract is from the Triggering Fundamentals paper from Tektronix, which I have attached to this blog.
Unfortunately, 'Window' trigger mode is not available on the 3 Series MDO. It does seem to be available for the 4000 series. I do not yet know how much of an issue this will be, I may be able to overcome it with one of the other trigger functions or it may be that the software can handle the amount of data from a general edge trigger.
Conclusion
This has been a disappointing aspect to the RoadTest, as it offered me a fantastic opportunity to carry out some partial discharge tests to learn more about the different kinds of faults that can occur. This kind of testing is usually restricted to universities and cable manufacturers with high voltage laboratories.
The lack of compatibility with older Tektronix native file versions has momentarily stopped the use of the analysis software, whilst the problems surrounding the instrument connections has prevented me from being able to attempt a work around. My preference would also have been to have been able to just utilise the oscilloscope in the test environment and not require it to be connected to a computer to collect the data, which does not look to be possible.
I could still do some tests with just the oscilloscope and attempt to pickup individual pulses, but this is a much more time-consuming methodology. I also have limited cable samples with which to work, once a fault is applied to a cable, it is non-reversible, so I can only collect base data on un-faulted cable samples once. I am therefore reluctant to start the tests.
I am reasonably convinced that the issues around the USB / LAN connectivity are down to my specific laptop / Windows 10 installation and are nothing to do with the Tektronix oscilloscope.
Top Comments