06-10-2024 04:03 AM
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
06-10-2024 06:56 AM
@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
06-10-2024 07:40 AM
@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.
06-14-2024 08:11 AM
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.
06-14-2024 08:50 AM
@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.
06-14-2024 11:22 AM - edited 06-14-2024 11:24 AM
@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.
06-14-2024 12:26 PM
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.
06-14-2024 12:37 PM
@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
06-14-2024 01:02 PM - edited 06-14-2024 01:09 PM
@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!
06-19-2024 03:37 AM
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