Showing posts with label graphical programming. Show all posts
Showing posts with label graphical programming. Show all posts

Monday, March 10, 2014

Upcoming software release unleashes the N7900 APS’s potential without any programming

Our N7900A Advanced Power System (APS) is well named, being the most advanced power product we’ve introduced to date. In many ways it is based on our N6700 series modular DC power system and N6705B DC power analyzer, incorporating their capabilities, including:
  • High precision programming and measurement
  • Seamless measurement ranging
  • High speed measurement digitization of voltage, current, and power
  • Long term data logging of voltage, current, and power
  • Output ARB and List capabilities
  • And quite a bit more


In addition the N7900A APS brings quite a few new and unique capabilities as well, including:
  • Much greater output power
  • Logic-configurable expression signal routing for advanced custom triggering and control
  • Optional external dissipater unit for full two quadrant operation
  • Optional black box recorder for post-test diagnostics when needed
  • And quite a bit more


To take advantage of these advance capabilities does require a bit of programming, which is to generally be expected for an automated test environment, but in low volume design validation and R&D this can slow down the desired quick time-to-result. The N6705B DC Power Analyzer, in Figure 1, has a full-featured front panel menu and graphical display that lets design validation and R&D users quickly configure and run complex power-related tests on their devices. In comparison, the N6700 series, pictured in Figure 2, does not have all the front panel capabilities of the N6705B and can be looked on as the ATE version of this product platform, requiring programming to take advantage of its advanced capabilities. The N6705B shares all the same DC power modules that the N6700 series uses.



Figure 1: The N6705B DC Power Analyzer, primarily for bench use




Figure 2: The N6700 series Modular DC Power System, primarily for ATE

The N7900A APS is very similar in form and function to the N6700 series, not having all the advanced front panel capabilities that the N6705B has for bench-friendly use of its advanced features. I am really pleased to be able to share with you that this is now changing! While we are not creating a bench version of the N7900 APS, we are upgrading our 14585A Control and Analysis software, which emulates the front panel of an N6705B and more, to work with the N7900 APS as well. The 14585A will soon let you quickly and easily create and configure complex power-related tests based on using the N7900 APS.  I am fortunate enough to be working with a beta version of the software. Some examples of things I was able to do in just a few minutes were to capture the inrush current of an automotive headlight, shown in Figure 3, and superimpose an AC sine wave disturbance on top of the DC output, shown in Figure 4.




Figure 3: Auto headlamp inrush current captured with 14585A software and N7951A APS




Figure 4: Sine wave voltage disturbance on top of DC generated by 14585A software and N7951A APS

The updated release of the 14585A Control and Analysis software is just a few weeks away. More about the 14585A software can be found by clicking on the following link <14585A>With the 14585A being a great way to implement ideas and tests quickly, using the N7900 APS, look for me and others coming up with some interesting applications in future posts here on “Watt’s Up?”!

Thursday, October 31, 2013

Power Supply Programming Part 2: What Type of Programming Language to Use

Happy Halloween Watt’s up fans!  Today I want to look at what programming language you are going to use to write your program.  Instead of recommending a particular language, I am going to break it down by graphical versus text based programming.

Let me start by saying that there really is no correct answer to this question.   This is a matter of personal taste.   

I am going to start with a bit about my background.  Unlike most of my colleagues, I did not specialize in analog electronics in college.  I focused more on computer engineering.  Due to this specialization, I have taken quite a few programming based courses.  I prefer sitting down and programming using a text based programming language because of my background. 

 Graphical programming languages are a very popular option (Agilent VEE is the one that I am most familiar with).     I find these programs are great for doing short programs.  If something can take up less than one page on your computer screen, then it works pretty well here.  These languages also make building user interfaces really easy since there are a lot of easy to access functions for controlling and displaying instrument data.  I personally find that they get very unwieldy if you want to send and read a lot of data with an instrument.  I also find the looping constructs to be strange.   People have told me that these graphical languages look very similar to circuit diagrams and I can see how people would prefer that kind of view to just plain text programming.

I am going to make a confession.  If I have to write a program quickly and I do not have to show it to anybody, I still will write it in HPBASIC.  I find it to be very easy to do simple instrument programming.  There is no need for drivers, once it is set up properly; sending and receiving information with an instrument is a breeze.    Large programs do not fare very well in HPBASIC though.

My preferred way to program these days is Visual Basic (using VISA-COM IO).  If you look at the power supply example programs that we provide, there is a lot of VB in there.  I feel that a text based program allows you to write much more compact code. It takes up a lot less screen space than an equivalent graphically based language.  Something like Visual Basic is also more versatile since it is not only for test and measurement but for more general applications.  The looping constructs work very nicely here and to me the flow makes more sense.  I also find typing quicker than connecting boxes.  Text based programming does have some cons though.  For one, the graphical languages are written from the bottom up to do instrument control.  They have built in functions and data manipulation that make thing easier.  The graphical languages also have some really good libraries for building User Interfaces. 

 The real correct answer to the questions is the best language to use is the one that you are most comfortable programming in.  If you think that I missed any pros or cons please feel free to share in the comments.