• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

RS-232 programming...help me bring my equipment into the digital era

J

jagec

Lifer
Hi,
I need some advice. I currently work in a lab that does a lot of HPLC. We have a couple of computerized machines, and I recently spent a day getting an old Pharmacia LCC-501 plus up and running. None of this part really matters.

The point is, the old machine doesn't have a computer. Instead, it has a plotter, which plots two parameters of interest, taking an analog signal from 0-1V as input for each. The main controller for the system also has a serial port, which was intended for use with a computer system that was sold separately. When new, this machine had the option of interfacing to an IBM XT computer running OS2/Warp, which could record data from the system and control all of the pumps and valves as well. The software is pretty much inaccessible to me now, as is any computer system that old. I have no idea where I could find it. I have, however, done some programming in Labview, which is essentially a VB-like package for scientific equipment.

My question is, would it be at all reasonable to try and control this thing in Labview via the serial port, without much information about the protocol, and figure it out by trial-and-error, or should I just suck it up, stick an A->D converter in parallel with the plotter and passively record those two values directly? How "standard" are serial port standards?

What I know:
Full duplex asynchronous (duh)
9600 baud, 1 stop bit, no parity (useful)
It sends packets of varying lengths, with a 63 byte maximum length. Packets have an 8-bit checksum.
Acknowledgment required except for ACK/NAK
I can't find any information on the web besides that. So I can listen to it, but I would still need to decipher the output

I do have some manuals that came with it.

Basically, I would love to run this thing 100% from the computer, but all that I really need is a digital plot of two values which are currently output on paper by the plotter. Thoughts/questions/comments/disparaging remarks about my intelligence and personal hygiene?
 
Plug it into hyperterm or so ( better if you can find one that will print the control codes, so you can see what's going on) and see what happens... play with it a bit. maybe move the plotter head manually, and see what changes, to see if you can reverse engineer what's going on.

Once (if) you can get that going, then it should be cake to make a program for it.


I don't have much experience with antique plotters, but there's a chance there's a standardized output from them.

Worst case scenario, you can stick a $2 AVR on there, have it read the voltages directly and report them over serial (or USB).
 
Sounds like a huge pain in the ass. I couldn't imagine trying to blindly parse data and figuring it out especially if the tangible benefits are minimal. It's do-able, I guess...if the data stream is always of the same format. For devices that I have developed against, depending on the setting of the device, the format of the data stream can change so one parsing algorithm may not work. Also, what do you mean by "how standard is serial standards"?
 
bas1c said:
Sounds like a huge pain in the ass. I couldn't imagine trying to blindly parse data and figuring it out especially if the tangible benefits are minimal. It's do-able, I guess...if the data stream is always of the same format. For devices that I have developed against, depending on the setting of the device, the format of the data stream can change so one parsing algorithm may not work. Also, what do you mean by "how standard is serial standards"?
Click to expand...

Essentially you answered it by saying that the setting of the device might affect the format of the data stream. Guess I'll go with the AVR solution...sounds like it will work with my current setup.
 
If it is old enough to use an XT for interfacing then that means the code it is using internally is stored in eprom or prom. I would open up the controller and take a look. Usually they socketed those which means you could pull the chip, use just about any eprom programmer , even the cheap $20 ones to dump the code.
Once you have the code you can probably figure out all the functions. The processor in the controller is probably an 8051 or z80. Very easy code to follow.
 
without knowing the codes, you do not have a snowbal chance.

With the codes; you can try to push a code down one at a time. The problme is that it may require multiple codes to perform a single visible action.

It would be a better waste of your time to trwl the internet to find out what the protocols are.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top