 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / General / September 2004listen to LPT1
Hello, I have a scientific machines that either outputs the results to a dot matrix printer or to the computer screen. I would like to capture the data to a file instead of having it appear on the screen. How do I monitor the LPT1 port and write the incoming information to a file. Thank you, Brandon Campbell  Signature-------------------------------------------- Database Administrator bkc5 AT CDC dot GOV > Hello, > > I have a scientific machines that either outputs the results to a dot matrix > printer or to the computer screen. I would like to capture the data to a file > instead of having it appear on the screen. How do I monitor the LPT1 port and > write the incoming information to a file. How do you get the data to the screen? I'm assuming there must be a program to do so? If so can you simply start it with redirection? IE, what does c:> yourmonitorproggiename >datafile.dat do? Hi, This is a non-trivial problem. The printer port on a PC is designed to be used for output, not input. Some printer ports support bi-directional operation, but you still would need to emulate the handshaking that is done by a printer, after placing the port into a mode where it can be used for input. You also would have to wire up a non-standard cable to handle the job. None of this is impossible, just not straight forward. I'd suggest that you might get a copy of Jan Axelson's book, Parallel Port Complete (I have a link to it on my homepage) for the details that would be involve. She also has information on her web site about bi-directional parallel port IO, but I doubt that there really is enough detail for you to proceed from that alone. A much easier solution would be to purchase a parallel to serial adapter (www.bb-elec.com), and using MSComm (and some code) to write the data to a file. The adapter would handle the handshaking problems for you, and all that you would have to do is to deal with the serial data. Dick SignatureRichard Grier (Microsoft Visual Basic MVP) See www.hardandsoftware.net for contact information. Author of Visual Basic Programmer's Guide to Serial Communications, 4th Edition ISBN 1-890422-28-2 (391 pages) published July 2004. Let me understand this. This scientific machine send its data to a printer or to a screen. You mention "computer" screen. Are you refering to the screen on a seperate computer or on the scientific machine it self. If it is on a seperate computer, how does the scientific machine get its data to the computer? Regardless if the screen is on the machine itself or not, Dick has given you the best answer. Get the parallel to serial convertor, and hook that up to the serial port of the PC. I had to do this years back, but the signal did not originate from a parallel port, rather from a mainframe connection, coax something or other. We got a convertor that converted the mainframe signal to serial, connected to the serial port, used MSCOMM and it worked beautifully. Good luck! Saga > Hello, > [quoted text clipped - 6 lines] > > Brandon Campbell > Let me understand this. This scientific machine send its data to > a printer or to a screen. You mention "computer" screen. Are [quoted text clipped - 3 lines] > If it is on a seperate computer, how does the scientific machine > get its data to the computer? ...Good point--I was assuming that he meant that somehow he could get the output to the PC screen--but on reflection, that's probably <not> the case--in that case, I also agree w/ the parallel-serial converter. Black Box is one source I've used in the past successfully, although they do tend to be pricey. I second the recommendation with Black Box, that's where we bought the converter I mentioned earlier. I also remembered <g> it was a 3270 protocol to RS232 converter. Saga > > Let me understand this. This scientific machine send its data to > > a printer or to a screen. You mention "computer" screen. Are [quoted text clipped - 9 lines] > Black Box is one source I've used in the past successfully, although > they do tend to be pricey. Saga, I am currently getting more information from the lab. I only know that the laboratorians unplug the machine from the computer and plug it into a dot matrix printer. It definately suggests that the machine has already decoded the information and using the computer and the printer as an output devices. I would think that the parallel to serial converter would be a good step, but I am not sure if the lab is willing to go that far. Currently, they are use MS Dos 6 as the OS. I would like them to update their computer to a 2000 box. Thank you for your suggestions. > I second the recommendation with Black Box, that's where we bought the > converter I mentioned earlier. I also remembered <g> it was a 3270 [quoted text clipped - 16 lines] > > Black Box is one source I've used in the past successfully, although > > they do tend to be pricey. > I only know that the > laboratorians unplug the machine from the computer and plug it into a dot > matrix printer so... it outputs some data to the computer's *screen* while plugged into the computer, and some further data to the dot matrix printer while plugged into that; and you want it to output *all* the data to a file, while still plugged into the computer? Is that the case? Bonj, From what I understand from the scientists, it is a one shot deal. Either they output the results to the computer, or they are output to the printer. As you may guess, the the printer wins 99.9 percent of the time. The output to the computer is only displayed on the screen. I would like to capture the incoming buffer to a file. In either case, the results have to be typed into another computer for the results to be used thus introducing human error. Thank you for your suggestions. Brandon > > I only know that the > > laboratorians unplug the machine from the computer and plug it into a dot [quoted text clipped - 5 lines] > into the computer? > Is that the case? Ah, OK. I'd probably go with what Dick Grier says then > Bonj, > [quoted text clipped - 18 lines] > > into the computer? > > Is that the case? Here is the proverbial "wrench in the works". I spoke with the lab and it turns out that the computer they use for displaying the results contains a program that is used for another machine. The computer is only running MS DOS 6. They are not willing to upgrade the DOS computer to an NT or 2K? box. I guess the program would have to be written in C. I did get some clarification on the process. It turns out that when the printer is connected to the machine, the operator pushes a button on the machine to send the results to the printer. To use the computer, the operator types a command at the prompt to get the machine to send the results. I guess this C program should capture the buffer. What do you all think? Thank you, Brandon > Ah, OK. I'd probably go with what Dick Grier says then > [quoted text clipped - 20 lines] > > > into the computer? > > > Is that the case? How is the machine connected to the PC? Is it also through thte parallel port? If it is using DOS, then I would wager that it is connected to either the parallel or serial port. If you are going to go the C way with DOS (I guess VB6 is out of the question here<g>) you'll have to write an interrupt handler for IRQ 3, 4 or 7 depending on which port the machine is connected (COM2, COM1 or LPT1 IIRC, since this is going back decades!). Then just let the program sit tight and when something comes in from the port, the Int.Handlers kicks in and processes the data accordingly. Note that this is a basic description and does not reflect the complexity of the issue at hand. I would start looking for C resources oriented specifically at int. handlers and data capture from these ports. Best of luck on this project!!! Saga > Here is the proverbial "wrench in the works". I spoke with the lab and it > turns out that the computer they use for displaying the results contains a [quoted text clipped - 36 lines] > > > > into the computer? > > > > Is that the case? Hi, You could write a program in QuickBasic (comes with DOS), and use the same parallel to serial converter. Straight forward -- though 15-years out-of-date. At a guess, we are talking about 20 lines of code. Dick SignatureRichard Grier (Microsoft Visual Basic MVP) See www.hardandsoftware.net for contact information. Author of Visual Basic Programmer's Guide to Serial Communications, 4th Edition ISBN 1-890422-28-2 (391 pages) published July 2004. ... > I did get some clarification on the process. It turns out that when the > printer is connected to the machine, the operator pushes a button on the > machine to send the results to the printer. To use the computer, the operator > types a command at the prompt to get the machine to send the results. I guess > this C program should capture the buffer. What do you all think? In addition to the other suggestions... Is the command prompt on the instrument or are they starting a capture program on the PC? (There's a little ambiguity in how your description can be read, at least to me) <If> that's on the PC, try the redirection trick before delving in too deeply... There's no reason I see to need to use C exclusively as Dick says and I don't see any reason to try to make them move to anything newer--it's quite possible the other instruments in the lab are incompatible, I have several of those myself with no possibility of sufficient funding to do anything different. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.