Agilent 34972A Error 261

[harisskriss85_85]

Hi,

Thanks for your suggestions. I m currently looking on hardware and firmware revisions point of view. One more thing i have noticed is, I dont recieve this error when only this agilent device is running. When this device is run along with other agilent or PSI (device: NetScanner Model 98RK-1) then i recieve this error. I dont understand the relation. 

[Minions]

Now that we have established that the equipment functions properly, try to run your vi in debug mode.  If the error does not come back, then it is a race condition at that vi level.  Otherwise, open one of the lower level vi's and try that in debug mode.  If the error does not occur, then that is where the race condition is present.  Continue to do this to eliminate this possibility in all of your vi's.  However, if the error occurs, check to make sure that vi that flags the error is not from an earlier or later version of the device drivers used in the rest of your project.

Also, how is this Agilent Data Acquisition Switch connected to your PC (LAN or USB) and what modules are you using in them (34901A, 34902A,...) ?

[harisskriss85_85]

Hi,

Thanks. I only get this error in the measurement device, it doesnt flag or show error in my VI. I connect using LAN and module thats gioving problem is 34972A. 

[Minions]

I have had similar issues with these instruments under certain conditions.  Did you configure the PT100 as a 4-wire measurement and then try to redefine it as a 2-wire?  There is some type of background conditions where these units hold the previous paired source channel configuration without releasing it and flags errors.

I typically program with these meters using SCPI and the VISA (Write, Read, and Close) vi's.  There are a number of different ways to control these instruments.  There is the default CONFiguration or MEASurement commands then there are the SENSe and others. 

The good thing is that this is not an execution error, but rather an instrument error which points at the order of performing tasks.  Make sure that you have concluded all configuration and trigger commands prior to requesting scan data from the device.  Things to consider are:

• make sure that you close the device if you are going to initialize the device again
• limit the number of triggers to end the scan
• make sure that the instrument power-on setting are for factory reset (Last may hold an invalid condition)
• follow commands in Instrument manual for how: "To Determine When a Command Sequence is Completed"

[harisskriss85_85]

Hi 

Thanks for your suggestions. I will work on them and see if i can solve the problem. Thanks alot

[harisskriss85_85]

Hi

The hardware and firmware revisions looks fine. I still cant figure out the possible reason. 

[Minions]

It still may come down to a race condition; however, this might be with the traffic sent across LXI.

Much of your code allows for things to happen on their own and not in a controlled sequential manner.  You are only using a single LXI bus/controller yet your commands to the two instruments are independent.  It may be that after sending the first command to one instrument, that it immediately sends the next command to the other. 

What may occur is:

1. The second command corrupts the reception of the first command being received on the first instrument.
2. A response placed on the bus from the first instrument command occurs prior to the sending of the second command.  The second instrument now reads the response from the first as a command and fails that as an unknown command, then will try to attempt the actual command next and respond (or not) accordingly.

Make sure that a command eliciting a response from a piece of equipment is read and handled prior to sending another command across the same bus.

[harisskriss85_85]

Thanks, will check the race condition.

[harisskriss85_85]

Hi,

Thanks for your time and suggestions.

The two Agilents are run on different connections. One is using TCP the other using COMM port.

The problem comes from the three sub VIs (configure trigger, Event status and Read) that are used by both the Agilents.

When I changed the name for the subVIs ( two different names for two Agilents) there is no Error seen.

Would appreciate if you can help me understand the error further and is this the bestway to solve this error or further suggestions.

Thanks

[Minions · Accepted solution]

This makes a little more sense.  Seeing that you are not talking to both meters through the same channels (both Serial Comm or Ethernet), the Max software may have been 'linking' the two meters as one with two connection choices.  By changing the names of those two meters, it may have broken that 'percieved' configuration and allow them to be treated as two separate entities.  Just a hunch.

Usually, the same equipment types would tend be grouped together by controller ports (GPIB, USB, PXI/cPCI, Firewire, Ethernet through a hub, and RS-232/485) and functions (Meter, Supplies, Relays, Loads, Waveform Generators, Digitizers/Scopes, Analogs,...).

In the future, I would try to keep the same communication busses with the same types of equipment.