LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Connecting a Power Supply - Without the drivers

Hi, 

 

I am new to Labview, and I am looking at integrating a Power supply to Labview setups. Specifically controlling the Tenma 72-2540. 

I have been able to get control using power supply drivers and an example provided from another forum thread. However, is there a way of doing this without the driver/driver modules and maybe using 488.2 / VISA?

The reasoning behind this is that Labview is being newly integrated into my company. We have many different types of the same power supply and we would like to have one power supply control VI that can be used no matter the power supply selected.

If this is not an option would you have a recommendation to keep the flexibility when choosing PSUs?

 

Thank you in advance,

Catherine Brown

0 Kudos
Message 1 of 13
(1,205 Views)

@CatherineBrown wrote:

The reasoning behind this is that Labview is being newly integrated into my company. We have many different types of the same power supply and we would like to have one power supply control VI that can be used no matter the power supply selected.


It sounds like a use case for IVI drivers. See Using IVI Drivers in LabVIEW or LabWindows™/CVI

 

-------------------------------------------------------
Control Lead | Intelline Inc
0 Kudos
Message 2 of 13
(1,178 Views)

@CatherineBrown wrote:

The reasoning behind this is that Labview is being newly integrated into my company. We have many different types of the same power supply and we would like to have one power supply control VI that can be used no matter the power supply selected.

If this is not an option would you have a recommendation to keep the flexibility when choosing PSUs?


I am personally not a fan of IVI as the drivers tend to do more in a single function than is needed and they lack visibility in what they are doing.  But I also know many who use IVI very successfully.

 

Your alternative to IVI would be to create a Hardware Abstraction Layer (HAL).  These are not simple to create.  It requires a lot of upfront planning, good Object Oriented Design, and likely a plugin architecture.  Again, this takes experience in order to get it straight.  I have personally rearchitected my HAL several times for one reason or another.  It actually would be a good presentation to talk through the evolution of the HAL architecture.  With all of that said, there are some good presentations out there about HALs.  It is something you should at least be familiar with the concepts.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 3 of 13
(1,169 Views)

Thank you both, i'll look into both of those ideas and gain some more understanding and more experience. 

At a lower level would SCPI commands be sufficient for TENMA modules? 

 

Thanks.

0 Kudos
Message 4 of 13
(1,108 Views)

@CatherineBrown wrote:

At a lower level would SCPI commands be sufficient for TENMA modules? 

I am not familiar with TENMA modules (as in I have not had the opportunity to "play" with one).  But if they follow the actual SCPI standard, yes.  In my HAL, I have a "SCPI Power Supply" and it works for almost all of the single output power supplies I have had to control.  I also have a "Multiple Output Power Supply" which includes the output channels.  This one works for many supplies, but a lot of devices do not properly handle how you state which output you are commanding.  "Properly" based on the fact that SCPI has a standard for stating which output you are commanding.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 5 of 13
(1,102 Views)

@CatherineBrown wrote:

Thank you both, i'll look into both of those ideas and gain some more understanding and more experience. 

At a lower level would SCPI commands be sufficient for TENMA modules? 

 

Thanks.


Personally, I REALLY don't like HALs. You could Google a Norm Kitchener presentation titled "HALitosis" to learn how most HALs can go very wrong.   To do them correctly you really need to know EVERYTHING about the system first ...

Including everything you can't know yet because it won't be developed for several years. 

 

Philosophically, a HAL is anathema to proper DOX, Design Of eXperiment, in that it introduces a variable class (hardware design specifications) into the "Control."  A proper lvlib containing the API for power supply xyz in experiment jki on System target lmn is easy to reconfigure with power supply tuv but DOES require the justification of the experment design engineering team rather than some simple hardware substitution by a Lab Tech.


"Should be" isn't "Is" -Jay
Message 6 of 13
(1,087 Views)

Well there's a couple ways this can be accomplished.

 

First off I am not a fan of IVI drivers. IMHO: IVI has way too many DLL calls involved and too much is hidden from the LabVIEW programer. So if anything doesn't work as expected you are basically hooped.

 

Anyway most LabVIEW instrument "drivers" boil down to sending text based SCPI commands to to the instrument using VISA. Someone just saved you a lot of grunt work making a VI set for the majority of the instrument functions.

 

SCPI was an early attempt to standardize instrument communication. So it's very possible that basic SCPI commands like setting a voltage or enabling the output are the same. Especially if all the power supplies are the same brand.

 

But it's also possible that they are slightly different. In this case what I have done is create a simple HAL if you want to call it that. Where I either detect the instruments or use a configuration file to determine what exact instrument is being used and select the right SCPI command or driver VI. 

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 7 of 13
(1,078 Views)

@CatherineBrown wrote:

Hi, 

 

I am new to Labview, and I am looking at integrating a Power supply to Labview setups. Specifically controlling the Tenma 72-2540. 

I have been able to get control using power supply drivers and an example provided from another forum thread. However, is there a way of doing this without the driver/driver modules and maybe using 488.2 / VISA?

The reasoning behind this is that Labview is being newly integrated into my company. We have many different types of the same power supply and we would like to have one power supply control VI that can be used no matter the power supply selected.

If this is not an option would you have a recommendation to keep the flexibility when choosing PSUs?

 

Thank you in advance,

Catherine Brown


Here is an article that I like when it comes to effort and deciding whether to go the abstraction route.

In general, using abstraction is a boon and a bane in itself. It saves time in some scenarios but ties your hands in some.

https://www.ni.com/en/forms/hardware-measurement-abstraction-layers.html

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
Message 8 of 13
(1,072 Views)

@santo_13 wrote:

@CatherineBrown wrote:

Hi, 

 

I am new to Labview, and I am looking at integrating a Power supply to Labview setups. Specifically controlling the Tenma 72-2540. 

I have been able to get control using power supply drivers and an example provided from another forum thread. However, is there a way of doing this without the driver/driver modules and maybe using 488.2 / VISA?

The reasoning behind this is that Labview is being newly integrated into my company. We have many different types of the same power supply and we would like to have one power supply control VI that can be used no matter the power supply selected.

If this is not an option would you have a recommendation to keep the flexibility when choosing PSUs?

 

Thank you in advance,

Catherine Brown


Here is an article that I like when it comes to effort and deciding whether to go the abstraction route.

In general, using abstraction is a boon and a bane in itself. It saves time in some scenarios but ties your hands in some.

https://www.ni.com/en/forms/hardware-measurement-abstraction-layers.html


I like the analogy of the HALs of power myself (J. R. R. Tolkien may agree!)

3 child Classes for DMMs each all alone

7 for supplies referenced to ground

9 for the output devices in stone.

1 spec to bring them

1 config to find them

1 class to rule them 

And in Obsolescence bind them.

 

All forged in Mt. Doom!


"Should be" isn't "Is" -Jay
Message 9 of 13
(1,063 Views)

Hi All,

 

Thank you all for the replies! 

I wanted to come back with how I moved forward for future reference. 

I did go ahead and look into OOP and setting up classes etc, this seemed to be the best choice when trying to future-proof my work. 

 

I've attached an image of my project setup for reference. But I've set up a basic set of class that then branch off to the TENMA power supply (only one PSU setup so far). Please do shout if the layout can be improved! 

 

I also found the following YT videos were the best for explaining OOP:

How to Setup a Hardware Abstraction Layer with LabVIEW classes (youtube.com)

1 of 6 Future Proof Your Code! Introduction to Object Oriented Programming in LabVIEW (youtube.com)

 

Thanks,

Catherine

0 Kudos
Message 10 of 13
(980 Views)