| Products > Test Equipment |
| Some old school instruments showing how it's done (HP 3325A and Fluke 8506a) |
| << < (51/91) > >> |
| joeqsmith:
I have two very old National Instruments Ethernet GPIB controllers (both damaged during that same storm that I believe took our my PROM programmer). These are no longer supported by NI and I had to reverse engineer the protocol then write my own software to control them. I tried a few more tests with the high speed but no luck. It's always coming up with the same error. This is looking at the newer code that I described. In the saturation picture, the blue is looking at the time from reading to reading. ASRate is the average. The wide swing is due to how I buffer the streamed data. The white is the input signal. Driving the meter deep into saturation. The second plot is looking at the in-range signal. I wonder if there was just too much overhead sending data to the serial port. Maybe the GPIB and parallel ports were more efficient for coding the firmware. Oh well. |
| garrettm:
--- Quote from: SilverSolder on February 11, 2021, 04:36:13 am --- What exactly is your GPIB adapter, @garretm? I have a National Instruments GPIB-232CT-A here, which I actually quite like - but I have never attempted anything particularly high speed with it. --- End quote --- I'm using an IOGear Serial488A Bus Converter I picked up for $15. It works much better with modern IEEE488.2 GPIB instruments that use standard GPIB terminations (EOS and EOI) rather than custom ASCII termination characters that the 8505/6A was designed to use (presumably for speeding up transactions). The 8500 series' custom termination characters are what break functionality with basic GPIB controllers as I've discussed previously. These older instruments require a full function GPIB controller to properly control HS data flow. Here's an interesting read regarding GPIB termination characters and binary data for newer instruments. https://forums.ni.com/t5/Instrument-Control-GPIB-Serial/Default-GPIB-termination-character/td-p/242545?profile.language=en And here's a programming tutorial for SCPI based GPIB instruments. https://web.archive.org/web/20070320000922/https://www.few.vu.nl/~elec/products/download/GpibProgTut.pdf |
| garrettm:
--- Quote from: joeqsmith on February 11, 2021, 04:51:02 am ---I have two very old National Instruments Ethernet GPIB controllers (both damaged during that same storm that I believe took our my PROM programmer). These are no longer supported by NI and I had to reverse engineer the protocol then write my own software to control them. I tried a few more tests with the high speed but no luck. It's always coming up with the same error. This is looking at the newer code that I described. In the saturation picture, the blue is looking at the time from reading to reading. ASRate is the average. The wide swing is due to how I buffer the streamed data. The white is the input signal. Driving the meter deep into saturation. The second plot is looking at the in-range signal. I wonder if there was just too much overhead sending data to the serial port. Maybe the GPIB and parallel ports were more efficient for coding the firmware. Oh well. --- End quote --- I'm sad to hear the ! toggle / ext. trigger hacks didn't pan out. It would have been nice to one-up Fluke and have HS readings with the serial interface. I have a spare GPIB controller if you want it. The lid needs some tape to stay closed, but it works. I'd let it go for 8 bucks + shipping. FedEx Smart Post might be the cheapest method, but maybe one of the Post Office Priority options could be cheaper. But for idle curiosity, maybe it’s not worth it? Did you write the software you've been showing screen shots of? I quite like it. It’s interesting to see the large spikes in latency from buffering. What is the frequency of the sinusoidal input signal? Digitizer operation looks promising if one can get the HS sampling mode to work. How are you decoding the 5 to 6 byte binary data (for 5.5/6.5 and 7.5 digit readings, respectively). Looks like it might be a little more complicated to convert to a double. I'll give it a go tomorrow and upload a snippet if anyone is interested. |
| joeqsmith:
--- Quote from: garrettm on February 11, 2021, 06:20:40 am ---I'm sad to hear the ! toggle / ext. trigger hacks didn't pan out. It would have been nice to one-up Fluke and have HS readings with the serial interface. I have a spare GPIB controller if you want it. The lid needs some tape to stay closed, but it works. I'd let it go for 8 bucks + shipping. FedEx Smart Post might be the cheapest method, but maybe one of the Post Office Priority options could be cheaper. But for idle curiosity, maybe it’s not worth it? Did you write the software you've been showing screen shots of? I quite like it. It’s interesting to see the large spikes in latency from buffering. What is the frequency of the sinusoidal input signal? Digitizer operation looks promising if one can get the HS sampling mode to work. How are you decoding the 5 to 6 byte binary data (for 5.5/6.5 and 7.5 digit readings, respectively). Looks like it might be a little more complicated to convert to a double. I'll give it a go tomorrow and upload a snippet if anyone is interested. --- End quote --- Thank you very much for the offer. I'm just using the meter as a source of entertainment and don't really have a need for it. Saving it from the dumpster but most likely it will become a dust collector. It's a bit of history with it's thermal technique and high resolution. Yes, I wrote that software. I use LabView, which is now free for home use. It's a very good engineering tool. I adopted it back in the 90s as it makes writing software like this a simple task and has saved me a lot of time over the years. I believe the 5-byte is pretty much the same as the 3-byte. Maybe there's a IEEE standard for these two formats. 2's comp is done already, I'm guessing to help speed things up and the exponent isn't fixed like the 3-byte, so you will need to multiply by 10^X. There's no error checking built into the 5-byte. In my case, I limit the range to +/- 10e12 for any reading sent from the meter. If you see a reading like 0.45423E225, it may not be a correct answer and is out of sync with the data stream. :-DD Looking at the plot I posted, we can see the sample rate is 25ms and there are 3100 samples. 0.025 * 3100 = 78 seconds. There are about 7.5 cycles, so 78 / 7.5 is about 10 seconds per cycle or 1 / 10 = 0.1Hz. Sampling at 40Hz, it's pretty limited. I think that's on par with my UNI-T UT181A after I made use of the bar graph data. In the other graph, I had started out at 7ish Hz and then slowed it down. |
| dietert1:
I also gave up on the '!' for the time being, since it did not run reliably. After two hours or so (with roughly a million of readings) i would find 0D and 0A in the binary data where it doesn't belong. It seems correlated with blocking operations on the Windows host. Seems like the instruments go to another mode on output overrun. While waiting for the AB-25 to arrive, i am using our two Flukes with "S2", at about 10 readouts per second and calculating averages every 320 samples. There is enough noise in those data to get reasonable averages. So this gives me two 8 digit DVMs. Sounds strange? These instruments can be used for serious work. There is some learning though. Since i am trying to characterize a low noise reference at levels of 1 uV and below, it's important to run the instruments at the proper operating temperature. The internal references are tuned for running the instrument at 23 °C ambient, whatever that means. I mean if you stack instruments, each one will have a different temperature. And our Lab has 19 to 20 °C during working hours and 17 °C during the night. Currently i am trying to cover the instruments to protect them from air drafts and at the same time rise their operation temperature to a better working point. Meanwhile i found a setup where one instrument exhibits a positive and the other one a negative TC - of similar magnitudes, so the averages are good for 0.1 uV during working hours. But it's still experimental. If i want to use it in summer, we need a cabinet with temperature control. Regards, Dieter |
| Navigation |
| Message Index |
| Next page |
| Previous page |