Moderators: Dave Moll, Steve Anderson
AncientBrit wrote:Very useful application Steve, thanks. Cheers, Graham
gary wrote:An interesting approach to implementing a curve tracer is discussed here:
As you can see I'm back and if you want me to have a look at your graphing problem let me know requirements etc (preferably with some sample data). Cheers. Gary
gary wrote:Steve, if you are trying to read in through the parallel port in realtime under windows you are between a rock and a hard place. In general reading data in through the parallel port should never require any particular timing constraints.
gary wrote:Steve, if you are trying to read in through the parallel port in realtime under windows you are between a rock and a hard place. I have done this when attempting to write an interface for Ralph Taggert's "Virtual Televisor". Whilst the approach works to an extent that can read in video data fast enough to maintain a display of the data I have yet to determine a way to access the keyboard at the same time to allow user control (thus limiting it's usefulness somewhat).
gary wrote:One of these machines can be setup for DOS (or even a realtime OS if you have one) and thus can easily read parallel data in realtime at the throughput of the parallel port (so obviously the better the port the better the throughput).
Whilst dedicated hardware would be a more elegant and compact solution I doubt whether it would compare as favourably on price, all things being equal.
Steve Anderson wrote:
I have thought about going down a similar route. I really wish I hadn't thrown out the old 486 machine about a year ago, it would have been fine. I did use it in a very similar application whilst running DOS without any problems whatsoever. Once the data is on that machine then it's a simple transfer of the file to the main PC, even if it's on a floppy!
Steve Anderson wrote:The worst-case data would be 64k of 12-bit values (padded to 16-bit/ 2 bytes), most often though only around 2-3 thousand. Speed is not really an issue except at the moment it's intolerably slow at one sample a second (or so), 100 a second would be fine, a tube/valve requires a couple of minutes to warm up anyway!
Steve Anderson wrote:I did consider making the PC dual-boot and although many 'out there' say it's easy, I found it not to be so and shelved the idea. I did start with a new disc partitioned it FAT at 500MB, the rest as NTFS for Windoze. But it wasn't to be.
Steve Anderson wrote:Basically the hardware is two byte-wide latches that the D0-D7 of the LPT writes to. Bringing the strobe low updates one and the line feed updates the other. Each one feeds a D-A one generating the anode volts in 2V steps from 0V to 510V. The other the grid volts from zero to minus 51V in 200mV steps. Up to this point all works fine and is plenty fast enough.
The resulting cathode current is measured by a 12-bit serial A-D and input to the LPT port on the 'busy' input, the corresponding clock from the A-D is on the 'Ack' line. This is where things are very slow. The PC just cannot keep up with a clock of only 16Hz!
Steve Anderson wrote:But it can quite easily keep up with a commercial device through the same port and Win XP at over 24,000 samples/sec. (Not audio). And examining the waveform out of the PC it's rock-solid in its timing! They must have done something very clever in their application software.
Users browsing this forum: No registered users and 11 guests