AnsweredAssumed Answered

53210A Problems with communication over GPIB

Question asked by weicher on Jan 11, 2012
Latest reply on Jan 27, 2012 by weicher

Like • Show 0 Likes0
Comment • 5

Hi!

Some years ago I made a DLL for the 53132A Counter. With this DLL, the 53132A Counter, the NI GPIB and a gate time of 40mSec we can make a single frequency measurement within ~60mSec.

We use the counters on the machines in our crystal tuning fork production, speed an reliability are a absolute must!

On Monday I got the first 53210A Counter and I'm not able to get it to work :-(

It seems not possible to build up the complete programming string and send this string to the counter.
So I tried the following programming sequence:

MC_METHOD_IMP THP53210A::Reset ()
{
     bool res = false;
     try
     {
          res = mGpib->DeviceClear (mDevice);
          if (res)
               res = mGpib->Send (mDevice, "*RST;*CLS;*SRE 0;*ESE 0;:STAT:PRES");

          if (!res)
               gError->DoSetError (ErrorStr().c_str(), "Counter::Reset");

          res = mGpib->Local (mDevice);

          CloseGpib ();
     }
     catch (...)
     {
          return false;
     }

     return res;
}

OpenGpib ();
mGpib->Send (mDevice, "CALC:STATE OFF");
mGpib->Send (mDevice, "CONF:FREQ 3.276800e+004,DEF"); // depends on user parameter
mGpib->Send (mDevice, "INP:PROB 1;IMP 50;COUP AC;FILT:LPASS:STATE OFF"); // depends on user setting
mGpib->Send (mDevice, "SENSE:FREQ:GATE:POL POS;TIME 4.000e-002"); // depends on user setting
mGpib->Send (mDevice, "SENS:ROSC:SOUR INT"); // depends on user setting
mGpib->Send (mDevice, "FORM:DATA ASCii");
mGpib->Send (mDevice, "DISP:WIND:STAT ON"); // depends on user setting
mGpib->Send (mDevice, "TRIG:SOUR BUS"); // automatic: BUS, manual: IMM
mGpib->Send (mDevice, "*SRE 16;*ESE 0;*OPC"); // automatic: "*SRE 16;*ESE 0;*OPC", manual: "*SRE 0;*ESE 0;*OPC"

The counter reports no error after this code.

Sometimes the Reset Function is not able to reset the counter. I have to switch off and on the counter (that is NOT acceptable).

It seems that the commands must be in a strict order.
ex. If I send the "TRIG:SOUR BUS" command after "CALC:STATE OFF" then the question "TRIG:SOUR?" after the above code returns "IMM".

My first try to trigger a measurement was with the GPIB GET command (ibtrg) -> "trigger ignored".

Then I did "INIT;*TRG;FETC?" then I could make a measurement. But it's so slow that it's unusable.

Since I can not believe that Agilent produces a Counter which is unusable, I must do something completly wrong.
Can please somebody or other help me to get this thing to work?

Best regards
Walter

No one else has this question

Outcomes

lhornburg

Jan 13, 2012 1:21 PM

Hi Walter,

Thank you for purchasing the new 53210A counter. I’m sorry the instrument is not cooperating.

There are 53210A commands that are sequence dependent; however, in the code you provided there are no such dependencies. I executed the commands in your sequence and queried the trigger source. ‘BUS was returned as expected. Sending TRIG:SOUR BUS immediately after CALC:STATE:OFF also returned the correct source:

-> *rst;:calc:state off;:trig:sour bus;:trig:sour?
<- BUS

Regarding the “trigger ignored” error, the 53210A must be set to the ‘wait-for-trigger state’ before triggers are accepted. The INITiate:Immediate command does this. The commands you used to configure the counter occur while the counter is in its ‘idle state’. Sending INIT moves the counter to the ‘wait-for-trigger’ state. When a trigger is received the counter is now in the ‘triggered’ state. When the signal from the specified gate source is received, the measurement is taken.

I am concerned that the Reset function on occasion is not able to reset the counter. Can you provide more information on what is occurring before and after the reset is issued?

You mentioned writing a DLL for the 53132A counter. Were you aware of the compatibility mode feature of the 53210A? The 53200A series counters will eventually replace the 531xxA counters. To help in the migration to the new counters, the 53200A models are compatible with the 531xxA models as follows:

53210A   53181A
53220A   53131A
53230A   53132A

In compatibility mode the 53200A series counter can execute the commands of its corresponding 531xxA counter. This allows the 53200A counters to be integrated into systems currently containing 531xxA counters and leverage existing code.

Actions

weicher Jan 19, 2012 5:19 AM

Hi lhornburg,

sorry for the delay, but I have a few building sites ;-)

"
-> *rst;:calc:state off;:trig:sour bus;:trig:sour?
<- BUS

"

Ok, that works... but when I send all may other commands after :trig:sour bus and asking at the end of the command sequence then I still get IMM.

But I got some help from Computer Controls and try to send a new INPut Subsystem string. But I always get the error -113, "Undefined header"

     // INPut Subsystem
     mInpSubSyst = "INP:PROB";
     if (mAttenuate == 0)
          mInpSubSyst += " 10;";
     else
          mInpSubSyst += " 1;";

     if (mImpedance == 0)
          mInpSubSyst += "IMP 50;";
     else
          mInpSubSyst += "IMP 1E6;";

     if (mCoupling == 0)
          mInpSubSyst += "COUP AC;";
     else
          mInpSubSyst += "COUP DC;";

     if (mTrigSlope == 0)
          mInpSubSyst += "SLOP POS;";
     else
          mInpSubSyst += "SLOP NEG;";

     if (mTrigSense == 0)
          mInpSubSyst += "NREJ OFF;";
     else
          mInpSubSyst += "NREJ ON;";

     mInpSubSyst += "LEV:ABS " + mTrigLevel + ";";

     mInpSubSyst += "FILT:LPASS:STATE";
     if (mFilter == 0)
          mInpSubSyst += " ON";
     else
          mInpSubSyst += " OFF";

this results is a string like "INP:PROB 1;IMP 50;COUP AC;SLOP POS;NREJ ON;LEV:ABS 1.000e-001;FILT:LPASS:STATE OFF"

Whats wrong with this string?

"
Were you aware of the compatibility mode feature of the 53210A?
"

Yes, but it did not work. I think it's because I used ibtrg() and *DDT #15READ?

best regards
Walter

Actions

weicher Jan 19, 2012 5:12 AM

with the string ""INP:PROB 1;IMP 50;COUP AC;SLOP POS;NREJ ON;LEV:ABS 1.000e-001;:INP:FILT:LPASS:STATE OFF" I dont get an error.

The measurement is started with "*TRG;DATA:REM? 1, WAIT" then I get the frequency with ibrd(...) but it only works for the first time. When I again send the command "*TRG;DATA:REM? 1, WAIT" I get -230, "Data corrupt or stale"

What is wrong here?

But I would like it mutch more when I could use ibtrg() and then the counter makes a measurement and when done sets the SRQ and then I can read the frequency.

Why I want this:
On our CrystalTuners after fixing and contacting the crystal two threads are started, the first one measures the frequency of the crystal and the second is the machine vision which searches the tuning space on the crystal. So when I sent the GET (ibtrg()) then the counter starts measuring and the measure thread sleeps on WaitForSingleObject (srq) so the machine vision thread can run at least for gatetime milliseconds. Normally the machine vision thread is finished before the SRQ from the counter so we save a lot time (We produce 2'000'000 Crystals per day so 2.0e6 * 40e-3 = 80000 seconds).

As a little motivation boost for you, we have about 50 53181A counters and more than 500 53132A counter in our fab ;-)

Actions

lhornburg

Jan 20, 2012 3:22 PM

Hi Walter,

I am not sure why the trigger source query is returning the wrong source unless a reset or preset is occurring somewhere.

As you discovered, you do not get an error with the string:

INP:PROB 1;IMP 50;COUP AC;SLOP POS;NREJ ON;LEV:ABS 1.000e-001;:INP:FILT:LPASS:STATE OFF

The reason is the command key words: PROB, IMP, COUP, SLOP, NREJ, LEV, and FILT are peers (i.e. at the same command hierarchy level). This means each is directly under the root keyword INP and are separated by a semicolon (;). The undefined header error was caused by the ‘FILT:LPASS:STAT OFF’ command because in the previous command the keywords LEV:ABS were specified. FILT is a peer of LEV and not ABS (a lower level). Therefore the “FILT” command must start at the root and be separated from the previous command by ;: (i.e. ;:INP:FILT:LPASS:STATE OFF).

If ABS had not been specified, your original string would have executed without error.

TRG;DATA:REM? 1, WAIT generates error -230, “Data corrupt or stale” the second time it is executed because there is no data to retrieve. The counter was not re-initiated after the first reading was taken, thus the trigger (TRG) was ignored. Sending a trigger will not start an actual measurement unless the counter is previously initiated by sending INITiate:IMMediate or the trigger count is set to a value > 1 (assuming the gate source is IMMediate). The attached figure from the 53210A user guide illustrates this:

For trigger counts > 1, the counter will remain in the ‘wait for trigger state’ until the specified number of triggers have been accepted. The counter does not have to be re-initiated prior to each trigger in the trigger count.

To have the counter generate an SRQ when the reading is complete a process similar to the following can be used:

CONF:FREQ                                        // configure measurement
     TRIG:SOUR <source>                                                // set the trigger source
    TRIG:COUN <count>                                                 // set the trigger count: 1 or ‘n’ number of readings
DATA:POINts:EVENt:THReshold <count>              // set the reading threshold to generate SRQ: same as trigger count
STATus:OPERation:ENABle 4096                                // unmask reading threshold bit (12) in standard operation register
*SRE 128                                                                              // unmask standard operation summary bit (7) in status byte register
INIT                                        // initiate counter
TRG                                        // trigger the counter
SPOLL                                    // poll the status byte for reading threshold reached
   FETC?                                 // fetch (read) the reading(s) from the output buffer
STATus:OPERation:EVENt             // read the event register to clear bit 12 for the next threshold event

TRG                        // trigger the counter
SPOLL
FETC?                                                    //fetch the next reading or set of readings
STATus:OPERation:EVENt             // read event register to clear bit

Attachments

53210A_manual_snippet.jpg38.6 KB

Actions

weicher Jan 27, 2012 6:28 AM

Hi lhornburg,

I got it to work, but I have to do this for each measurement:

mGpib->Send (mDevice, "INIT");
mGpib->Trigger (mDevice);
if (WaitForSingleObject (mSRQEvent, mTimeout) == WAIT_OBJECT_0)
{
    char poll = mGpib->SerialPoll (mDevice);
    if (poll == 128)
    {
      mGpib->Send (mDevice, "FETC?");
      std::string data = mGpib->Enter (mDevice);
    }
}

When sending the programming strings to the counter, before sending the display command strings "DISP:WIND:STAT ON" or "DISP:WIND:STAT OFF" I have to do a Sleep (500)! Without this Sleep() the counter is dead! Only switching off and on brings it back to life.

Best regards
Walter

Actions

53210A Problems with communication over GPIB

Outcomes

Attachments

Related Content

Recommended Content