0

Using the *OPC?[I!] command

I have been writing a lot of closed loop procedures recently and need some clarification on when to use the *OPC?[I!] command with the SCPI, IEEE, & IEEE2 FSC's. Some instruments take longer than other to complete their routines and need time to finish before receiving another command. Sometimes, MetCal automatically waits for the command to complete, but other times it does not so I have to add the *OPC?[I!] command to the end of the line to wait for a Operation Complete return value or a delay [D###] command. I have also noticed that many instruments return different values for the *OPC? command. Some return a 1 integer signifying the operation is completed. But others, such as the 3325B, return the same command that you just sent. For example:

###############################################

IEEE       [@3325B] FU1;*OPC?[I!]

# Turns 3325B Sine wave function ON and returns "FU1"

#############################################

SCPI       [@PSA]*RST;*OPC?[I!]

# resets PSA and returns "+1"

#############################################

SCPI       [@PSA]INST MRECEIVE;*OPC?[I!]

# Changes PSA to Measurement Receiver function and returns nothing. Just hangs up waiting for a response that never comes.

##############################################

IEEE       [@3325B]AC;*OPC?[I!]

# Auto Cal's the 3325B and returns nothing. Does not hang, but nothing is returned so I need to use a delay command [D5000] to give the 3325B time to complete its routine before pressing on to the next MetCal command.

IEEE       [@3325B]AC[D5000]

# Auto Cal's the 3325B and waits 5000 milliseconds to move to the next line of code.

###########################################

Obviously, I cannot use it after every command because some instruments have nothing to return even after receiving a command and completing it. There has to be some rhyme or reason of when to use a *OPC? command, when to use a [D###] command, and when to use nothing.

 

Some further explanation into this topic would be greatly appreciated.

14 comments

Date Votes
0
Avatar
Dale Chaudiere

Never, never use *OPC? with the IEEE2 or SCPI FSC.   These FSC automatically setup the device to assert a SRQ request when the Operation Complete (OPC) bit is set in the Event Status Register (ESR).    Please read the IEEE2/SCPI help file.   It has full examples of command and query processing/overhead when an IEEE2 or SCPI FSC is executed.   The only thing that the SCPI FSC does is send "SYST:ERR?" when any of the error bits are set in the ESR.

If your device is controlled by an IEEE-488 interface and does not work with the IEEE2 or SCPI FSC, then and only then you can append ";*OPC?[I!]" to the end of your command strings.   Do not append ';*OPC?' to the end of queries.

However, if an error occurs when using ';*OPC?[I!]" the IEEE statement may simply timeout.   I more robust solution is to write a "Wait for OPC" subprocedure that sends *OPC, and then send *ESR? every 100 ms to determine when OPC (bit 0) is set.  You can also check the error bits (1, 2, 3, & 4) at the same time.

0
Avatar
Christian Tarr

Thanks for the response. That is good to know.

If my device isn't SCPI compliant, how do I choose beteen using the IEEE and IEEE2 FSC's? Currnetly, I just use trial and error. I start with a SCPI command/query and if there is a problem sending the command or returning the data I try the IEEE FSC, which usually works.

0
Avatar
Dale Chaudiere

SCPI compliance requires IEEE-488.2 compliance.   The IEEE2 and SCPI FSCs can only be used if the IEEE-488.2 Operation Complete (OPC) Service Request (SRQ) process works correctly as defined by the standard.  Therefore, if you device is not SCPI compliant, you cannot use the IEEE2 or SCPI FSC.   Again, the only difference between the IEEE2 and SCPI is the SCPI FSC sends "SYST:ERR?" is any of the error bits are set in the Extended Status Register (ESR).

Many devices support IEEE-488 Common Commands like *RST, *IDN?, and *OPC, but do not uphold the IEEE-488.2 Operation Complete SRQ requirement.

0
Avatar
Christian Tarr

I am confused as to why a warranted Fluke procedure uses the *OPC? command with the SCPI FSC. The Agilent E444x Fluke Gold procedure developed by CLS use the *OPC?[I!] after several SCPI commands? For example, for the Self Cal of the E444x the following code is used:

SCPI     *RST;*OPC?[i]

IEEE     :CAL:ALL?[D30000][I]

EVAL  -E  (MEM==0)   :   INTERNAL ALIGNMENT \ SELF CALIBRATION

IF          MEM != 0

DISP    UNIT FAILS SELF CALIBRATION. PROCEDURE WILL NOW TERMINATE.

END

ENDIF

 

Wouldn't it be better to do the following:

SCPI     *RST

SCPI     [T240000]CAL:ALL?[I]

EVAL  -E  (MEM==0)   :   INTERNAL ALIGNMENT \ SELF CALIBRATION

IF          MEM != 0

DISP    UNIT FAILS SELF CALIBRATION. PROCEDURE WILL NOW TERMINATE.

END

ENDIF

0
Avatar
Dale Chaudiere

That would be a bug.   I will log it in our tracking system.

Basically, adding ;*OPC?[I!] to the end of a SCPI command is a NO-OP.   By the time the *OPC? is send, all pending operations have already been automatically handled by the SCPI FSC overhead.

SCPI  *RST;*OPC?[I1]

becomes two separate IEEE-488 bus transactions:

1. Send "*CLS;*SRE 96;*ESE 61;*RST;*OPC".   Wait for an SRQ from GPIB board 0.  Serial poll the UUT address to determine if it asserted the SRQ.  If so, send ESR? to read the Extended Status Register.  If any of the error bits are set, send "SYST:ERR?" and display the returned error string until 0,"No Error" is returned.  If no error bits are set in the ESR, check to see if the Operation Complete (OPC) bits is set.  If so, return.

2. Send "*CLS;*SRE 112;*ESE 60;*OPC?".   Wait for an SRQ from GPIB board 0.  Serial poll the UUT address to determine if it asserted the SRQ.  If so, check to see if the Messsage Available (MAV) bit is set in the serial status byte.  If so, read the response from the device.  In this case a "1" indicating that all pending operations are complete.

0
Avatar
Michael Schwartz

The Answer to that question is simple. “I am a control freak! “

I use the IEEE FSC all the time. If I need to send an *OPC?[i] I will write it in the code.  

I am a little old school in how I write procedures.  I believe if it is not broke, don’t fix it.  I have never had an error with the IEEE FSC I could not fix.  And it works in ALL version of MT/CAL.

Also we do a lot of complex procedures, some from smaller manufacturers who sometimes read the standards differently.  I like the low level control of the IEEE FSC.  I can handle things like *OPC? that returns a 0 indicating the unit is busy and will return a 1 when it is finished, so the *OPC? has to be placed in a loop.

In the E444x Procedures all the IEEE FSCs were changed to SCPI after the procedure was fully developed and tested.  

0
Avatar
Michael Schwartz

You and I have a different definition of a “BUG”.  

For me a BUG means, the software is not working.  It is broken and the customer needs it fixed ASAP.  And I need to move this to the top of my priority list.

I am sure, there are a thousand better ways of resetting the UUT and running a selfTest.  But this is more of a code improvement that comes with the cost of having to be tested before it is released.   That is always the constraint when writing automation.  We only have access to the units for a limited amount.  We have to make the tradeoffs between speed, unhandled failures and elegance in code.  For us Error Free code is our top priority.

When we made the change from the IEEE FCS to the SCPI FCS, we ran the procedure from End-to-End and found issues.  We changed back IEEE Calls that could not be executed with the SCPI FSC, that is why there are some IEEE Calls in the code. .  Because that line of code worked with the IEEE

Personally I like the KISS method I learned in my Army Metrology Training, KEEP IT SIMPLE STUPID!  IEEE *RST;*OPC?[1] works just fine in all MET/CAL Version.  We avoid using SCPI FCS because the UUT has to correctly implement "*CLS,*SRE 96, *SRE 112, *ESE 61, &*OPC.  If not the code breaks.

I don’t mean to be conferential, just that it is not really a bug, it is more of a difference in programming styles.  If the code would have been left with the IEEE FSC calls in the first place, then the use of *OPC would not have been in question.

I do have PSA on my desk and I will test the updates that Tarzan has posted.

0
Avatar
Chad D.

This thread is a good discussion!  Thanks to all who are contributing and reading.

It sounds like we do have different definitions of what constitutes a bug.  We know that Fluke Gold customers expect to use warranted procedure code as a reference source for how to write MET/CAL code.  If we ship dead (commented or skipped) or benign code which serves no purpose (as Dale described above) in a procedure, this is a bug to us.  Sure, the bug may be tracked at a different priority level than a bug which prevents operation or breaks functionality, but it is still a bug.  To follow along these same lines, typographical or grammatical errors in operator prompts would also constitute a bug, even when the instruction is still clearly conveyed.  In this fashion, we treat warranted procedure source code as if it were an extension of the product's documentation.

-Chad

0
Avatar
Michael Schwartz

Along those lines, I would like to point out the Agilent E444xA procedures developed by Cal Lab Solutions are not a Fluke Gold Procedure.  I know there are lots of Fluke Gold procedures developed by contractors, but this one Cal Lab Solutions retains all rights and ownership of the procedure. 

  1.007  DISP         [32]               PLEASE NOTE!
  1.007  DISP         This procedure is © 2007, Cal Lab Solutions.
  1.007  DISP         [32]            All rights reserved.
  1.007  DISP
  1.007  DISP         This procedure is licensed for unlimited use under the
  1.007  DISP         Fluke MET/SUPPORT Gold user agreement.  Redistribution
  1.007  DISP         of this procedure in part or in full is strictly
  1.007  DISP         prohibited.

This is why the E444xA does not look like other Fluke Gold procedures.  And it was never meant to be a training tool.  One of my pet paves is when someone copies a procedure, changes some specifications and says “I am a programmer!”  It is a lot of hard work to make a procedure rock solid.  It is even more work to develop a system of writing MET/CAL® procedures that are rock-solid and easy to support and maintain. 

If any customers have open support issues (Real BUG Reports) related to the E444xA procedures Email me at MSchwartz@CalLabSolutions.com  WE WILL GET THEM RESOLVED.  

Note:  We will have to verity that you as some point an active Fluke Gold member

0
Avatar
Christian Tarr

I think CLS and Fluke are both making valid points. From a commercial point of view, a developer must produce a usable product that meets the customer’s needs as quickly as possible. Even though the code might not be optimized to its fullest; if it works, publish it. However, over the lifecycle of the product, improvements and optimizations could be made to improve reliability and efficiency. If you find redundant code, then it would be best to remove or fix it as time allows. But we shouldn't be hung up with making the code absolutely perfect from the beginning or the product will take too long to finish.

I have been posting most of my questions to this forum instead of contacting Fluke support directly so more people can learn from our questions. When I have a question about programming in C++ or VB, there is enough info on the internet to answer almost any question I might have. Met/Cal programming is a different story since the user base is much smaller. The community needs as much info as possible posted to this forum to help out new and seasoned developer alike. My plan is to start adding tutorials on how to code some of the more complex things in Met/Cal so everyone can benefit. I also look forward to others critiquing my code so I can become a better developer.

0
Avatar
Michael Schwartz

Tarzan217,

To answer your question:

IEEE       [@3325B] FU1;*OPC?[I!]
SCPI       [@PSA]*RST;*OPC?[I!]
SCPI       [@PSA]INST MRECEIVE;*OPC?[I!]
IEEE       [@3325B]AC;*OPC?[I!]
IEEE       [@3325B]AC[D5000]

Don’t look for perfect.  Automation is all about efficiencies!  It is all about the technician getting calibrations out the door with minimal problems.  SO Every one of the above examples are correct!  
If you are going to apply LEAN Programming Principles; if the code runs, leave it alone.  If it breaks and it requires a simple fix, don’t rewrite the whole thing, just fix it and move one.  But if it is not a simple fix, take the time to restructure the code better.  (Yes it is hard to know when to fix vs re-structure.)

COPY & PASTE is BAD!.. every time you copy and paste you are copying errors.  You really have to take a step back and say there has to be a better way to do this IN LESS CODE!  Yes MET/CAL® have limited programming features.  But you should cringe every time you in the Control V Key.

We can Cal Lab Solutions DONOT MIX UUT code and standard code.  This allows us to swap standards without touching the UUT Procedure.  So we only have 1 UUT procedure that we have to support and maintain.  We seldom us FSC, all of our driver calls are made in a sub procedure for that standard.  And just like the UUT code, we only have one place where we need to maintain that code.  We use a configuration file to bring the UUT and Standard code together, there we can customize it to the customer or station. 

Appling LEAN Programming Principles, you need to write less code, reuse more of your existing code.  We have always been a 2-3 man operation, our procedure list is the largest in the industry covering everything from Phys-D to High end LTE Test systems.  We must be doing something wright.

0
Avatar
Samuel Anderson

CLS,

Could you elaborate on your use of configuration files for merging UUT and Standard code in a Procedure? To reduce duplicate code, I'd like the UUT procedure to be standard agnostic.  Is there were a way to specify a procedure call dynamically during run-time? Is that how you use configuration files, or am I way off base?

 

0
Avatar
Michael Schwartz

I think the best way to show you how we write our procedures to be standard agnostic is to show you a sample with a better abstraction.  The Agilent DSO-X Procedure are available free of charge.

http://www.callabsolutions.com/products/oscilloscopes/agilent-dso-x-3000-series-proc/

Though MET/CAL is not an Object Oriented Programing Language, we have found ways to isolate the objects.  In this procedure you will see there are three version of the code 5520, 5820 and 9500.  If you look close there is only one version of the UUT code that is shared between the configurations (See Main, Test Points Sub and Test Routines Sub). Because this code is shared with all the configurations it can be fixed in one place.  

Next are the CLSD drivers, these drivers are used in place of the typical FSC and support standards not yet supported in MET/CAL.  It has taken us 10 years to write all these drivers, but it was well worth the investment because it gives us limitless flexibility. 

Finally is the Config Sub.  There is where we link the UUT code to the CLSD Drivers used.  Here is where we handle all the configuration options for the customer or the station.  We are able to support 99% of all the modification we need to make for standards or customer test requirements in this file.

Please sign in to leave a comment.