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: Looking for feedback on what epics users require |
From: | Ralph Lange <[email protected]> |
To: | "Pawel Kowalski - BiRa Systems Inc." <[email protected]> |
Cc: | [email protected] |
Date: | Wed, 11 Mar 2009 10:03:11 +0100 |
Hello Pawel,To connect to your power supplies through UDP on standard ethernet, you do not need to run the IOC on VxWorks. So-called "soft IOCs" run as a multi-threaded process on any "host side" OS, such as Linux (preferred) or Windows. If the only device connection of the IOC is through IP/ethernet, this solution is probably more flexible and efficient (many soft IOCs can run on a single machine), and a lot less expensive (inexpensive hardware, free OS). You could go as far as only supplying the software needed to create and run the power supply IOC on a machine the customer would provide.
If your systems are to be integrated into an existing EPICS based structure, most installations will have their own solution for display (panel) managers, alarm handlers, achivers etc., based on the variety of tools that are part of the EPICS toolkit. Creating some user interfaces that you ship with your IOCs is a good thing to do, but forcing your customers to use stuff that you supply would probably rather cause resistance, and (in the best case) your beautiful panels would just be not used.
Be aware that the Channel Access network protocol that people will use to integrate your IOCs is completely relying on channel names to describe hierarchies and - to some degree - properties. Any existing EPICS system will have a strict naming convention for channels, and any "foreign" IOCs with channels that don't follow that customer convention will cause a lot of grief and trouble when being integrated. You should try to create a solution that allows channel names to be adapted to customer naming schemes. This is not easy. (IE in our case your "powersys:voltage" name would of course be completely unacceptable and be replaced by something like "Q3PD5R:rdVolt" - first part: device name, second part: channel name, both following strict conventions.)
Thanks for asking, (I mean it - please continue to ask!) Ralph On 10.03.2009 15:45 Pawel Kowalski - BiRa Systems Inc. wrote:
Hello,My company is researching providing an epics IOC with some of our power supplies. I would like to get some feedback from the epics community on what exactly would be required. First let me start off by saying that epics is still a new area for me so hopefully these questions aren't dumb, we are still in the early research stages on this. What we would like to do is provide a system with each device that will host an EPICS IOC. This will be a vxWorks based system running epics base 3.14. This system will communicate with our device using ethernet and convert standard UDP commands that our devices work on to process variables. So for example our clients would now have a process variable they could use to monitor or set the voltage of a power supply (IE: powersys:voltage). For the client side we would like to develop a LabVIEW interface, we would most likely not be developing a custom C/C++ application for the client. Would this be adequate for most epics users or would more be required to integrate this into an existing epics network? Would people use the LabVIEW client we develop or do most labs use their own custom software to control/monitor epics enabled equipment? Any feedback from the community would be greatly appreciated, thank you.