Using DT340 with HP-VEE

I am sure some body with more knowledge will be along soon, but in the
mean time perhaps I can help.

It is about three years since I had one of these in a PC which was also
using a A/D card from the same people, cannot remember the exact number
at present. From what you say you have HP-VEE installed correctly and
you have also installed DTVPI. If this is all then your problem lies
with not installing the DT340 "driver" I assume windows is been run. It
sounds like you have the method to communicate to the card but it cannot
speak to it without the driver. Have you looked on the DTVPI disk for an
example for this card (cannot remember if these are also accessible from
the menu tool bar they were for the A/D card) this will save having to
write from scratch. Try their site for latest drivers or drop them an
email, the UK office were always very helpful to the company I used to
work for. Just noted you mention DT Open Layers, are you sure that this
is the correct driver rather than a protocol. Further to this with one
board we had to ask for earlier versions of DTVPI as it would not
run/detect the version of DT-VEE we used.

Hopefully this will help

Thanks for the reply. It turns out that the card was being recognized
after all. I still don't know which mode I am accessing the card in
(i.e. whether it is direct access or using panels or whatever), but I
am able to do things like measure frequency of a square wave etc..

However, one thing that is still hung is that I am not able to set the
counter timer frequency of any channel to a value over 1 kHz. The
internal oscillator on the DT340 is apparently 20 MHz, and people have
told me that I should easily be able to get 1 MHz out of the counter
timer. When I set the frequency to anything above 1 kHz, the computer
progressively hangs for longer and longer durations as the frequency
keeps incresing. At 1 MHz, the computer reboots!

Any ideas?

-SD

mysticengineguy wrote:

It looks like the counter timer generates an interrupt at 1kHz or
above and that your OS can't handle it at that rate. Is this the
case?

Well, I think that the counter timer does generate up to 100 kHz. The
computer hangs once the generation starts - I have to abort the
process, although I do see the square wave output on an oscilloscope
while the computer is hung. So you're right, may be the OS (Win 98
here) can't handle it. But that is VERY unlikely because we used to
have the exact same card on an older (and slower) computer with Win 98,
and I used to be able to do a 1 MHz generation quite comfortably. I
installed new drivers for DT 340 on the older computer after which it
stopped doing what it used to - my guess is that the driver
re-installation has somehow reset some configuration because of which
the problem is occuring. The driver itself couldn't have a problem; I
can do things like setting individual digital i/o pins high and low,
and confirm that on a scope. I can measure the frequency of an external
wavetrain etc. using HP-VEE and this card.

Of course, at 1 MHz, the computer neither generates any output nor does
it hang - it just reboots!

-SD

mysticengineguy wrote:

Can you also enable or disable interrupts when setting this I/O pins?
If you can disable all interrupts from the counter you can adjust
the rate and see if that has an influence on the PC.

It worked like a charm. You're the man!

On disabling all PC interrupts for the counter timers, I was back to
business. Could you help me understand why turning the PC interrupts
off remedied the rebooting and hanging problems? This is so that in
future, I don't spend two weeks wondering why something that was
working a few minutes back doesn't work anymore.

Thanks again for the advice.

-SD

mysticengineguy wrote:

Interrupt Service Routines execute at a high priority level and can't
be interrupted by user processes. If the interrupt frequency is
too high, ISRs will take up most of the CPU time and user processes
are slowed down. If the frequency is still higher, queues that are
used to store pending requests issued by ISR might run out of
physical memory and crash the PC, eventually causing it to reboot.

Lanarcam wrote:

That's all true, except that an interrupt routine can be made
interruptible at the programmer's option.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Jerry Avins wrote:

This is true but an ISR can only be interrupted by an ISR of higher
priority if the programmer has not changed voluntarily the level
at wich the ISR executes. If the ISR has disabled all interrupts it can
even never be interrupted but this is *normally* for extremly short
periods of time.

ISR are meant to react quickly to external events so they should
execute in the least possible amount of time, delayed user processes
being responsible for later processing. In theory this is true but
badly written drivers can cause problem indeed.