Mark iv data capturing in pc.

  • Thread starter Instrumentation
  • Start date
I

Thread Starter

Instrumentation

Hello. We have been using hyperterminal of Windows XP to capture the serial printer data from mark iv control system. The same data we are using to capture in text format by using the "capture" facility of hyper terminal. Now when the pc is restarted, the hyper terminal function starts by itself (we have used the file in startup of pc) but the capture function to capture the text needs to be done manually. I would like to have the capture into text format automatically as and when hyperterminal file is started. Can anyone please suggest me if it is possible or any other program that can be used in place of hyperterminal to capture mark iv printer data.
 
C

Curt Wuollet

COPY COM1: FILENAME

Or if you are really command line challenged, check out Kermit. The versions I've used could be configured to do this,

Regards

cww
 
Any communications program capable of RS-232 serial communications over a COMn port and configured as you have configured Hyperterminal can be used to capture data from the Mk IV printer port.

Google "serial+communications+software"; there are many packages available. You could also check some of the Windows shareware/freeware sites.

There used to be some MS software (PowerToys?) which had a macro recorder which could be used to capture keystrokes and clicks into a macro file which could be executed on start-up or by clicking on a destktop shortcut icon. It was a very useful tool--kind of like creating command-line batch files in DOS but "automatically" in Windows!

Perhaps some crafty person could write a VB app to do this automatically? Or a script file?

markvguy
 
Mr. Wuollet's suggestion is by far the simplest and easiest. You just substitute the name of the file you wish to store the data in for FILENAME, put the command in a batch file and execute the batch file on start-up. (Do this by putting the batch file in the Start-Programs-Startup directory???) Hyperterminal is just a graphical user interface that requires lots of clicks to do the same thing one can do from the command line.

The Microsoft PowerToys were available from the Microsoft website; it's not certain they contained the macro recorder but there are probably many such applications available via freeware or shareware.

Anyway, other than that the PC you're using is running WinXP (an extremly reliable and stable OS--NOT!), why is it necessary to keep re-starting the PC? This seems to be the "bigger" problem.?.?.? Is there some other application which keeps crashing the PC?

markvguy
 
I

Instrumentation

Hello,

Well we need to restart the pc as we are running another application with the same pc.

Well What are the command lines you are talking about???
 
Well,

COPY COM1: filename

is a command, executed at a DOS prompt, sometimes referred to as a "command line." It tells the COPY command to "redirect" the input to the serial port COM1: to a file (the file may or may not have a filename extension and may include the entire path to the desired location/directory/folder).

The command could be placed in a batch file and the batch file could be placed in the 'Startup' folder and executed each time the PC was started. WinXP has reasonably good Help files on command line (DOS) execution and batch files. You could also refer to some 'mature' DOS batch file books, or search the Internet for examples and help.

What's not clear is how to stop the command, short of closing the command prompt window it would run in; perhaps Mr. Wuolett could comment?

markvguy
 
C

Curt Wuollet

I think sending an EOF from the host would do it. Or simply typing a <cntrl>C. This isn't a redirect, it's still just a copy command. To redirect from the command line I believe would involve the MODE command IIRC, the way you used to redirect LPT1 to a serial port when using a serial printer. Or in the early days to, redirect the console CON: to a serial terminal. No MS software here to check but I'm sure there are folks with DOS books out there. Might be an ASSIGN command. That's a lot of years (and OSs) ago :^). DOS actually had pretty good functionality if you knew it well, and didn't hide it from
the user.

Regards

cww
 
M

Michael Griffin

Under MS-DOS, the MODE command could be used for port and display settings and for re-directiring between the serial and parallel port, but not for re-direction to a file. This is not suitable for the problem.

Assign was used to change the letter by which a driver was referred to (e.g. "assign a = c"). It was replaced by the "subst" command in later versions of DOS (e.g. when MS-DOS adopted subdirectories). This is also not suitable for the problem.

Both of the above were used for MS-DOS, and may possibly have also worked on MS-Windows 95 and 98. Newer versions of MS-Windows have dropped a number of the original MS-DOS commands (likely including the above two) and added a few new ones. Even with the original MS-DOS, I/O manipulation related commands didn't always work in conjunction with application programs because it was common practice for application programs to bypass MS-DOS and work directly with the BIOS or the hardware (MS-DOS functions were often slow, buggy, and of limited functionality).

I'm not sure if the "copy" command works correctly with a serial port, although this could be easily tested. I/O redirection (e.g. using ">") would likely work the same as "copy".

However, it is unlikely that the above would be sufficient for the actual needs of the application. It appears as if the system is intended for frequent unattended operation, but it is difficult to make a recommendation as we don't really have a good description of the overall requirements. For example, is it desired to continuously append to one large file, or should it start a new file every so often? Should you be able to view the data as it arrives in the serial port (so you can see if it is working)?

It would not be difficult to write a small program to do this. I have done this in the past for special applications. This can be written in pretty much any programming language (execution speed is not a problem).

It is not much more than:

1) Wait for serial port and monitor for "quit" command.
2) Read serial port.
3) Open file.
4) Write to file.
5) Close file.
6) Echo the data to the display.
7) If a "quit" command was received then exit, else go back to step 1.

It is typically a good idea to limit the size of the file by starting a new file (with a new name obviously) every so often on a timed basis (e.g. once per hour or day).

Alternatively, there should be scriptable terminal emulation programs that are suitable (Hyperterminal is rather limited). The old MS-DOS version of Crosstalk used to have a script file with a special name that would (if present) be automatically run on start-up of Crosstalk. Doubtless there are some more modern programs that will do the same thing. The problem with this approach however is that these programs often have so many features that it is easier to write your own simple program than it is to learn how to use the terminal emulator.
 
C
Hi Michael,

I have also coded a skeleton program or two in C to do this as in my tasks there is often other conversion to be done, e.g. stripping and formatting database records from reports, and it's handy to put that stuff right in the port reader. But MS users are usually impoverished in regard to programming tools and tools in general, so I don't think those would be helpful. But the copy thing does work, or did in "real DOS" anyway because I used it often. Actually IBM DOS used to come with a crude terminal emulator as an example of the included BASIC interpreter. That would be an ideal starting point under DOS if a version with BASIC can be found and used. I don't know how much they've degraded DOS to bring it to Windows standards, but I doubt they give you GWBASIC or BASIC to work with. Any Linux version would have the tools to do this elegantly, but I was trying to offer what he might have available. The Mode and Assign misinfo is simply at least 20 years of not working with DOS, having moved on to vastly more powerful *NIX and my desire to forget MS. :^)

Regards

cww
 
It's not normal (well, this is Windows we're talking about here...) to have to shut down and re-start the OS to start/stop/re-start an application. From the original post it seems Hyperterminal would work fine if the OS didn't have to be started/re-started....

It doesn't appear as if the COPY command will work under WinXP as the I/O is handled differently under Windows than it was under DOS (command-line OS). Two tests have caused WinXP to hang, requiring a reboot of the computer... this after making sure the port was configured and communicating properly using Hyperterminal and Control Panel.

Google for telecommunication software applications; unfortunately, many of them seem to be fairly high-priced these days (USD$150-$300), and there doesn't seem to be a lot of shareware telecommunication apps available these days (though that is still an option). http://www.tucows.com is still a good site for Windows shareware/freeware applications; there are several others, also.

markvguy
 
M

Michael Griffin

I will say to begin with, there are a number of serial data loggers available (use google to search for "serial data logger"). There are programs which run on a PC and log to a file, and there are dedicated battery operated "boxes". For use on a PC I would prefer to write my own small program to tailor it to the task. For someone who doesn't want to do that though, there are ones you can purchase. You must however be willing to live with the limitations of what a general purpose product can do.

The commercial terminal emulator software market has dried up because of the internet. The major market for these was to connect to mainframes or mini-computers (locally or remote over a phone line). This market has pretty much been taken over by the web browser and the web server.

There are still lots of terminal emulators for Linux though (you usually get several with any normal distro) and they won't be disappearing any time soon. If you need to dedicate a PC to straight forward stand alone terminal
emulation Linux is probably the best choice.

As far as problems with using the "copy" command at the MS-Windows command line is concerned, I didn't expect that you could lock up MS-Windows (requiring a reboot) just by using the "copy" command. I suppose I shouldn't be all that surprised though.
 
C
Well, a quick look shows that the Kermit project has succumbed to the money grubbers. But, the DOS version is still free and eminently suitable for this task. Kermit is very powerful and a little arcane but it supports a scripting feature that lets you load it at boot configured for the task at hand. I used it a lot for turning PCs into terminals, it even supports TCP/IP with a packet driver, I believe. At least it did when I was using it. A PC with Kermit on an Ethernet connection was a great leap forward for terminal users as it was lightning fast and had very good emulation for common terminals. I would expect that Kermit on DOS is still faster than anything on Windows. It might take some reading but if you fool around much with terminals or serial devices, and you don't grok Linux, it's a very useful tool. And it will run under Windows, from what I hear. Failing that, if you have any programming language available, it's not very hard to write something that simply sets up the port and copies everything to a file. I probably have an example or two around here but they would be for *NIX.

Regards
cww
 
Top