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.
02-10-2024 05:32 AM
Dear Rolf, many thanks for this. The main reason for asking about the GWBASIC add-ons was to ensure that I could reproduce the calls using VISA. I did find some other application where various constants were set up. I use VBA and NI VISA a lot as I used to be a VB6 person and I like buttons and stuff for free. I am pretty sure I am OK with that now.
The issue I am hitting is, I think, a hardware (or firmware) one. The target is a monochromator interface manufactured by Park Scientific in the 1990s. It drives a stepper motor, but the interface has some mid-level code in it to make it easier to get the motor to move n steps, reset, and so on, from a higher level (the GWBASIC or whatever I use). I can talk to it using the NI GPIB-USB-HS interface, meaning I can get it to respond to what is called the "where am I?" command (it's just send a space " " in fact). The box replies with a "B" which means it's in bootstrap mode. It should be when it's powered up first of all. Well so far so good. Then I need to get it to enter program mode. This requires the string "O2000" plus a null (chr$(0)) to be sent. I take this as telling the bootloader to commence execution at 'line' 1000 (probably hex) in the program. This causes the box to hang and (so far) I can't get back from this without cycling power to the box. I cannot write any commands to the stepper motor without being in Program mode, the Boot mode will allow some reset functions that I have tried without beneficial effect so far. I do not have a schematic for the interface box, though of course I have had the top off and can understand what's in it (I have a good knowledge of 1990s electronics). Without going through a lot of stuff, I can say there is a UVEPROM in there (27C512) which I expect contains the Program code. As it could easily be 30 years since it was programmed, I worry that it has lost a few bits and so this Program functionality is lost.
So far I didn't find any firmware on the internet so I could reprogram it. I fear my only chance is to put a different stepper motor driver in place of the interface box (the stepper motor is a unipolar 2-phase SAIA unit) and program an Arduino to do something similar to what was intentioned. I was hoping to avoid that, and the project is on the margins of the bin right now. Any ideas gleaned from your experience would be welcome.
02-10-2024 05:40 AM
Rolf, I should add that I have been in contact with the original suppliers Horiba Jobin Yvon, who have been helpful on another query (I need some UV gratings for this spectrometer) and have supplied me with some data I already had. I plan to write to them to ask if they have a schematic of the interface box and so on, but all the electronics is OEM (Park Scientific) and I think they have no follow-up on that. Basically the person who designed it, and his apprentices, will be moved on/retired/passed away by now. But you never know!
02-10-2024 06:20 AM - edited 02-10-2024 06:34 AM
Sounds to me that the problem is actually with the interface box which may be actually a custom design job for this setup. The name Park Scientific does not ring a bell and may have been a small engineering shop who was building this device for this specific setup and in that case it is very unlikely that Horiba knows anything about its internals. The only thing I can find is Park Scientific Limited in the UK. They sell however chemical materials, close but not quite the same. Maybe they did originally also resell spectrometers in the past and even custom modify them for some specific applications.
An Arduino in its place may be indeed the most promising solution as long as you can get the interface description of the Horiba device
I’m impressed that they actually still give support for such old devices. Most manufacturers nowadays wouldn’t even respond to such an inquiry or instead send you an offer for their newest and greatest device.
02-10-2024 08:10 AM
Many thanks Ralf. I will spend one more afternoon on software, but tbh I think it will be wasted time. I have identified where the 'intelligent' part of the controller ends and the 'power drive' for the motor begins. There are 6 TTL levels to the ribbon cable between the two boards, which then go into a PLA, and as I don't know how that has been programmed, I've no idea what they might do. Probably they don't map to the 6 ends of the stepper motor wires, more thyat they select fractional stepping phases etc. If I can work this out by trial and error then I can use that part of the circuit to condition the Arduino outputs, to save a bit of time, and also use the power supply for the Arduino.
My dealings with Horiba UK have been very positive up to now, and they have offered a 'best effort' solution to the gratings issue. But so far, no quote. It may be horrific...
Thanks for your inputs, which are most helpful.