Psuedo function panel for end user

[ngay528]

i figured I would ask before I started all the work...

Has anyone or is there an easy way to implement a psuedo function panel for the end user.  I am making a generic remote program that can talk to supply, scope, etc.

I would like to give the user essentially remote access to run any of the functions that I can implement on the source side.  So wasn't sure if there was an easier way than me making a drop-down list with a bunch of case statements and checking.

Also, does anybody have a suggestion on the best way to implement multi-type instruments?  i have two types of Supplies in my current case.  I am giving the user the option to select which one they have and then I determine which functions to call.  Currently I am creating my own h/c file with the extra input argument of device_type (which i created a enum for) to call the correlating fp functions.  Should this be a .dll or included in the program?  Does it matter in the end?

[Raj_V]

hi ngay528,

As for your first question, I don't believe there's a way to implement a pseudo function panel other than the way you mentioned. I am curious as to what you are trying to develop here. Are you attempting to  build a development environment itself. If so, it's definitely possible for you to implement tree structures and fill it with elements similar to the function panel but there's not easy or straightforward way of doing this.

To answer your second question, It shouldn't matter if you include the .c and .h file as part of this project or if you build it into a DLL and call it from this project. In either case, you would essentially get a value returned to you indicating which fp to load. For simplicity's sake, I would suggest using it in the same project if your developing a small application. For larger applications, it might make more sense to abstract this away into a DLL in case you need this functionality in multiple projects.

[ngay528]

Thanks for the input.  Essentially I will be making a test development application in which the user selects which supply they have, which scope, etc and then the user plans the test setup for instance, set instrument 1 to 4 volts.  In twenty seconds, measure this, then loop, etc.

So for the end-user fp, it would be useful if the user selects their instrument, I have the type saved, and then I pull the fp.  I believe I can access the Ivi function pointer that would return an ENUM, i just may need to create the "string" titles to correspond.

[MJF]

The sort of thing you are trying to do is the idea behind IVI drivers and a test executive environment like TestStand. It's quite a large task and also quite difficult to implement. Why not use the existing tools instead of attempting to write your own?

[ngay528]

That is not a bad idea and may look into that.  I will most likely still need to create some of the outside libraries or custom function calls, but TestStand may be exactly what I'm looking for for the sequence and automation of my program.

Thanks

[MJF]

I am a firm believer in not re-inventing the wheel.

Somebody has already done a significant portion of what I want to do, I'll look at that solution in detail before I decide to go off and do the work myself.

Sometimes knowing what tools are out there is half the battle.

As far as instrument interchangeability goes, like I mentioned, that is the idea behind IVI drivers. Unfortunately, not all instruments have an IVI driver. Also unfortunately, IVI is a lot harder to use than I think it should be (it requires configuration outside of your application in MAX).

Another approach is to write your own wrapper functions around the functions you want to implement and switch on the instrument type to call the right driver (which is really what IVI is doing behind the scenes). The drawbacks here are multiple, you have to decide what functionality you need to support and there can be a lot of time invested in writing and maintaining the wrappers.

One other thing to keep in mind, if your instruments conform to the SCPI standard, a lot of drivers will function with instruments even from different manufacturers. I have done this successfully with some Agilent and Rohde & Schwarz spectrum analyzers and network analyzers as well as power supplies from a variety of suppliers. It's not ideal and not everything works but it can save you a lot of time.

[ngay528]

Sounds good.  And ya I did see that many conform to the same standards so different Agilent devices may have the same commands.  Thanks again