Using DT340 with HP-VEE

I am trying to use the Data Translations 340 timing board with the HP-VEE programming software. I have the DTVPI interface software
installed on my computer.
My problem is that HP-VEE refuses to acknowledge the presence of the board. The board is mounted on a PCI slot of my computer, and its driver (DT Open Layers) is installed and enabled. On HP-VEE, I/O => Instrument Manager => Find Instruments doesn't detect any interface at all! When I do a I/O => Instrument Manager => Add Instrument, with the hope of adding DT340 as a recognizable instrument within HP-VEE, I don't know what kind of interface I should choose, what the address should be, and more importantly, what the driver file (*.cid) for DT340 is called, and where it is located on my hard disk.
Since DTVPI is an interface between HP-VEE and DT340, does one need to provide a DT340 driver to HP-VEE at the time of configuring the board, or does DTVPI have a "virtual driver" for HP-VEE to see?
Someone, SOS.
-SD
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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.

  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.