Writing C# Synchronized Read/Write Functions

[Schoon]

I am trying to create C# functions that will wait until the GPIB command has actually completed on the system that it is executed on.  That is, I dont want to just wait until the command has been run, I want to wait until the command is complete.  So for example, if I do a Device.Write(":INITiate:IMMediate" ) where the Device is a Spec A, I want to wait until the sweep is complete on the system before continuing in my code.  I think the Device.Wait(IOComplete) only waits for the issuing of the command to complete.  It doesnt wait for the sweep to finish (I know this because after I run Device.Write(":INITiate:IMMediate" ), then Device.Wait(IOComplete), then Device.Write(":CALCulate:MARKer:MAXimum" ), which does a peak search.  And I can see that on the Spec A, that the sweep isnt complete when the peak search is executed.

This is cutouts of the code I have so far.  I would also like to do a similar thing with Read (that is make sure the read is finished before moving on).  I feel there is a better way than what I have below (which seems to work ok, but it might just be because of the extra delay introduced by the *OPC? command.

 Board mGpibBoard = new Board(mGPIBConfiguration.GPIBBoardID);

mGpibBoard.AbortAsynchronousIO();

mGpibBoard.SendInterfaceClear();mGpibBoard.BecomeActiveController(true);

mGpibBoard.IOTimeout = GPIB_TIMEOUT_VALUE;

mGpibBoard.SetEndOnEndOfString = false;

mGpibBoard.SetEndOnWrite = true;

Device Unit = new Device(mGPIBConfiguration.GPIBBoardID, gpibUnit.PrimaryAddress);Unit.TerminateReadOnEndOfString = false;

Unit.IOTimeout = GPIB_TIMEOUT_VALUE;

Unit.SerialPollResponseTimeout = GPIB_TIMEOUT_VALUE;

Unit.SetEndOnEndOfString = false;

Unit.SetEndOnWrite = true;

public void SyncWrite(String command)

{

  if (Unit != null)

  {

    GpibStatusFlags wait_mask = (GpibStatusFlags.IOComplete | GpibStatusFlags.Timeout);     Unit.Write(command);

    Unit.Wait(wait_mask);

    bool synced = false;

    int counter = 0;

    while (!synced && counter < 100)

    {

      Unit.Write("*OPC?");

      Unit.Wait(wait_mask);

      String val = Unit.ReadString();

      Unit.Wait(wait_mask);

      synced = val.Trim().Replace("+","").Equals("1");

      counter++;

    }

  }

}

public String SyncRead(String command)

{

  String read_string = ""; if (Unit != null)

  {

    GpibStatusFlags wait_mask = (GpibStatusFlags.IOComplete | GpibStatusFlags.Timeout);

    Unit.Write(command);

    Unit.Wait(wait_mask);

    read_string = Unit.ReadString();

    Unit.Wait(wait_mask);

    bool synced = false;

    int counter = 0;

    while (!synced && counter < 100)

    {

      Unit.Write("*OPC?");

      Unit.Wait(wait_mask);

      String val = Unit.ReadString();

      Unit.Wait(wait_mask);

      synced = val.Trim().Replace("+", "").Equals("1");

      counter++;

    }

  }

  return read_string;

}

Thanks,

Nick

[Burban]

I am unaware of a direct way to program this.  In LabVIEW, we usually use a small delay between the GPIB Write and Read on the instrument.  I would recommend the same to you.  Your extra call will accomplish this, or you can program a delay directly.

[Schoon]

The problem with delays is that they system setups the software will be running on is different.  One customer might be running a USB GPIB device, while another is using a high speed PCI GPIB device.  I would like to be able to run the set of commands as fast as possible for a given setup.  Otherwise I have to run the worst case delays, which is pretty slow (considering that what we are doing is adjusting systems, doing a scan on the Spec A, then doing a Peak Search, over and over).  If we need a worst case delay of 500ms in between each, this adds an extraordinarily large amount of time to the test.  Hoping for a programmable solution here.

Thanks,

Nick

[Burban]

The time required to complete an operation is different for every operation on every instrumentand thus the ability to know when the operation is complete is not built into NI-488.2.  This kind of functionality would have to be instrument specific.