A viable vintage data aquisition system?



#11

This is a question out of pure curiosity.

In my job I regularly work on electronic data aquisition systems and I'm always wondering how experimental data (in a laboratory for example) was aquired and processed in the "HP-41 era".

After some googling I wonder if the following "HP-only" system would have been a viable solution:

- an HP-41CV/CX

- a Agilent HP 3468A Digital Multimeter

- an HP 82160A HP-IL module to connect to the 3468A

- an HP 82162A printer

- another HP 82160A HP-IL module to connect to the printer.


Using this system you could read the voltage samples from a sensor, convert and process them, store them temporarily and finally print them. In case you have a 41CX or a C/CV with time module it could even be done time triggered. Some kind of mass storage device would come in handy as well...

As I said, it's really just to sattisfy my interest in engineering history. Maybe there are a few guys here on the forum who did actually work on such laboratory systems in the late seventies or early eighties. I'd really be interested to know whether a system like the one outlined aboe was actually ever used professionally in a laboratory.

Thanks for your feedback in advance and best regards,
Timo

PS.:
And before you ask: No I do not own all of this equipment! However, I'd lie if I said that it is not tempting to try and get all the components together... ;)

Edited: 5 Mar 2010, 2:08 p.m.


#12

My first automated test equipment (ATE) system contact with a 41 used the HP3421A data-acquisition unit with HPIL. It was like a DMM with relay cards also to do some controlling, not just taking data. The company got a loaner 3421A from HP to evaluate for buying. Most of the engineers in the engineering lab had their own HP-41's, and my friend used his on this and took 20 minutes of his lunch time to write the program and get it going.

It was an instant hit, being so much less expensive and easier to program than the other millions of dollars of IEEE-488 equipment and controllers the company had. A requisition was put in for a set, but management wounldn't approve the 41, saying it was too easy for someone to put it in their pocket and walk off with it. Instead, they got an IBM PC with an IEEE-488 card, and three weeks after it came in, the two engineers responsible for setting it up were still trying to get the PC and IEEE-488 card to be friends.

A couple of years later, I was at another, much smaller company that was starting to need some ATE. I had my own 41cx by then (1986) and started using it with the HPIL-to-HPIB (IEEE-488) interface converter (HP82169A) to connect to equipment on the workbench to automate the repetitive jobs of taking certain readings through the DMM, and controlling signal generators, relay boxes, power supplies, and so on. In small but quick steps, the company got into a product line that required a lot of testing that was totally impractical to do by hand. Not realizing how quickly this situation was going to escalate, I set up automated testing, using my HP-41 as the controller. Especially back then in the late 80's, people would be absolutely stunned to see a large rack of instrumentation controlled by something that would fit in a pocket. It gradually got to where I didn't get to use my HP-41 much anymore. Production test operators were using it all day to test our product. In fact, the first two million dollars' worth were tested by this HP-41cx and a 20-page program.

Eventually we transfered the control of the production testing to a 68000-based HP series 9000 computer. Interestingly, it was not even twice as fast as the HP-41, because much of the time was spent giving filters time to settle and waiting for readings to come back from the equipment.

I still use the same 41cx every day, but it's pretty seldom that I use it to control anything on the workbench anymore. The 71 gets used more for that-- in fact, that's nearly the only thing I use the 71 for these days-- but that's still not much. My workbench control and data acquisition now is mostly handled by a home-made workbench computer about 5"x7"x2.5".


Edited: 5 Mar 2010, 2:33 p.m.


#13

THanks for your response Garth,

very interesting! I thought about the HP-41 only in terms of a device for laboratory level usage. But you are right I forgot about the HP-IL/HPIB converter which opens a much wider field of applications.

I'm reasonably familiar with GPIB since almost all of our test equipment offers a GPIB interface. As far as I know, HPIB and GPIB are very similar since GPIB is based on the HPIB. I'm not sure but would it be possible to control GPIB devices with the HP-IL/HPIB converter and a HP-41?

I'm just imagining a Keithley DMM being controlled by a pocket calculator which was produced about 20 years before the Keithley was even designed - and the looks of the colleagues...


#14

I have never found any differences between HPIB and GPIB. IEEE adopted HPIB as a standard and gave it the number IEEE-488. I used the 41 to control IEEE-488 instruments from HP, Wavetek, Cytec, and others, all at once. HPIL is basically a serial implementation of HPIB, and the interface converter was basically invisible to the 41. IOW, as far as the 41 was concerned, the instruments out on the IEEE-488 bus were really on HPIL, except that they weren't auto-addressed. My programs had to say "9 SELECT" for example to select the device at HPIB address 9.

To call it "viable" (your word) is a big understatement. In spite of the 41's lack of structured programming, I found it easier and quicker to devlop the programs on the 41 than I did later on the 68000-based HP-9000 computer running Rocky Mountain Basic 5.1. Remember I said my friend wrote that initial test set-up program in 20 minutes of his lunch. You couldn't do any better with a modern system with a drag-and-drop graphical test-writing interface.

I should mention that I have the Extended I/O module (built into my HPIL module so it doesn't take up an extra port). I also have the FSI164A which was virtually identical to the HP82164A HPIL-to-RS232 interface converter except that the FSI came with two RS-232 channels and optionally had up to 8, and could also be battery-powered. I wish I had gotten both of the HPIL-to-parallel interface converters when they were available. I can do it now through my home-made workbench computer by communicating with it through RS-232 and having it do that parallel part, but it's a "middleman." This is in fact how I use my parallel printer with the 41 and 71.

Edited: 5 Mar 2010, 4:45 p.m.


#15

Have you priced HPIB equipment recently? I just did to see if its a better choice for my project, and dang its expensive.

Dimitri

Edited: 6 Mar 2010, 2:00 a.m.


#16

Quote:
Have you priced HPIB equipment recently? I just did to see if its a better choice for my project, and dang its expensive.
If you buy the new equipment, yes, it's very expensive. You can get used equipment very inexpensively on the auction site. It has its advantages, depending on what you want to do. Most of it you can also use stand-alone if you want to, without a computer to control it, unlike a lot of things made strictly for the PC, whether to go inside it or have proprietary driver software that only runs under certain operating systems within a narrow range of release times. The product life of industrial buses is much longer than that of the fast-moving PC market, and that longevity gives valuable stability.

For the last ATE I did at that last place of work however, we were supposedly going to need seven sets. In that case, the "rack-and-stack" IEEE-488 approach would have been cost-prohibitive, so we pursued a route that took more development time but the time could easily be amortized over the seven sets since the per-set hardware cost would be a lot less. The hardware platform we (or should I say I, since I did 90% of the work on it) chose was STD bus. "STD," by the way, stands for "simple to design," not "standard." STD is far less expensive than something like VME or VXI. I used a 19"-wide card cage and off-the-shelf power supplies and STD-bus cards for CPU, signal generators, and analog I/O, and designed custom boards too for programmable filters, signal routing relay sets, programmable power supplies, programmable loads, and DMM front-end.

I had gotten my start in Forth on the HP-71 (which is not a very good Forth), but this project is where I really took off with Forth. I programmed the project in Forth and found that it made for very efficient use of programming time, leaving more time to debug hardware problems (which it also facilitated). During the development, relations turned sour with a couple of our foreign assembly plants, and I stopped with only two sets of the ATE. For only two, it might have been more cost-effective, at least when the development time was factored in, to go with the rack-and-stack IEEE-488 equipment. (Test fixtures had to be custom either way though.)


Edited: 6 Mar 2010, 3:24 a.m.


#17

Quote:
I programmed the project in Forth and found that it made for very efficient use of programming time, leaving more time to debug hardware problems (which it also facilitated).

Well I can admit I never worked with Forth or STD or even HPIB, I was wondering which one for a hobby programmer who does micro-controllers would you recommend for a modern HP-41 calculator?

Dimitri

Edited: 6 Mar 2010, 1:11 p.m.


#18

Quote:
I was wondering which one for a hobby programmer who does micro-controllers would you recommend for a modern HP-41 calculator?
Get a used HP3421A HPIL data-acquisition unit from the auction site, making sure it has the relay cards in it. You can use them to select inputs for the internal DMM and do some low-speed digital I/O with them too. This will take you a long way on a small budget. I recently got one, full, for $100 plus shipping. (That was the starting bid and no one else bid, IIRC.) I think both the user manual and the service manual are available in digital form on both this site and Warren Furlow's HP-41 site.
#19

Quote:
My first automated test equipment (ATE) system contact with a 41 used the HP3421A data-acquisition unit with HPIL. It was like a DMM with relay cards also to do some controlling, not just taking data. The company got a loaner 3421A from HP to evaluate for buying.
... It was an instant hit, being so much less expensive and easier to program than the other millions of dollars of IEEE-488 equipment and controllers the company had.

...

(The company later) got an IBM PC with an IEEE-488 card, and three weeks after it came in, the two engineers responsible for setting it up were still trying to get the PC and IEEE-488 card to be friends.


That story had certain things in common with my 'challenge' from 1993. Part of my task was to write a program for an HP3852A Data Acquisition Unit to receive measurements from a load cell. The other part as to write Visual Basic software for a PC to accept and process the data from the HP3852A.

After overcoming one hurdle by replacing the DOS-based GPIB card with one that supported Windows 3.1, we were able to send data to the PC in a 64-bit double-precision IEEE standard floating-point format that both devices supported. However, the data received appeared to be random noise. I thought at first that the problem might be incorrect parity.

It turned out to be "little-endian, big-endian": The Intel-based PC stored words in reversed byte order, while the Motorola-based(?) HP3852A stored words in their original representations. (Peter Norton's books termed this "backwords".)

Not seeing any option in the GPIB's data-transfer commands to account for this, I managed to handle it by writing a DLL routine in C language to perform the 'byte-swapping'. One minor misstep: I learned that a 'short int' is not necessarily one byte if a regular 'int' is two bytes. Execution of the byte-swapper using a pointer to a two-byte 'short int' was entertaining to watch on the PC, as waves of gibberish passed over the screen accompanied by frequent beeps, due to corruption of instructions. That cleared up after changing the swap variable to a 'char'.

-- KS


Edited: 11 Mar 2010, 3:23 a.m.


#20

Karl, this is why the IP protocol family defines a "network byte order" which is, btw, big endian. Writing networking software always has to deal with this. Many protocols and data formats use strings for numeric data to avoid these problems.

The C language specifies only that sizeof long >= sizeof int >= sizeof short int >= sizeof char. In most implementations, long is 4 bytes, int is 2 bytes on 16 bit compilers and 4 on 32 bit compilers, short int is 2 bytes and char is 1 byte. With the rise of unicode, 2 byte chars are possible but mostly a seperate data type (wchar) is defined.

Since Java runs on a virtual architecture, definitions are much more strict here (big endian, 8, 4, 2, 2 bytes for long, int, short and (unicode) char). To access a single byte a seperate data type byte exists.


Possibly Related Threads...
Thread Author Replies Views Last Post
  Sheet data importer for HP Prime Marek Russ 4 771 11-15-2013, 04:55 AM
Last Post: debrouxl
  PRIME: re-format the flash drive to recover the operating system Harold A Climer 2 688 11-06-2013, 12:22 AM
Last Post: Michael de Estrada
  Vintage HP 15C with bleeding LCD display Michael de Estrada 1 591 10-30-2013, 09:54 AM
Last Post: Jeff O.
  Entering,Saving,and Analysis /Fitting X Y Data on the Prime Harold A Climer 6 1,070 10-26-2013, 01:54 PM
Last Post: Tim Wessman
  HP PRIME: How to change the column headers and reset data Joseph Ec 5 888 10-18-2013, 02:26 PM
Last Post: Joseph Ec
  HP Prime data sharing Alberto Candel 5 863 10-06-2013, 07:49 PM
Last Post: Alberto Candel
  HP Prime Solving Nonlinear System of Equations for Complex Results Helge Gabert 11 1,775 09-30-2013, 03:44 AM
Last Post: From Hong Kong
  Another non-HP RPN vintage calculator joins the collection Michael de Estrada 2 805 07-23-2013, 04:10 PM
Last Post: Walter B
  Printing HP 9825 data Norman Pillsbury 3 699 06-01-2013, 10:08 PM
Last Post: David Ramsey
  WP-34s data exchange with PC over IR Marcel Samek 3 688 02-26-2013, 11:53 PM
Last Post: Marcel Samek

Forum Jump: