12-15-2017 01:37 PM
I am attempting to resurrect several instrument control programs I have used successfully in the past.
They are written in GWBASIC (because that is what I have and what I know how to use) and I am running them on an old Win98 machine (because it has worked in the past).
The GWBASIC programs include the required statements from: "DECL.BAS" and "bib.m" is present in the directory where I am running the programs.
I believe my problem lies in the configuration file created by ibconf.exe
When I exit ibconf.exe I get the following warning:
CAUTION: Board GPIB0 is not present in this machine at address 02B8H. Do you still wish to exit ibconf? (y/n). When I say "y" I get: "Handler file unchanged".
I can't find a base I/O address for the GPIO0 that ibconf likes.
Device Manager says the board is installed and working properly with no conflicts. Under Resources it says:
Memory Range: DFFDF800 - DFFDFFFF
Memory Range: DFFD8000 - DFFDBFFF
These addresses will not fit in the ibconf field for base I/O address.
As a result, my application program can not talk to my device (HP59313A A/D Converter) and I cannot access the device using ibic. I see no bus activity on NI Spy when I try to access the device using either of these methods. When I do an ibfind I get error: EDVR(2).
However, when I run the "Getting Started Wizard" to verify the hardware and software installation it says: Software Presence Verified, Hardware Presence Verified, GPIB Interface Sequentially Verified. GPIB Name: GPIO0, Interface Type: PCI-GPIB, Status: Passed.
When I use "Measurement & Automation Explorer" and scan for instruments it finds my device and says it is at primary address 16 (which is where I have it set up in ibconf). I can communicate with the device using "NI-488.2 Communicator" and when I do, the bus activity is seen on NI Spy.
It seems that neither my application program nor IBIC can communicate with my device while "Measurement and Automation Explorer" can. I suspect the difference is that "Measurement and Automation Explorer" does not rely on the configuration created by ibconf.exe while the other two methods do.
Any help would be appreciated.
Solved! Go to Solution.
12-18-2017 04:04 PM
Hey there,
If your GPIB communication works in MAX you could consider remaking your program in LabVIEW.
It sounds like NI products are functioning as expected.
12-22-2017 07:28 PM
Rather than purchasing a new application to replace the one I already have, I prefer to find the one small piece of information needed to make my current application work.
After doing a lot of digging I managed to find the answer to my original question, which I will post in a separate reply.
Thanks.
12-22-2017 08:13 PM
I discovered I had a couple issues.
First, the GPIB board I was using (PCI-GPIB) is not supported by the DOS driver. I solved that by switching to an AT-GPIB/TNT PnP board which I also have.
The second problem was that the DOS driver is not able to install the board into the Windows Device Manager so no resources get assigned to it and IBCONF thinks it does not exist.
I found a NI publication (321011C.pdf): "Using Your NI-488.2 Software for DOS or Windows 3 with Windows 95/98". It describes how you can go into Windows Device Manager, find I/O address ranges that are not being used by other resources, reserve them for the GPIB board and then enter them into the IBCONF utility. Unfortunately, that does not work. When you do this and exit IBCONF it says the GPIB board is not present at the I/O address entered. If you then go back into device manager and look at that I/O address range it says it is now being used by an "unknown device" and there are no "National Instruments GPIB Interfaces" in the list of device types (even after rebooting).
However, somewhere I saw a comment that the DOS Driver for the AT-GPIB/TNT PnP (Version 2.7.2) and the Win98 Driver (Version 2.2) can be installed at the same time (as long as you don't try to RUN them at the same time). So I Installed the Win98 Driver then powered down, installed the AT-GPIB/TNT PnP hardware, powered back up and let the Windows New Found Hardware Wizard add it to device manager. I then went into device manager and noted the I/O address range that had been assigned to the board. I then ran the DOS version of IBCONF and input the I/O address that the Windows driver had assigned to the board. That worked! My original GWBASIC programs now work with one slight modification: The DECL.BAS file has changed in this later DOS driver (for instance it no longer uses bib.m) so the new DECL.BAS rather than the old one, has to be merged with the GWBASIC application programs.
02-07-2024 04:58 AM
Hello. I have a Horiba/Jobin Yvon monochromator that has a GPIB unit that operates the various commands. It sounds like you are running similar? I will be using a NI GPIB-USB-HS Interface and w10 to try to talk to it. I have the manual for the instrument, with the GWBASIC programs used as examples, but I do not have the original GWBASIC file DECL.BAS. While I won't be using this code it would be useful to have it or a listing of it to save guessing at what the subroutines are doing. I'm planning to use NI VISA to communicate, which has worked well for other OEM type issues like this. So a listing of DECL.BAS and/or any further advice you may have would be welcome
02-10-2024 03:39 AM - edited 02-10-2024 03:49 AM
I think DECL.BAS was simply the GPIB interface definition for Basic and it defines functions of the NI GPIB 488 driver like ibrd(),ibwrt() etc. However programming on 488.1 level in this time and place is similar to wanting to drive from A to B in a Ford T model: one hell of a ride and cool to brag about but if something breaks on the way you are on your own.
The way to program GPIB is since over 20 years through NI VISA. That API can access GPIB just as well and is a lot simpler in most cases. Only thing where it can get a little tricky is when trying to access really old devices that were released before IEEE 488.2 was released. 488.1 offered a lot of obscure options to save a few us here and there and that some manufacturers used in random selection and made programming a device an exercise in studying the GPIB bus down to bit level and sometimes prevented two different devices operating on the same bus due to timing incompatibilities. 488.2 did solve that by encouraging one specific bus operation and abandoning some of the more obscure options.
Since you don’t want to use GW Basic anyhow I would go the extra mile and use NI VISA instead. The most important part will be the commands sent to the device (where your program uses ibwrt()) and figuring out how to parse the responses read through ibrd(). These correspond almost verbatim to viWrite() and viRead() when using VISA. There might be some extra ibXXX calls initially to setup the GPIB interface in a particular way but most of them are easily set through VISA properties or may not even be required if your device is reasonably 488.2 compatible.