Using DT340 with HP-VEE

The message from "mysticengineguy" contains these words:

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

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

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

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.

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

Jerry

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.