[Problem] NI-488.2 problems accessing multiple DC PSUs on the same GPIB bus...

[ChristopherPovey]

We have a one Test Set containing two XHR 40-25 PSUs.  These are linked to NI-488.2 card and the Test Set uses v1.7 of the driver and our software works perfectly.  In this Test Set, one PSU provides 28V DC and the other provides 115V AC (via a transformer).

 

We have another Test Set containing the same two XHR-40-25 PSUs and an AC PSU.  One DC PSU provides 28V DC and the AC PSU provides the 115V.  The PSUs are all linked together to a NI-488.2 card and the Test Set uses v2.4 of the driver.   The same software as above initialises the DC PSUs using NI IVI calls.  When DC PSU is initialised it errors with error code 8 – “Data Sent without a Query Being Sent”.  The GPIB addresses for the DC PSUs are the same on both Test Sets (addresses 2 and 3).  ACPSU is on address 8.  There is also a DMM on the GPIB bus on both Test Sets (which seems to be unaffected by this problem).

 

We also have a TestStand sequence which initialises the two DC PSUs then the AC PSU using IVI Tool Custom Step calls.  When DC PSU 2 is initialised, DC PSU 1 errors (I see an error LED on the PSU).  The error code is 8 – “Data Sent without a Query Being Sent”.  I worked round this by initialising DC PSU 1, then calling IVI Pwr Custom Step to set the voltage to zero and disconnecting the PSU.  I then initialised DC PSU 2.  DC PSU 1 then did not error.  For consistency I also call IVI Pwr Custom Step to set the voltage to zero and disconnected the PSU.   Though I don’t understand why this is needed?

 

Why am I getting these errors?  Has there been a change in the drivers between v1.7 and v2.4 in this area?

 

Thanks.

[rsw]

Hi Christopher,

The core issues between those driver versions is the inclusion of USB and ENET hardware for support, and a few minor bug fixes. The error you get refers to the following:

 EDMA (8)

Error Condition:
Error occurs while using DMA for data transfers.
Description:
EDMA occurs if a system DMA error is encountered when the NI-488.2 driver attempts to transfer data over the GPIB using DMA.
Solutions:

• You can correct the EDMA problem in hardware by using the GPIB Configuration Utility to reconfigure your GPIB board, so that it does not use a DMA resource.
  
• You can correct the EDMA problem in software by using the ibdma function to disable DMA.

If you could try that and let me know if it helps.

All the best,

[ChristopherPovey]

Ok, thanks, we will give that a go. 

We did observe the following yesterday.  On the front panels of the two DC PSU is a green "ADR" backlit LED.  This is normally off.  When we step through our code (be it TestStand IVI CS or CVI IVI calls), each time the PSU was communicated with this ADR LED flashed.  We did observe that when the error occurs, the ADR LED on both PSUs flash, and then the one not being communicated with errors (see a red ERR backlit LED is set).  For example:

Comm with PSU1 (GPIB Addr 2) -> PSU1 "ADR" flashes.

Comm with PSU2 (GPIB Addr 3) -> PSU1 "ADR" and PSU2 "ADR" flashes.  PSU1 "ERR" comes on.

So even though the steps/function calls are addressing a specific PSU (by virtual named GPIB addresses), when we switch to another PSU, the first one seems to "see" and attempts to process the message.  It then errors.  Would this be a symptom of the DMA issue?

[rsw]

Hi Christopher,

It sounds like a similar issue and most likely linked to the DMA issue, if the card attempts to DMA the information out, the speed is increased as it's direct from memory and may result in the PSU's either being unable to read correctly, fast enough or out of sync. Hopefully it is this issue as its a nice fix, however if this doesn't solve the issue if you could perform the actions shown in the following document's and I will review whats going on with the communication layer.

NI Spy and GPIB Analyzer

Thanks,

[ChristopherPovey]

We are having trouble locating the DMA setting in GPIB tools.  I should clarify that we have a GPIB card (not +) and running v2.4 of the drivers.  I cannot see any EDMA entries from properties in MAX.  Can you provided step by step instructions to this setting?

Thanks.

[rsw]

Hi Christopher,

If you go to Windows Device Manager via right clicking on My Computer > Properties > Hardware tab > Device Manager and expand the GPIB Listing. If you double click on your GPIB card and go to resources to see if DMA is listed as a resource and to ensure no conflicts are shown. Something I should have asked in my first reply, which card are your using and which type of interface i.e. USB/PCI.

If no DMA and no Conflicts exist then please drop me the NI Spy and GPIB captures listed in the previous post and I will review them as best I can.

All the best,

[ChristopherPovey]

"Something I should have asked in my first reply, which card are your using and which type of interface i.e. USB/PCI."

It is a PCI-GPIB Card.  I would have to ask the hardware guys for exact version numbers etc.

I can do a NI Capture, but not a GPIB capture as it is not a GPIB+ card...

We will check out the DMA shortly.

Thanks.

Edit:

Had a look at Device Manager entry.  There are no conflicts, but also no DMA entry.  The only entries are:

Memory Range D5004000-D50047FF

Memory Range D5000000-D5003FFF

IRQ 18

Message Edited by ChristopherPovey on 09-23-2009 10:00 AM

[rsw]

Hi Christopher,

If possible could you also attach your teststand sequence and associated VI's and I will try it out here with a simulated device to rule the driver out. DMA doesn't look like a huge issue then if no conflicts are registered then either the card doesn't support DMA or the OS is taking care of that itself.

Thanks,

[ChristopherPovey]

Attached is the TestStand Sequence that works (with the work around).

If you skip steps 2 and 4 it will fail (first test case will return 8).

"HUD_DC_PSU_x" are mappings in MAX to actual DC PSUs.

The other issue has also has a work around now too.  If we initialise the AC PSU (Address: 😎 before the DC PSU (Address: 2) then there are no errors from either PSU.  Though we need to do more checking to confirm this as the ACPSU does not have a visible error LED.

Thanks.

[rsw]

Hi Christopher,

I've gone through your teststand sequence and see nothing untoward, sadly the simulator I am using to attempt to replicate the issue won't perform the actions I require to confirm this same issue under the 2.7 driver. I would recommend seeing if the workaround you've found solves the issue although I cannot find any information as to why the driver version differences have such an effect on your teststand sequence.

Sorry I can't be or more help and give you a definitive answer to this one, I will keep checking through our databases to see if this issue has ever appeared before.

All the best,