Mike> I am in a situation of being asked to make a logger for an Mike> autoclave I have no physical access to. I am working on a more Mike> general logger, which I can parse data with, but they are asking Mike> me to read data from an rs232c port which I believe is meant for a Mike> printer. I need to log what I have been told is ascii data...but Mike> I am not sure. I have been requesting an example of the data Mike> somehow but am not able to access it. (can you say middle man) Mike> Any thoughts on how I should approach it would be really Mike> helpful. I apologize if this message sounds dumb.
Russ> Here are some random ideas: Russ> Russ> a) tell them you can't created a logger without physical access; Russ> Russ> b) if them won't give you physical access, tell them you already have a Russ> logger, but that they can't have physical access to it (for arbitrary Russ> and capricious reasons); Russ> Russ> c) when you do have access, write a program that opens/configures the Russ> serial port and timestamps the data it receives and dumps that to a log Russ> file or database or something. I did this in C once upon a time, and I Russ> have seen similar things in Python (or pick-your-favorite-language). Yes, What Russell said... let me add this though: Since this is an RS232 serial port (the most nonstandard standard ever invented <g>), they will have to give you complete documentation on the pinout and handshaking protocol (if any) implemented on that port. Also, is there already a device attached to the port (you hinted at a printer)? If so,, you can just tap in by building a Tee to monitor the outbound data and log everything you see. You will probably want to know the printer brand and model the autoclave is designed to print to so you can reverse out the page protocols and "re-paint" the data into fields properly (even if there are only horizontal tabs, form feeds, CR, LF, and vertical tabs to deal with and no escape sequences, it can still be useful to know this). If they are painting graphical data to the printer, it could be a bigger project to interpret the data then they may be thinking as you will have to reverse-out the graphic protocol in use if they want to end up with data fields. Hopefully it is just sending textual stuff to the printer port! I had to do this a long time ago for a large security system that only logged events to a specific printer and they needed to take the log data (from the printer stream) and do automatic stuff around the secure plant in response to security events that were only seen (at that time) by physically reading a piece of paper from the printer (did I mention this was a long time ago?). You have to sync your parsing on form-feeds or something like that to get your data framed properly. Of course, there is the chance the port is not for a printer but is a control/monitoring port for the machine with some defined protocol, in which case you will need the detailed documentation for that protocol and will need to build some test software to check your protocol handling before implementing the final version. If you can't get physical access, perhaps you can go with a rs232 to tcp/ip device that you can gain access to remotely? Or maybe a wireless version of this so you can play with it while sitting in their parking lot? And the obvious stuff of course which you I'm sure already know: you will also need them to provide you with the usual baud, start bits, stop bits, data bits, parity info (none, odd, even, mark, or space). Also, you may want them to verify the actual voltage levels being used in the RS232 for you... some designs cheat those output levels which might cause you problems if you assume true rs232 levels. By the time you ask them all these technical questions you may find they will grant you special access so you can do the project properly. :-) Doug
_______________________________________________ dorkbotpdx-blabber mailing list [email protected] http://music.columbia.edu/mailman/listinfo/dorkbotpdx-blabber
