yes its possible

 

Okay. Here you go Xiptron. Let me know how it works out for you. The txt file and the program file must be in the same directory.

Attached Files

MULTI6.zip (24.0 KB, 7 views)

 

See next post.

 

It's working well now CC. I have installed it on an old 286 laptop as it seems to be prefer running under dos in W95. On my current XP machines the program sometimes won't load, or it'll crash or trigger on entering a filename. Not to worry.

One thing is that it won't start by connecting DSR to DTR, but will start with 9V (from a small battery) connected to DSR via a remote switch. (I found that getting it to start by connecting DSR to DTR is dependant on how the DTR interface is configured).

Abort (Control-Break) doesn't function but that's not really an issue.

For now I have to close the program and relaunch it with a new filename for my different timings. This is a bit of a pain and a refinement would be, if you're willing : ), to load a new file without having to close first. Perhaps after timing completion it could ask "Enter new filename"?

I really do appreciate your efforts in preparing the program for me CC, thankyou.

 

It's working well now CC. I have installed it on an old 286 laptop as it seems to be prefer running under dos in W95. On my current XP machines the program sometimes won't load, or it'll crash or trigger on entering a filename. Not to worry.

I made some improvements that may solve some of the above. It works for me in an XP cmd window. I cleaned up the counter display to make it easier to read, also.

One thing is that it won't start by connecting DSR to DTR, but will start with 9V (from a small battery) connected to DSR via a remote switch. (I found that getting it to start by connecting DSR to DTR is dependant on how the DTR interface is configured).

You need to short RTS to DSR, not DTR to DSR. Also, the timers start when a change of state is detected on DSR, so holding DSR high will not restart the timers on the next go-around. When running in an XP window there is a couple second delay from the moment a state change on the DSR pin occurs and it is passed to the program. This delay occurs when the program is first run, only. Nothing can be done. The delay is not seen again if the s key is pressed and the timers are restarted with another DRS trigger. That should do it. Of course, the battery applied to DSR will work too.

Abort (Control-Break) doesn't function but that's not really an issue.

Yeah, I see that. It only functions once the counters are running.

For now I have to close the program and relaunch it with a new filename for my different timings. This is a bit of a pain and a refinement would be, if you're willing : ), to load a new file without having to close first. Perhaps after timing completion it could ask "Enter new filename"?

Okay, done. Your welcome xiptron. I've done very little bug testing, so I leave it to you to let me know if anything else needs fixing.

Attached Files

MULTI6B.zip (24.0 KB, 2 views)

 

Thanks for reply CC.

One thing is that it won't start by connecting DSR to DTR, but will start with 9V (from a small battery) connected to DSR via a remote switch. (I found that getting it to start by connecting DSR to DTR is dependant on how the DTR interface is configured).

OOPS! That was my error! I didn't take enough attention to note that it was from RTS to DSR. I'll try it and dispense with the battery (it is a momentary closure btw).

Something else I would find useful is a PAUSE function acting over all timers.

I've just noticed that the countdown is too fast, gaining 7 seconds over a ten minute period. I wondered why my sums weren't working out! Could the 286 internal clock be running too fast? Not much of an expert in these areas I'm afraid.

 

I can add a PAUSE function. I noticed it runs about 7 seconds per 10 min faster than the PC clock too! If anything, I would expect a problem where it runs a bit slow due to processing time??? I'll need some time later to work on those things.

 

Ver 6b is working well and the mods are great.

Adding PAUSE to the next version will be cool.

For now I'm applying a correction factor of 1.0117 to obtain the correct durations (thank heavens for spreadsheets!). Let me know when you've found the problem (would slowing down my cpu help? There are a few programs around to do this).

 

Just thought I'd let you know CC that I've had to stop using your software for the present. It's a shame after all the work you did for me but the error is a big problem and the correction factor isn't working out over my longer timing periods. I tried slowing the 286 cpu down and it seemed to help but it still doesn't have the accuracy I need over periods like 90 to 180 minutes. Maybe it's not a cpu thing? While I appreciate the problems involved I think the timer design may need to be one compatible with todays faster processors and operate under Windows. You may not want to go to this trouble and I will understand that.

 

Just read the PC clock and use that to control the durations. It's no harder to read the clock in hardware than to write to the serial port in hardware.

 

Xiptron, this version uses a function which is tied to the PC's clock. I think it solves the timing issue. I also added a pause function. Let me know. Regards

Attached Files

MULTI6D.zip (24.3 KB, 2 views)

 

CC many thanks, please see txt attached.

Attached Thumbnails

 

Attached Files

changes4dostimer.txt (1.3 KB, 10 views)

 

Gary, I can do most of those things if not all of them. I'll be back with an update in the next few days.

 

Someting that could help: PC timer which also raises RTS and DTR on timeout.

 

Cool, thanks cc. Just one last thing, can you replace "EXPIRED' back with the original 00:00:00 syntax. Looks better. Ta