| 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 <2025> | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 <2025> |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: Some questions about CaLab (Dariush Hampai) |
| From: | Dariush Hampai via Tech-talk <tech-talk at aps.anl.gov> |
| To: | tech-talk at aps.anl.gov |
| Date: | Mon, 23 Jun 2025 17:18:06 +0200 |
Hi Kathryn,
thank you for your answer. Yoyu're right (Labview on windows).
However I don't see any process in Task Manager that can store all
the PV informations.
In order to explain better, i Started the SoftDemo.vi, so all the
PV presented are stored.
I stopped it and closed it.
Then I create a very simple VI (in attachment the front panel and
the block diagram) in order to explain better which is my problem.
As you can see, I tried to disconnect in two ways the PVs (by name
and all togheter). However the PVs remain stored.
Dariush
Hi Dariush,
I may have been wrong with the caching aspect, but as I say a quick look at the LabVIEW code for CaLab Info has a case structure and feedback nodes which I'd say are in keeping with a functional global variable (this is a LabVIEW VI of a specific type, the VI doesn't follow that style properly, but I'd say does much the same thing.) So what I think it is doing is asking for the information the first time it is called, and then keeping that information in memory and returning it - depending on how you are calling it. (Would need to the LabVIEW code to do more than make this as a random stab in the dark guess.) This is supposition based on minimal information. But that might only be the case if the IOC is actually stopped, otherwise, if the IOC is running the PVs will be there, you can't stop or disconnect a PV at the IOC side easily from the LabVIEW side.(For the experts, yes, I'm aware of the DIS fields, but I'm not certain the use case here is involving them, and they may be an additional complexity that isn't needed.)
CaLab is certainly the option I've found best when integrating on the LabVIEW side, but you do need a reasonable understanding of what each side is expecting and how they behave to be able to get the best results.
Please note, I have assumed that LabVIEW is running on a Windows system rather than the Linux system, which is again something that would make a difference to how things might be interacting.So starting CaLabSoftIOC.vi will spawn the IOC as a separate process, that process knows nothing about LabVIEW, it will just run on the same computer that LabVIEW was running on all on it's own. Check out the task manager, you will see it in the list. So simply stopping LabVIEW won't stop the IOC. I'm intrigued that it survived a restart of the computer though. However, it would restart as soon as you start the VI, so it might be worth trying that again and checking in task manager before starting the IOC.
Regarding the architecture, you need to run the version that matches the OS you are on, as there are DLLs underneath which care about that.
-- ************************************ Dr. Dariush Hampai, PhD INFN - LNF X-Lab Frascati Via E. Fermi, 54 (ex 40) I-00044 Frascati (RM) Italy Mail Address: XLab-Frascati LNF-INFN Casella Postale 13 Frascati (RM) Italy Room: +39.06.9403.5248 Lab.: +39.06.9403.2286 Mob.: +39.06.9403.8025 Fax.: +39.06.9403.2597 ************************************