NI AT-GPIB ISA card with linux-GPIB 3.2.11 driver: failed to allocate ioports
I'm trying to get an ISA gpib card working, but I have no luck so far. I have a NI AT-GPIB 488.2 card, Rev e.2.
I'm using linux-GPIB 3.2.11. I've configured the gpib.conf like this: Code:
interface { When I load the kernel module: modprobe tnt4882 the following output comes in dmesg (nothing in the console: Code:
Linux-GPIB 3.2.11 Driver Code:
gpib:/home/gpib # gpib_config --minor 0 Code:
gpib: (debug) request module returned 256 I also have an HP 27209 (also isa), this one came just as far but with: invalid base io address 0xffffffff I haven't tried any further, in the config I set: base = 0xdc000 but that didn't came through. small addition: In the bios I set IRQ 3 and DMA 5 to 'yes' in the section for the legacy ISA cards. There is also a UMB section, but this doesn't cover the base io adress (it does for the HP card). pnpdump doesn't find anything, the card isn't plug and play. Code:
gpib:/home/gpib # cat /proc/interrupts |
Sounds like it could be as simple as requiring root privilege to load the modules and to configure the driver(s)("Operation not permitted", "failed to allocate ioports"). Are you sure that your board works and is compatible with the driver you are loading? There are at least a couple different versions of NI ISA cards, and I think some are supported by a different module.
--- rod. |
I'm doing everything as root, so that shouldn't be the problem. I'm not sure of the condition of the board, but I think it is fine. There are different versions, I just checked and I did have the wrong card in the config, it should be "ni_nat4882_isa", but I changed this and the same error appears.
So, I tried it the other way: Code:
gpib_config --iobase 0x2c0 --minor 0 Code:
gpib: (debug) request module returned 256 When I now try ibtest: Code:
gpib:/home/gpib # ibtest |
Yes, it probably does mean it is working. You should try opening a device. It will ask you for a GPIB address, and then you should be able to write commands and read replies from the instrument. By opening a board, you should be able to read the state of the bus, control the bus, etc. Not so interesting, IMHO. If you have udev enabled, you should see /dev/gpibXX appear after the kernel module loads (or maybe after it configures, I forget).
As for why it works by configuring it the way you did, versus just using the config file, I can only guess. Is your config file located in the standard /etc/gpib.conf? --- rod. |
I'm trying to get anything out of a Keithley 192 with the 1923 GPIB option, but I only get bus errors. I haven't got the manual of the 1923 options, so even the address of the DMM is a guess. But I tried practically all addresses with the same result:
Code:
gpib:/home/gpib # ibtest edit: I just checked the cable, it's fine. The switched on the back of the DMM are probably set to address 7. |
Hey bluefan, I am having your very same problems with an ISA hp82335.
My /etc/gpib.conf is presumably set correctly as well as the jumper settings on the card. However, running # gpib_config gpib_config --minor 0 returns the same error messages that also reported. By giving # gpib_config --iobase 0xDC000 --minor 0 the card is apparently configured successfully as no message is displayed at the prompt (the base address I am feeding by the command line is the same in the gpib.conf) By giving # ibtest I try to write a string and read out the response enter a string to send to your device: *IDN? sending string: *IDN? gpib status is: ibsta = 0xc100 < ERR TIMO CMPL > iberr= 14 EBUS 14: Bus error ibcnt = 0 The same error message that you are getting. A quick look at dmesg shows gpib: (debug) request module returned 256 My question is, did you manage to get a bit further? Besides all this, I am struggling with the concept of IRQ and DMA. How can I know if an IRQ is taken? By just screening the output of # cat /proc/interrupts and look for a number x: that is not listed? And how do I pick a good DMA number? cheers, mirko |
Hey Mirko,
I didn't got any futher, I did try my HP 5334B counter, but as expected that wasn't the problem. I'll put in the HP card tomorrow, see if I have more luck than the NI card. I have no experience with IRQ's and DMA's, I just tried to pick anything that wasn't in use. I haven't got much time this weekend, but I'll try to get a little futher. And I'll see if I can get something out of the linux-gpib maillist. I should be so simple... regards, Johan |
It could be the termination character:
http://digital.ni.com/public.nsf/all...2566570074A501 But I don't think so. It may just be something with the interrupts: http://osdir.com/ml/linux.hardware.g.../msg00026.html Because: Code:
gpib@gpib:~> cat /proc/interrupts I still have my NI AT GPIB in by the way, can you check your /proc/interrupts? It's probably the same problem. |
I've changed the card to IRQ 9. Giving all options in the gpib_config doesn't change anything:
Code:
gpib_config --board-type "ni_nat4882_isa" --dma 5 --file /etc/gpib.conf --iobase 0x2c0 --irq 9 --minor 0 Code:
gpib command timed out |
Here's one possible interpretation of the error message: "There was no device that was addressed to listen to the command, and I got tired of waiting for one..."
Based on this interpretation, one could imagine writing a code snippet or iteratively using ibtest to write a message to each of 32 possible GPIB primary addresses, and see if you either get an actual response, or you get a different error message for one address. Do you have write permission on /dev/gpib0 (--minor 0)? What happens if you issue bus commands that do not require a specific listener, such as 'send (i)nterface clear'? What about writing arbitrary bus commands using the ibtest 'c' command? What about reading back bus status lines, especially with and without your instrument(s) attached? Do you know that your instrument actually responds to the IDN? command? This is pretty standard, but by no means universal. I don't think this is your problem (yet), because sending a 'nonsense' command should not result in a timeout in most cases. Do you have good evidence that your GPIB interface hardware actually works, such as functionality on some other platform ? --- rod. |
I execute everything as root, and I have the right permissions. I also tried with a HP 5334B, and with both the Keithley and the HP I get the same error message, no matter what gpib id I pick. I checked the cable. What I can do is check two other cards. I have no way to tell if any of the devices work, having three dead cards is a possibility. But I don't think that's the case.
I can see the bus status and things: interface clear: Code:
: i Code:
: l |
Yes, I think the card is working, or at least partly working. It may not be working as a listening device. I think (speculating) that listening is where interrupts &/or DMA is used, probably generating an interrupt or DMA request in response to bytes received or complete messages received.
Are your HP &/or Keithly instruments configured to listen to the GPIB? Some instruments, especially HP instruments, have a switch to select front-panel vs. remote control. If the setting is for local control only, the device ignores the bus. There is usually some way of discovering the GPIB address of the device, as well. The most typical ways are through a front panel menu + display, or with rear-panel dip switches. The 5 least significant bits of the dip switches generally gives the GPIB address. Many devices have a front panel indication of data transfers via the GPIB. If you can determine the GPIB address, try using ibtest to issue bus commands to the specified device (MTA,MLA,etc). See if these result in bus timeouts. These commands probably do not require IRQ or DMA, so if they work, but writing & reading data does not, then you can probably start looking for a better/different combination of interrupts/DMA. If you have multiple cards, you may be able to use two cards in two different computers to help you solve you problems. If I recall correctly, the Linux GPIB driver package (you are using that, and not the NI package, right?) comes with a program to perform such a test. Okay, I just did a quickie test on a NI PCI GPIB card that is running. It issues a query message every 2 seconds, and receives a reply string. I see about 45 interrupts per 2-second period, which corresponds pretty closely to the number of characters in the command string plus the number of characters in the corresponding reply. From that, I conclude that interrupts are generated on a per-character basis for both sending and receiving. At least on my hardware. Just thought this might be helpful. --- rod. |
My Keithley should work, but I don't have the manual and it's a quite old device. It dip switches imply addres 7 (the default for the device), but I'm not 100% sure, so I always try more than 1 addres with ibtest. The HP is very clear in this. I indeed use the linux gpib, haven't touched the NI stuff yet. That program would be interesting, but I have a little/big succes now:
I disabled DMA (set it to 0) just to have something less to worry about. I also connected my HP counter, just because I have it's manual to work with. I set it to adres 3 and it displays "addr 3" when powering up. So, I use ibtest to send something to the device with the addres 3: REN should be remote enable: Code:
: w And this command does use an irq: Code:
gpib@gpib:~> cat /proc/interrupts Ok, stupid me, REN is not a command to send as string. I'm new to gpib, so this can happen. If I send "FN2", it indeed starts measuring channel 2, just like the manual says it should. I can send ID (identification) without error, but how do I get to see what it responds? Ok, nevermind, I just got again a little futher. The HP responds with 19 bytes, so I really shouldn't choose the default of 1024 bytes the read commadn of ibtest has. Picking 19 would be better: Code:
: r Yay, it works!!! What it did? I don't know, maybe the DMA, using the HP counter again, I'll see if I can find it. |
Very good progress. A few points:
As you recognized, the REN command is not sent as a string. REN is a uni-line command, which means that it operates by controlling the logic level on a dedicated signal conductor on the bus. The command is issued with ibtest using the 'e' command, and is one of the 'uni-line' class of bus commands. There is another category of commands which can be issued to the bus, and these are accessed using the 'c' command of ibtest. Each of these will be a single byte, and the state of multiple bus lines will be affected. Some commands contain a device address in the lower 5 bits of the command. A table of the commands is in the Linux-GPIB driver package. In communicating with a test & measurement instrument, the usual procedure is to first issue a command string to the instrument, followed by a read from the instrument. This would be the procedure to retrieve the device ID. When reading back from the instrument, you can usually allow for an arbitrarily large reply. The instrument + device driver + application software can determine that the reply message has terminated, and close the read operation appropriately. There are different methods used by different instruments, device drivers, and applications to determine when a message has completed. Tuning these methods is often necessary, and may be accomplished in different ways. The gpib_config file is one part that may be used by the Linux GPIB device drivers. This is often the most confusing aspect of using GPIB, especially when there are combinations of instruments that use different methods of signaling end-of-message. Sometimes, as I think is the case with your HP counter, the instrument will send unsolicited data, simply by reading from it. It looks like you are on the way to succeeding in communicating with other instruments, now that you have the controller working. One thing that may be playing a role for you is the possibility of a secondary address. To accommodate more than 32 GPIB addresses on a bus, there is a secondary address scheme. I've never had to use it, but I think if your instruments are configured to a non-zero secondary address, then you will need to either reconfigure them, or use the secondary addressing to talk to them. Sorry that I don't have the details on how to do this, but I though it is worth mentioning if all of your efforts fail. I have had some success finding online documentation for older instruments; at least enough to get my GPIB communications working. This may be an option for you if you are unable to get your older gear to talk. There are also a few places that sell old manuals, although I've never used one of those. Good luck. --- rod. |
All times are GMT -5. The time now is 10:12 AM. |