Showing posts with label status subsystem. Show all posts
Showing posts with label status subsystem. Show all posts

Tuesday, June 30, 2015

Using User Defined Statuses on the APS

Hi Everyone,

I wanted to talk about a feature in our Advanced Power Supply family (APS from here on out)  that not too many people know about.  The APS features two user defined statuses in the Operation Status group.  Here is a rundown of all the entries in the group:


You can see that bits 7 and 8 are User1 and User2.

Using the advanced triggering system for the APS you can define what conditions will trigger a change in these two statuses.  The N7906A Power Assistant Software (download link) has a very handy graphical way to set up the trigger.   As an example, let's say that I wanted to change the user defined status when the voltage exceeds 1 V and the unit goes into positive current limit status.  Using the Power Assistant Software I would whip up the following:


After I draw out my trigger expression, I can either download it to my APS or I can click the "SCPI to Clipboard" button on the top of the page.  If I hit that button now and then hit paste here, I get:

:SENSe:THReshold1:FUNCtion VOLTage
:SENSe:THReshold1:VOLTage 1
:SENSe:THReshold1:OPERation GT
:SYSTem:SIGNal:DEFine EXPRession1,"Thr1 AND CL+"
:STATus:OPERation:USER1:SOURce EXPRession1

I can just copy this code into my program.  It's a pretty convenient.

I think the big question is: What can you do with this?  The answer is: whatever you want.  It's user defined so you can use it in whatever way you see fit.  If you want to check if the current exceeds a certain threshold you don't want to do a bunch of measure commands in loop, you can define that as your trigger and then just check the Operation Status Group (using the STAT:OPER? or STAT:OPER:COND? queries). 

I think that the most powerful thing that you can do with this is set up a SRQ handler to act when the user statuses change.  This is actually a project that I am working on presently so I have not implemented this just yet (but I will in the near future).   When I do, I will definitely write a blog post about it though!  I wanted to get the word out about this because even I did not automatically think about this when faced with a issue that just screamed to use this.  

Thanks for reading and stay tuned for a future installment on this topic! 

  




Wednesday, October 9, 2013

Using the power supply status subsystem to improve your test throughput

Continuing on my throughput theme here, one recommendation is to take advantage of the power supply’s status subsystem. Some power supply operations take notably longer than most to complete than others. Two notable examples:
  • Initializing a triggered measurement
  • Initializing a triggered output transient or output list event

When developing programs you can include long, fixed wait statements to make certain these operations have completed before proceeding. However, this can easily add many tens of milliseconds or more of unnecessary waiting, increasing overall test time.  A better way is to take advantage of the DC power supply’s status subsystem features that eliminate unnecessary waiting for these operations.

Triggered measurement and output sourcing events can substantially speed up testing by providing actions tightly synchronized with other test activities. But they do have some up-front set up overhead time needed for initializing them. Instead of using a fixed programming delay following an initialization operation it is better to take advantage of the Operation Status Group register in the status subsystem, which is illustrated in Figure 1.



Figure 1: Agilent N6700 series DC power system operation status group

The “WTG meas” bit (#3) or “WTG trans bit (#4) in the condition register can be monitored with a loop in the test program to see when they turn true. At the moment the measurement or output sourcing event is initiated and ready for a trigger the test program will then proceed with its execution without incurring any unnecessary additional waiting. This saves a considerable amount of time as illustrated in Figure 2.



Figure 2: Operation-complete wait time distribution

Instead of waiting for the full worst-case each and every time, the wait is now just the actual time. When repeated over and over for all DUTs being tested, the net result is the average of the actual wait time, which in most cases is just a small fraction of the worst case time! The net result can be many tens of milliseconds test time savings, making an improvement in test throughput.

The first five hints of my compendium “10 Hints for Improving Throughput with your Power Supply” can be viewed here: (click here to access).  For those reading our “Watt’s Up?” blog here are getting the opportunity to preview one of the remaining 5 hints yet to be released!