NI MAX sees GPIB controller/board, but hangs on Troubleshooting test/Scan

Hello,
I have a new PC (Win7, 64 bit) with a new PCI-E GPIB card and NI-VISA 14.0 (latest). I can't get the card to 'do' anything - it won't pass the troubleshooting self test, or scan for instruments, and the ibfind command in Interactive control does nothing (they all 'hang' no error reported). This is happening with two identical machines, each with the PCI-E card. My test machine from 6 monts ago works fine, but that is 32 bit and has a different firmware/chipset from the vendor (which was unexpected, we ordered the same model, but the vendor seems to think it's so minor they kept the model the same number).
Any ideas on what steps to take? I've downgraded NI-VISA a couple of times already, and Windows happily reports the driver/card are working fine. GPIB options all seem normal on default (GPIB0, system controller checked, etc).
Thank you for any suggestions!
- Rick
Solved!
Go to Solution.

Hi rnelsonee,
Make sure that you also have the NI-488.2 driver up to date so you can communicate with GPIB devices properly. You can follow this link for a download.
http://www.ni.com/download/ni-488.2-14.0/4802/en/
If you are still running into issues, could you let me know what kind of errors you get when you fail the self-test in NI MAX? Any screenshots or error codes you can provide will be useful. Thanks.
Paul C
Paul C
Applications Engineer
National Instruments

Similar Messages

Labview error GPIB controller not adressed correctly

I get this Labview error: GPIB controller not adressed correctly (LV5.1, win NT4) when i try to send data to a HP4275A LCR meter. How ever it works on an older system running with LabView 5.0 (also NT)!!!
How can I get rid of this problem????

Hi Diego, thanks for the hints!
I tried to configure (GPIB) everything standard.
when I try a 488 command initialze, I get the controller conflict, when i don't do this I get atime out problem either by 488 write-command or by 488.2 send-command.
the differences between the systems where it works and where not are:
working: Win 95, LV 5.0, GPIB-card/TNT (plug & play)
not-working: WinNT, LV 5.1, GPIB-card/PCI
i tried to set baord config to the same parameters...
on the faulti system however I see the instrument with the MAX and I can send commands, without problems !!!!
Also the driver you posted does not work (but the NI-communicate program ;-)
i have no clue what else to do!
btw. how do I copy the spy output when running the program? I may provide
this to find errors.
Since MAX indicates the board is all right I guess it is not necessary to reinstall the boarddrivers?!

Command requires GPIB Controller to be Controller in Charge

I downloaded the labview driver HP428XA, the 'getting started.vi' works fine, but all other example application vi's keep giving me the following warning:
'Warning 1 occurred at VISA Read in HP428XA Fetch.vi->HP428XA Frequency Step Measurement .vi. Possible reasons:
LabVIEW: An input parameter is invalid.
or
NI-488: Command requires GPIB Controller to be Controller in Charge.'
I am a novice when it comes to labview, can anyone offer a solution?
thanks!

Hi,
The two error descriptions refer to the fact that the error code (1) has a different meaning depending on what software component gave the error: labVIEW or GPIB (NI-488.2).
Since you are able to use the Getting started VI, that means that the GPIB bus, driver and the VISA library are working porperly. Additionally, you would not get a Controller in Charge error if do not explicitly configure the board to be non system controller. labVIEW automatically configures the board to be controller.
So the error must refer to an incorrect parameter to some LabVIEW function. Open the HP428XA Frequency Step Measurement.vi and use the highlight execution tool to see where the error is generated.
I couldn't find the instrument driver at www.ni.com/idne
t, so I didn't take a look at the driver.
DiegoF
National Instruments.

Embedded systems (PIC based): We are looking to upgrade our GPIB controller chip from Ines iGPIB7210 to a more "mainstream" chip and are interested in NI's offerings.

Ines provides a library of ANSI C source to drive their GPIB chip from any suitable processor (as do ComputerBoards). Do NI have a source code library for their driver chips? BTW it doesn't need GPIB "Controller" capability. The uP controlling the GPIB chip is a Microchip PIC18C452.

Hi Mr James,
Thanks for your question ..We are also planning to have GPIB interface for our equipment .Again we are new to the interface design .For our equipment we dont need controller capability.I think Ni TNT 488.2 T/L is suitable for our application .But we are stuck with this ...Our equipment has a PIC 16c77 MCU.
If you can help regarding the procedures to be followed for having this GPIB interface that will be great!!!
I have some doubts regarding this.
1. How we can use the TNT 488.2 chip in our equipment board.
2. How we can controll this GPIB chip Is it is done by PIC controller?
3. Is above PIC is compatible with TNT 488.2 T/L.
4.Do we need to program the GPIB chip.I know that there is a devoper kit ESP-488 package is there .How we can
develop program for GPIB using this package.
5. Who will help in designing the same
Please help me .
Thanks in advance.
regards
Prasad

How do I use my controller board with garageband?

I have an Edirol PCR-30 controller board which I use w/ garageband 3.x. So far I've only been using it as a keyboard and not as a tool. What I mean is it has all these knobs and sliders but I have no idea how to get them integrated with GarageBand.
Can anyone explain this process?

I can pair the headphones with the computer but the sound from GB is distorted and muffled. I can barely hear it. The set works with iTunes, but not with GarageBand.

Enet100 GPIB controller on 64 bit OS

After having to upgrade to the new LabView because of a bug and seeing how poor its performance is, I decided to give it the benifit of the doubt and got a brand new Core 2 3GHz PC w/ 8G of RAM.   I figured the time I am wasting trying to use the new interface will pay for the PC.   I now have XP-Pro-64 bit installed to take advantage of the memory, plus most of the tools I use have 64-bit versions now.
I went to install Labview and there appears to be no support for the Enet100 GPIB controller. This is how I talk to most of the test equipment. I know, your thinking why is he not using ethernet. Some of the equipment doesn't support it, and some of the even newest equipment, like the Tek AWG7102 arbs software is so poor that the GPIB is actually a faster way to talk to it.
Any idea when and/or if there will ever be new drivers to support the Enet100 on the newer 64-bit OSs?

Thanks for your help!
I had been looking on:
http://zone.ni.com/devzone/cda/tut/p/id/6893
and noticed:
National Instruments Products XP x86 (32-bit) Vista x86 (32-bit) Vista x64 GPIB-ENET firmware A.5
Assumed because there were no checks for it under Vista x64 there would be no driver.   I downloaded the drivers you linked to and they appear to work with XP Pro 64-bit even though there is no mention of this particular OS.   Tried a few things with the new PC and  LabView is still a little sluggish on it compared to 6.1 on a much slower PC. But it at least shoud require less hair pulling....
If I could just get NI to put the menus back to the way thay have been since the beginning of time and and allow me to do some sort of setup on that control menu so it does not pop up with that stupid express menu that I never seem to use.   If it were even smart enough to use the last setup I had it would go a long way to improve it. Or, even better, give me back the old menus so I can find things faster...

HyperTerminal sees a COM port but VISA does not

It should not be possible that HyperTerminal sees a COM port but VISA does not. Does anyone know why or have any ideas?
Here's some more info: I wrote a LabView (LV) program and deployed it (via the Application Builder) to some of our production department's PCs (some Windows XP and some Windows 7). We use it to set up products we design and manufacture through our device's USB serial port. The USB port is actually a virtual COM port (VCP) - a USB to Serial converter or "bridge". We have a custom driver for our device and since each device's USB bridge chip is programmed with a different serial number, every time we connect a new device to the PC the installer runs and assigns a new COM port number. This is so our customers can use multiple devices on a PC. Fine. On one of our production PC's we were close to COM900 ports (HyperTerminal sees only up to COM256) when suddenly Win7 would not allow any more. We were able to uninstall orphaned (non-present) COM ports from DeviceManager ("DM") by starting it from a command console (DOS window) with a special command-line switch, "set devmgr_show_nonpresent_devices=1" then "start devmgmt.msc" (I have this in a batch file). In DM View menu you can "Show hidden devices" and uninstall them as if they were connected. I've also tried uninstalling them the normal way when the device was actually connected. Either way, sometimes, not always, depending on the COM port number, after reusing that port number by installing a new device which picks up that old, freed-up number, LV VISA doesn't see it. In other words, when "Refresh" is clicked in the COM port VISA list box, any new devices installed should be and normally are seen. (Refresh is not needed if the application is started after the device's driver is installed. It is only need if the LV application is open with the new device is added.) However, HyperTerminal does see it and lists it in the Properties screen, the "Connect using..." list box. And the port works with HyperTerminal. (Of course we've tried rebooting after uninstalling and/or reinstalling the device, with the same results.)
When I've spoken to the NI Applications Engineers in the past about serial port issues (not about this problem) they have confirmed that if HyperTerminal can see the port then NI VISA should also see it. This is crazy. I am posting this in hope that someone can shed some light on this problem.
Thank you. -Ed

Good catch. Yes, we're using the Silicon Labs CP2102 and have created a "custom driver" installation package. Our new PCBs have a factory-programmed chip, so the PC reuses that COM port (COM3 on that PC). The problem is when we we re-program the CP2102 (setIDs exe) with our PID, and device strings (including the S/N), the PC runs our installer and assigns the next COM port number. I was hoping that maybe it would go up to 64K or something! Anyway, it surpassed COM256 but we ran into this problem when almost up to COM900.)
There is a registry entry for each SN device, which shows the assigned port. If we delete the key with regedit, the COM port database (don't know the file name) still has the port number. That's where Device Manager comes in. It seems to allow us to manually delete the ports, but it would take quite a while to delete 900. (I was trying to make a batch file for DevCon, but couldn't get it to see the HW ID of the devices in need of deletion.) So we tried manually deleting a few. After doing that Device Manager shows that Windows (and HyperTerminal) can reuse the port number when a new device (new SN) is installed, but, as you know from this post, VISA cannot see unless I manually add it in MAX.
I can't see how it has anything to do with the Silicon Labs driver. I might have to delete ALL of MY devices, then uninstall the driver files, reboot, then reinstall, as you suggested with the SiLabs driver. However, I don't see how VISA will now see these changes. VISA must have it's own database. That's what I thought deleting the ports in MAX would clear out, like a fresh install, but apparently not.
I've been through Silicon Labs' tech support on other issues and they've been able to help on some. I could run this by them.
BTW, have you noticed that Silicon Labs' chip and driver, while faster than NI's own "bridge" or serial-USB converter (I returned it because at $100 it's performance was worse than a $20 converter you can buy in Staples), is substantially slower than a real serial port? For example, our device can transmit 250 readings per second (a 12 byte string). A real serial port used with my LabView program can keep up, i.e.., graph & tabulate at that rate, but with a VCP we only get about 70 RPS. Same code. Can't figure this one out. They say the've tested the driver to 900 KB claimed. We're using 115KB here. Anyway, the VCP driver makes it look like a COM port which LV thinks it is. Why is it slower than a real port when the USB should be able to work almost 10 times faster than I'm using it (up to 1024 bytes per mSec per the full-speed USB spec, which SiLabs claims they verified)?
Anyway, I appreciate your help. Thanks! -Ed

Instrument not recognized - computer too fast for AT-GPIB/TNT board

I have a problem with a potentiostat (PAR 283) connected to ISA AT-GPIB/TNT (not pnp) board. I recently upgraded to a motherboard with 1.8GHz AMD processor. Potentiostat is recognized by other software as "28PD", "28PE" or sometimes just some garbage characters, instead of "283". I'm using driver version 1.6 (1.7 could not recognize the board). In "Measurement&Automation" potentiostat doesn't respond to *IDN? query (error EAB0). FRA analyzer connected to the same board is recognized without a problem. None of the Windows programs can control potentiostat (it's not recognized as "283). One DOS program, however, is able to recognize and control the potentiostat. I tested the whole system with 166MHz compu
ter, and everything worked fine.
My operating system is Win98
Does anyone have idea what could solve the problem?
Thanks
Darko

I don't necessarily have an answer to your problem, but I want to assure you those usually these problems are with the instrument. The IEEE 488.1 standard defines a 3-wire interlocked handshake to prevent any problems due to computer/device speeds.
However, some devices violate this protocol. They rely on internal timing to determine when things should occur on the bus. For example, the talker asserts the DAV hardware line to indicate that data is valid on the bus. Following that, the listener is supposed to latch the data from the bus and then assert NDAC to indicate that it has taken the data from the bus. At the moment that NDAC has been asserted, the talker is allowed to modify the data lines since they have already been latched. However, some devices have noted in the past that their is usually X amount of time that passes from when NDAC is asserted until the data is removed from the wire. In order to improve peformance, they actually assert NDAC sometime before the data has been latched, assuming that the data will be there when they are actually ready to receive this data. In the case of moving to a faster computer, this data is actually staying on the bus for a shorter period of time than expected and the device receives garbage data.
A similar phenomenon can occur when the device is the talker where is violates the proper 3-wire handshake.
Note that not all failures are intential on the side of the device, it could be a legitimate bug.
Now that I have given a somewhat long-winded description of how problems like this can manifest, I can give you a few recommendations.
1) Obtain a GPIB bus analyzer and examine the handshake sequence to determine where the failure is.
2) Talk to the equipment manufacturer to see if they have any updates
3) Modify the bus timing in NI-488.2 from 500ns to 2ms. This is not likely to work since you are on the receiving end.
4) Try to procure a GPIB-PCII/IIA board. This is a slower board that overall responds to handshaking slower than the AT-GPIB/TNT board and may mask the problem.
5) Increase your cable length (including to "illegal" lengths such as 8m). This can add propegation delays that can mask this problem. I have seen work in teh past with troubled instruments.
Good luck.

Command requires GPIB Controller to be Controller in Charge on dequeue element

I have some funky stuff going on in the attached VI. What the VI does is simply to log data to a text file. It is built up as a state machine. This VI's Create state is called from a mainVI (with the help of named queues). I get more than one error and it seems completely random.The error usually occurs if I stop the mainVI, then starts it again. So the second (or following) times the DP VI is called, I get random errors such as the two below:
Error 1 occurred at Dequeue Element in DP.vi->PSS.vi
Possible reason(s):
LabVIEW: An input parameter is invalid.
NI-488: Command requires GPIB Controller to be Controller in Charge.
Error 1 occurred at Close File in DP.vi->PSS.vi
Possible reason(s):
LabVIEW: An input parameter is invalid.
NI-488: Command requires GPIB Controller to be Controller in Charge.
Why is this? I don't even have a GPIB controller?
Solved!
Go to Solution.
Attachments:
DP.vi ‏61 KB

Siniz wrote:
blawson, I think you found the error!
So shift registers only gets uninitialized again if I close the actual VI, and not when I start executing it again? So in reality, they actually behave like real shift registers? I found two solutions to this problem.
1) To initialize the error shift register with an empty error constant.
2) To remove the wire from the shift register to the Write to Text File. This works since I always call the Create state first.
Which one would you recommend?
Also, what is the reason to keep the typedef strict? I have seen non-strict in other code.
Generally you should always explicitly initialize your shift registers unless you want to retain the values from one execution to the next. This is required for Action Engines but in most other cases you should use initialized shift registers to avoid side effects like you encountered in this application.
Mark Yedinak
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot

Sometimes GPIB controller did not command the instrument to talk while the high-level program did have "READ" command.

GPIB controller should send "UNL", "LA0", "TAxx" to command the instrument to talk. Though the program do have the "READ?" query, sometimes GPIB controller didn't send the above commands from NI Spy, resulting in the system is hanging there. It happens randomly.

HI,
It is not clear to me what is going on. I'd like to get more information.
Could you specify what programming language are you using?. Also, what functions are you using?. What driver version are you using?.
Include any information you think might be helpful. Also, attach the Spy capture.
DiegoF.

Receive error-1 at TCP/IP read - GPIB controller must be controller in charge

I have a stripped down version of Talk Module from the LV TCP/IP examples. All it does is execute one TCP/IP read of 512 bytes and reset the output error to no error if a timeout or close connection error occurs. I placed it in the main loop of my program so it executes one time each loop but I receive an Error 1 "GPIB controller must be controller in charge" when it runs. I then stop the program and get that same error from a different source before it exits. I know it works because I can set it up in a separate VI and it works fine. The program is controlling a GPIB power supply and a VXI chassis. Any ideas what could be causing the error? Thanks.
Jason

All the inputs are wired correctly and the connection is opened first. I am using hyperterminal on another computer to check out the connection. Sometimes after running the close connection VI, hyperterminal says the connection is still open. When the VI stops running, the connection is always lost and when the VI runs again, it seems to have no problem opening the connection on the same port. Thanks for the advice, I will check into it.
Jason

What kind of changes I have to do when I move from GPIB Controller to GPIB-USB Controller.

I want to know some information about GPIB-USB Controller. We are using National Instruments GPIB Controller to read and write data in a Instrument called Diagnostic Readout Box(DRB III) which will hook up with the Engine controller of the car. Now we plug-in the GPIB card in to the I/O slots of the Computer. Now, we want to use GPIB-USB Controller instead of GPIB Controller because of its portability and other features. However, we have developed some C++ applications which are available in the form of DLLs that will interact with the DRB III. Do we have to do any modifications in the coding of these applications when we move into the GPIB-USB controller?.

Once the GPIB-USB is configured, it behaves exactly like a PCI-GPIB board so you should not have to change your program. The GPIB-USB is only supported on Windows 95 and 98. If you are planning on using the GPIB-USB on 95\98 you would still use driver version 1.6 or 1.7. If you need to work on Windows Me or 2000, then you will need the GPIB-USB-A and driver version 1.0. The GPIB-USB is not supported on NT.
The USB-A driver does not allow you to use GPIB device templates. This issue is covered in Knowledge Base 266CNP00 (see link below).
http://ae.natinst.com/operations/ae/public.nsf/fca7838c4500dc10862567a100753500/862567530005f09f862569ec006c8bef?OpenDocument
Kim L.
Applications Engineering
National Instruments

Sbus and scsi gpib controllers

I have a Sun box with an sbus gpib controller in it and need to another
controller.
I am considering adding the scsi bus gpib controller. Is this possible?
My main concern is over driver/kernel parameter conflicts - is it a
valid concern?
Has anyone else done this? What were your results?
thx.

It is difficult to specify the expected lifetime of the card.
You said that your system works if you change the cables, making the total cable length shorter. Can you change the cables without making the total cable length shorter? This may indicate a faulty cable rather than a drive problem with the controller.
When your system fails does the card lose context? By this I mean do the registers reset to their default values? You should be able to determine this by checking status to see if the board is still listen/talk addressed or CIC like it was before the failure.
Also, can you be more specific about the failure? How do you know it has failed and what do you do to fix it?

AT-GPIB/TNT board driver with linux kernel 2.2.16

I have installed AT-GPIB/TNT board to my linux computer. I downloaded the driver 0.5.1 from ni web site, installed with no problem.
First I used Window98 OS to test my hardware setup. My GPIB board is connect HP E3632A DC Power supply. I can use window version's ibic to run ibfind, ibdev, ibwrt, ibrd. Then I booted to linux, load the drive. But when I run ibwrt, give "EBUS" error. I used small test program to verify that I would get the same error. But I couldn't get it from Windows.
Where is my problem? inside the driver? or linux driver setup?
Thank you in advance
Allyson

Version 0.6 of the BETA driver is available at:
http://www.ni.com/linux
See if this new release gives you better performance
Ryan Mosley

How do I create Labview VISA ports for *individual* GPIB instruments using Prologix USB GPIB controller?

Hello,
I'm trying to use a Prologix USB GPIB controller to control GPIB
instruments, and I would like to have a virtual serial (VISA) port for
*each instrument*, as is the case with a normal GPIB controller with a
standard NI driver. However this is not what the Prologix driver
provides -- it provides a single VISA virtual serial port for the
entire controller. To address the instrument with GPIB address 11,
you first send "++addr 11" to the serial port, and then you're talking
to instrument 11. However, this means I have to change all old
Labview programs.
Is it possible to create a "wrapper" function of some kind that will
define a virtual serial (VISA) port for each *instrument* on the
controller? For example, to talk to GPIB instrument 11, call it
ASRL3::11::INSTR, each time it is written to it would have to write to
the virtual serial port of the controller, say ASRL3::INSTR, first "+
+addr 11" and then the command that is sent to it.
A clearer explanation of the difference (i.e. incompatibility), and of
my objective:
1) A normal GPIB controller with NI driver: I go to the NI
Measurement & Instrumentation Panel, under GPIB, and Scan for
Instruments; all the live instruments show up; subsequently when I
want to use Labview programs that use VISA ports, the VISA drop boxes
allow me to choose a different port for each instrument, e.g.
"GPIB0::11::INSTR", "GPIB0::12::INSTR" would be instruments at
addresses GPIB 11 and GPIB 12.
2) The Prologix GPIB controller that plugs into a USB port: In
Labview you get a *single* VISA virtual serial port, ASRL3::INSTR, for
the entire GPIB0 controller. Therefore to address GPIB instrument 11,
you write "++addr 11" to the virtual serial port ASRL3::INSTR, and
then you are communicating with device 11, so you can write and read
ASRL3::INSTR to talk to that device. Then to talk to device GPIB 12,
you write "++addr 12" to the same VISA port, and then you are talking
to that device. The problem is that this requires recoding all
Labview code, whereas I would like to be able to use the same program
either with a normal or with a Prologix GPIB controller. Therefore, I
would like to create code that scans the controller for all GPIB
attached devices and creates VISA ports for all. Such ports, when
written to, would have to first write "++addr DEVICENUM" to
ASRL3::INSTR (i.e. the port of the GPIB-USB controller) where
DEVICENUM is the GPIB address of the instrument corresponding to that
port, and then would have to do a write or read or whatever function
is being done on that instrument VISA port.
I haven't figured out if it is possible to do this easily. Help and
pointers on where to look for hints would be much appreciated. Many
thanks!
Milos

My first impression is that if you don't want to make any changes at all to existing programs is that the wrapper you need is one around VISA. You would need to intercept all of the calls into the NI VISA driver. If you create your own visa32.dll and in there, change the addressing and then call the real VISA driver, you might (repeat, might) get something to work. If this would even work, you still might find that you have to make significant changes anyway. The serial connection is going to be considerably slower, and interface specific functions such as service request handling, bus triggering of multiple instruments, etc., would be difficult to impossible. This would be a lot of work, imho, to just save a couple of hundred dollars over a real GPIB controller. I've seen this Prologix device before and have even used NI's RS-232->GPIB controller. The Prologix intended use to me seems to me more for a hobbyist or very casual user. Of course, I'm used to having multiple GPIB instruments worth 10s/100s of thousands of dollars and the cost of an fully compliant GPIB controller is just lost in the noise.

NI MAX sees GPIB controller/board, but hangs on Troubleshooting test/Scan

Similar Messages

Maybe you are looking for