How can I interface the Propeller with an old device that outputs data via RS-232?
I've recently been handed an old (1989) spectrophotometer that appears to be in working condition when doing a single data point. However, when you want it to scan a sample, it communicates its data through a port using RS-232, a port that used to be hooked up to a printer. If possible, I would like to capture that data onto an SD card instead of a printer, and I thought the Propeller would be good for doing that.
I have no idea how to even approach this problem.
Would this be difficult to do or is this pretty straightforward?
Do I have to build sophisticated interfaces to deal with voltage differences, if any?
Are there OBEX objects that can be used for this kind of thing?
I guess what I need at this point is an outline of the steps needed to make this happen and/or examples of similar projects.
Many thanks,
Mark
I have no idea how to even approach this problem.
Would this be difficult to do or is this pretty straightforward?
Do I have to build sophisticated interfaces to deal with voltage differences, if any?
Are there OBEX objects that can be used for this kind of thing?
I guess what I need at this point is an outline of the steps needed to make this happen and/or examples of similar projects.
Many thanks,
Mark
Comments
Any of the serial I/O objects can be used to handle the data. FullDuplexSerial would be the most straightforward. Kye's SD card driver would be my choice to handle the SD card side of things.
You will have to write a simple program that initializes the two I/O drivers, opens up a file on a SD card, and copies all the received data to the SD card file. You'll need some way to signal to the program that you're done so it can close the file before quitting. You could use a second instance of FullDuplexSerial to communicate with your PC (the Propeller Serial Terminal object / program is good for this) to display debug information, enter file names, and simple one letter commands like to close the file.
You may also find SerPlug of some use, see my .sig
Do you have a Propeller Professional Development Board yet, If so, you may already have everything you need on hand for this.
OBC
Thanks, Mike. And thanks to Bill and Jeff, too. This is excellent news!
Old? 1989 is not old. I look after a few that are between 5 and 10 years older than that. The propeller has been a blessing in dealing with them. As Mike and Bill said connecting to them is pretty straight forward, usually only requiring dealing with straight ascii text. If you don't mind me asking, what make and model is it.
While you could do this with a propeller, there are pre-built datalogging dongles out there that are already built and programmed for you. Here's one that's $25 all assembled and ready to go: http://www.sparkfun.com/products/9530
kwinn,
it's a Beckman DU 64. So if you've got any tips on how to work it with the Propeller, that would be awesome!
To localroger,
I think data only needs to flow one way, but I'm not sure how the system works in detail yet. I guess I need to look over the manuals in more detail. So if the printer was ever supposed to send data or status signals to the spectrophotometer for whatever reason, I'm guessing the dongle thing wouldn't work? or would it?
many thanks, guys, for helping raise my spirits on this one. I always like the idea of bringing machines back from the dead (= dumpster). :-)
If you get stuck there use to be Serial Break Out boxes (you can buy them surplus on e-Bay) for breaking down the signals. The basic ones are just LEDs and resistors. The more advanced ones have a uprocessor and help to ID the data, do the handshaking, send dummy data etc. But you can do all of this with a terminal emulator, even X-ON/Off should b via the Scroll Lock or a ctrl sequence.
I'd suggest the following;
- Install a terminal emulator on a PC (the propeller one may be fine to start with)
- Short pins 2&3 of the serial connector (called a loop back test)
- Check to see what you type appears back on the emulator screen
- Then make a cable with TX,RX and Gnd, connect to the opposite end of the device you are connecting to (TX to RX, RX to TX)
- Try with 4800 baud 8 bit no parity Xon/Xoff. Cycle online/offline/print or whatever for the device you are using to try to make it spit something.
- If that doesn't work retry with 9600 then 19200, then 1200. Reboot the PC after each test and retry the loopback first. I've spent lifetimes troublshooting a hung up serial port!
- If you don't get even garbage appear it's probably using hardware handshaking. If so you'll have to play with full modem cables (google).
I have had problems where PC's don't push the RS232 levels properly, so you may also want to consider that.
Once you have the emulator working with whatever cabling you need, then look at connecting to a Propeller using a MAX232, and then you can look at what serial object will work. If you have to do HW handshaking, if you don't care about flow control then you can hard tie the lines via the MAX 232 TTL side tie to VCC or GND to set the line, or soft tie it via the MAX 232 TTL lines to Prop pins.
Good luck :-)
http://en.wikipedia.org/wiki/RS232
Also was the Serial port for a MODEM or Mainframe or Printer? this will give you clues on how to connect. If it's a modem then it'll need HW flow control. If it's to a computer then it'll likely only be SW flow control. A printer could be either (depending on the vendor). Though from the late 80's onwards most printers were SW flow control only.
I'm afraid I can't help you much with the specifics of that one. Most of my work has been with the ARL, Baird, and TJA spectrometers. With schematics and a service manual I could be of more help. After all a spectrometer is a spectrometer is a spectrometer. In spite of what the sales brochures say there are far more similarities than differences between products of any particular generation.
There is quite a bit of information available if you google “Beckman DU-64”. It looks like commands are entered on the instrument panel and results are printed on a parallel printer. Should not be much of a problem to connect a prop in place of the printer. It may not be much more difficult to enter commands from the prop, but that would depend on how the front panel is interfaced.
Perhaps you could contact Beckman Coulter for a service manual. Someone I worked with years ago went to work for them so I will do the same.
zoopy,
thanks for all the tips on fathoming the inner workings of this device.
The unit also has a printer port, which was apparently hooked up to an Epson LX-810.
Luckily, I was able to find out something from its manual labelled "RS-232 Interface Accessory".
What's sticking out of the RS-232 module (which is installed in the spectrophotometer) appears to be a DB-25 male.
Apparently by using this accessory, the spectrophotometer can "communicate with a computer, terminal or printer. It can both send and receive data from remote locations..."
The manual says this spectrophotometer is configured as a DTE.
It says I have the option of choosing either 7 or 8 bit data operation. But I'm not sure how to give it those commands or what the default might be.
It says I can select different baud rates. Again, I'm not sure how that's done. Must be somewhere in the manual, though.
It says that "when parity is enabled the word length is increased by one bit."
The manual says the unit "always ignores the Clear to Send signal. Therefore, a remote device should always be ready to receive data." It also says, "The DU-60 also always holds the Request to Send high, indicating to the DCE that the DU-60 is always ready to receive data," but I'm not sure if they're talking about all DU 60 series or just the DU-60 itself, which is a particular unit in the 60 series. The manual appears to use DU-60 as a generic term for all 60 series, I think.
I have no idea what this means, but it says to send output data to terminals, computers, or printers, the unit uses a format described as follows:
<format B> : : = <alphanumerics><crlf> <alphanumerics> : : = Any non-control ACII characters. <crlf> : : = Carriage return and line feed.
Apparently this format B can be selected by pushing some buttons on its control panel.
The manual says that the "input side of the RS-232 interface has been implemented with XON/XOFF controls."
It also says "output can be controlled using XON and XOFF."
"During a scan, data are automatically output to the remote device..."
"Scan data are buffered by the instrument before output to the RS-232 at the rate determined by the baud rate. If the buffer fills with data, the scan speed will decrease automatically, so that no data points are lost..."
"The ASCII code for XON is hexadecimal 11 or decimal 17. The ASCII code for XOFF is hexadecimal 13 or decimal 19."
"On the output side, the DU-60 uses a 128-character buffer. The data to be output to the RS-232 port are first put in this buffer. Then, the DU-60 starts to output one character at a time. If the remote device wishes to indicate to the DU-60 to stop transmitting, the remote device must send an XOFF. When the remote device is ready to accept more data, the user must send an XON. When the DU-60 output buffer is full, the instrument will wait until characters are removed by the remote device before adding to the buffer. No data will be lost."
I also read the following:
Pin.....Circuit.....Direction..... Function
1..........AA .....none ..... Protective Ground
7 ..... .....AB ..... none ..... Signal Ground
2 ..... ..... BA .....TO DCE ..... Transmit data (TxD). The DTE holds this signal. Marking during internals between characters.
3 ..........BB .....FROM DCE .....Receive Data (RxD). The DCE holds this signal. Marking during internals between characters.
4 ..... .....CA .....TO DCE .....Request to Send. An ON condition informs the DCE that the DTE is ready to receive data.
5 ..........CB .....FROM DCE .....Clear to Send. An ON condition informs the DTE that the DCE is ready to receive data.
6 ..........CC .....FROM DCE .....Data Set Ready. An ON condition informs the DTE that the DCE is ready.
20 ..........CD .....TO DCE .....Data Terminal Ready. An ON condition informs the DCE that the DTE is ready.
Okay, so that's what I'm starting with. I sure hope I typed all of that correctly. Based on the above, I'm guessing the MAX3232 approach suggested by Mike Green might be best because it would allow the Propeller to talk back to the unit. I'm not sure if any of above information addresses zoopy's questions about handshaking and so forth. I don't know enough about computers and data transmission to tell what sort of flow control is implied by all of the above.
Any further suggestions will be vastly appreciated,
thanks again,
Mark
kwinn,
at this point, I'm not totally sure of anything, but it has ports for both a printer and one labelled RS-232, which appears to be a Beckman accessory board that was added to the device and for which a separate mini manual was provided .
The printer port was apparently hooked up to an Epson LX-810.
OMG, if you can get a Beckman service manual for this thing, that would be insanely fantastic. Because this thing was headed for the dumpster, my original intention was to salvage parts off of it, but it seems to pass all of its self diagnostics. I'm hoping all it needs is a way to record data, and then I can actually use it. The people who chucked it were also chucking perfectly good microscopes, etc. so it's very possible it is fully functional.
thanks again,
:-)
Looks like you have a couple of different options. From what you sent it appears to have the ability to do byte wide TTL Centronics, RS232 with either wired or SW flow control. You just have to work out how it's configured.
If it was connected to an EPSON LX80. These were CENTRONICS printer ports, just goole CENTRONICS. They are easy to connect to. Though you may have to tie READY and PAPER OUT to get data flow. It's a TTL level byte wide interface with a clock. You could either just latch this into the PROP or do it via a shift register. Quite easy to use.
http://en.wikipedia.org/wiki/Centronics_printer_port
http://pinouts.ru/ParallelPorts/Centronics_pinout.shtml
http://www.lammertbies.nl/comm/cable/parallel.html
Or as you've found RS232. From what you've posted looks like you can set it up, but you just need to work out how to do it. I'd suggest 9600 8bit no parity with software handshaking (Xon/Xoff). Then pull the data into a buffer. You'd already got the format which is great - it reduces the guess work. Though as mentioned I'd look at sending it to a PC using an RS232 emulator first. That way you know that you are getting data and what you have to do.
If this is your machine and this is going to be a permanent hack. Then one opportunity you have is to build this inside the machine itself. Due to it's vintage it'll be TTL levels. Just look on the logic board for any TTL devices, get the pin out and measure the levels. There is bound to be a 7404 of some kind (LS, F, HC, etc) then just pin 7 for ground and pin 14 for VCC. It'll likely have dedicated RS232 chips of some kind 1488/89 or newer. Just look for the pin out and use IC clips to connect to the TTL side. This will save you using a MAX232 on the Prop side. Then just interface to the TTL side with a 1K resistor. You could then build a permanent board to go into the device that would have a +3.3V reg, the Prop & supporting circuitry and SD card. For this kind of hack my best friend in a logic probe. You set the machine to print and look at where the data goes! Alternatively you may be able to do this with one of the PROP logic analyzers and some resistors (to protect the prop).
http://pdf1.alldatasheet.com/datasheet-pdf/view/8396/NSC/DS1488.html
http://pdf1.alldatasheet.com/datasheet-pdf/view/8397/NSC/DS1489.html
Sounds like fun :-)
The XON/XOFF protocol is straight forward, and zoopydogsit's suggested baud rate and settings are a good starting point. The most common setting I encountered on instruments was 9600 baud, 8 data bits, no parity, and one stop bit.
The “format B” description simply means the instrument sends out a string of alphanumeric characters followed by a carriage return and line feed. That would probably be a table of wavelength and intensity numbers if printed out. In normal use the computer connected to the instrument would have software that parsed the output, performed some calculations, and provided a report and/or graph as output.
If you end up trying to make a virtual parallel printer of a Propeller, some info presented in this recent HaD entry may prove helpful.
zoopy,
Thanks for mapping out all of these options and providing an expert perspective on peering under the hood of this thing. I'm sure I'm not the only one on the forum who is going to find this information very useful!
Yes, even though I've never worked with communications of this sort, the idea of getting control of a device is too tempting a prospect to ignore. Maybe a general Prop-based RS-232 data-reader would make a nice little kit for us dumpster divers to buy.
It's great to know there are multiple options for bringing this zombie back to life. Many thanks for casting a little of your brilliance from yon Outer Darkness. :-)
"You guys are wonderful," he says, tears rolling down his cheeks and dripping into the cuvette, "Hey, I wonder what the transmission of tears is at 280 nanometers?"
IIRC someone on the forum makes a small board with an RS232 driver chip and DB9 connector to do the conversion from the prop 0-3.3V levels to the +-12V RS232 levels. Add that to a protoboard or one of the other boards available and you are good to go.
Wulfden (spelling?) also makes a transistor based version.
Very interesting. I'm not familiar with the Mem+ and Morpheus products, so could this SerPlug work directly with a Propeller Protoboard? Do I have to use a PropPlug to communicate with SerPlug or could I use any Prop pins I want for communication? How might the DB9 connector adapt to the 25 pin connector on my spectrophotometer? Sorry to ask so many questions, but if it's directly compatible with something like a Prop Protoboard, it would definitely be a bargain.
thanks!
Mark
I found out these settings are performed on the RS-232 card via DIP switches. So, thankfully, I don't need to do something weird. I just need to deal with the dust bunnies inside.
If memory serves me the SerPlug was designed to work with the prop. Not sure what connector is on the end but worst case you should be able to cut the connector off the cable and connect the wires to the propeller board. No PropPlug required for the propeller to instrument communications but it will be required to program the prop.
You would need a DB9 to DB25 cable or adapter. That should be available at most computer stores. If it turns out the connector on the instrument does not have a standard pinout you may have to make a cable. Not too hard, I have done so often.
If you have a schematic or signal pinout for the DB25 you can post I can take a look at it tomorrow and tell you what you need. I would also need to know if the connector is male or female.
I did this for a 25-year old cnc and found it.
keep the questions coming
best regards
Stefan
kwinn,
I had the DU64 run its own diagnostic tests again tonight and it tells me everything passes, and it did appear that its two lamps lit up inside, so at the very least the machine thinks it is sane. I think I will use a Propeller-based display to tell me whether the machine can do more, though, since I'm afraid of something maybe going wrong with the DU64 and blowing up my PC via a direct connection.
What's sticking out of the DU64 appears to be a DB25 male. The only pinout I'm aware of is something I read in the manual:
Pin.....Circuit.....Direction..... Function
1..........AA .....none ..... Protective Ground
7 ..... .....AB ..... none ..... Signal Ground
2 ..... ..... BA .....TO DCE ..... Transmit data (TxD). The DTE holds this signal. Marking during internals between characters.
3 ..........BB .....FROM DCE .....Receive Data (RxD). The DCE holds this signal. Marking during internals between characters.
4 ..... .....CA .....TO DCE .....Request to Send. An ON condition informs the DCE that the DTE is ready to receive data.
5 ..........CB .....FROM DCE .....Clear to Send. An ON condition informs the DTE that the DCE is ready to receive data.
6 ..........CC .....FROM DCE .....Data Set Ready. An ON condition informs the DTE that the DCE is ready.
20 ..........CD .....TO DCE .....Data Terminal Ready. An ON condition informs the DCE that the DTE is ready.
Do you happen to know if that's standard for cables? It's been a long time, but I seem to recall, through the cobwebs of my aging memory, putting together a cable or two.
Just for laughs, I tried hooking up the antediluvian Epson printer that I also rescued along with the machine. The Epson didn't give a printout but it's not surprising considering how awful it looks.
The only thing the DU64 is missing is a cuvette holder, but I will probably have to custom kluge something for my purposes anyway.
Stefan,
luckily I was able to rescue most of the manuals that came with the device, so at least I've got something to work with.
Thanks, gentlemen, for your assistance and encouragement. When faced with bringing dead equipment back to life, such insights and experienced perspectives are priceless.
I think my next approach with this project will be how to utilize the MAX3232. :-)
Pin – Function
2 - Transmit data (TxD) from the instrument to the prop
3 - Receive Data (RxD) from the prop to the instrument
7 – Ground
4 – Request to send jumpered
5 – to clear to send
6 – Data set ready jumpered
20 – to data terminal ready
For some equipment pin 8 was also included so pins 6, 8, and 20 were jumpered together.
kwinn,
hey, a 3 wire cable sounds like something I might be able to handle without electrocuting myself. Thanks again for the tip! :-)