Pawel, I didn't mean to raise network traffic as an issue, and I'm not
competent to make the judgment you're asking for. I'll bet some of the
accelerator guys have more useful opinions than mine on this topic.
My comments were intended to address the time required to exchange
information between my IOC and a power supply. I care about this
because I'm probably going to end up putting one of your power supplies
in a feedback loop, where round-trip message time translates pretty
directly into a limit on the highest frequency at which the loop will
be stable. In this case, I care about the time required for the
simplest read/write message, and the worst-case number of messages I'll
have to send to change the power supply's output.
Putting an extra IOC in the message loop could be a problem because it
involves channel access in what is essentially a device-support role.
Channel access has optimizations and priorities that were designed for
a different purpose: channel access handles everybody's traffic, and is
fair; device support handles only my traffic, and is permitted to be
selfish.
Tim
Pawel Kowalski - BiRa Systems Inc. wrote:
Tim, I would have to do some research on providing device support. I was
under the impression we would need to provide an IOC but it looks like I am
wrong on that assumption. I appreciate you and others mentioning this, I
will look in to it.
To address the network traffic issue I will look in to providing 2 ethernet
ports on the vxworks IOC. That way the UDP traffic can be on its own private
subnet. Do you think this would be an appropriate solution to the network
traffic issue if we did go the IOC route?
Sincerely,
Pawel Kowalski
BiRa Systems Inc.
505-881-8887
http://www.bira.com
-----Original Message-----
From: Tim Mooney [mailto:[email protected]]
Sent: Tuesday, March 10, 2009 10:27 AM
To: Pawel Kowalski - BiRa Systems Inc.
Cc: [email protected]
Subject: Re: Looking for feedback on what epics users require
Pawell,
First of all, questions from vendors, about what customers would like, are
automatically not dumb. What they are is rare.
If the devices, which you plan to provide with support, respond to standard
UDP commands, then maybe an IOC is not the most valuable thing you could
provide, because each write/read transaction would require at least four
hops on the network. I think some of your customers would prefer to have
device support they can call from their own IOC. This probably only matters
for high-traffic devices, or devices likely to be used in feedback loops.
(I don't intend this to discourage you from providing an IOC, but rather to
encourage you to make the device-support code available.
Providing an IOC will dramatically simplify the integration job in most
cases.)
Client-side EPICS support seems to me generally much less valuable than
server-side EPICS support, because it has a smaller (more
fragmented) audience, and because clients are harder to orchestrate than is
server side support. (If you provide a client that ramps the device, for
example, I probably can't call that client from my client, or from my IOC,
to get ramping done. I'll probably have to reverse engineer the client-side
algorithm, and implement it in my IOC. If you provide EPICS server-side
code that does the same job, I can call it from anywhere.)
Tim Mooney
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.
--
Tim Mooney ([email protected]) (630)252-5417 Beamline Controls & Data
Acquisition Group Advanced Photon Source, Argonne National Lab.
--
Tim Mooney ([email protected]) (630)252-5417
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab.
- References:
- Looking for feedback on what epics users require Pawel Kowalski - BiRa Systems Inc.
- Re: Looking for feedback on what epics users require Tim Mooney
- RE: Looking for feedback on what epics users require Pawel Kowalski - BiRa Systems Inc.
- Navigate by Date:
- Prev:
RE: Looking for feedback on what epics users require Pawel Kowalski - BiRa Systems Inc.
- Next:
MM4000 asynMotor problem Wang Xiaoqiang
- 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
- Navigate by Thread:
- Prev:
RE: Looking for feedback on what epics users require Pawel Kowalski - BiRa Systems Inc.
- Next:
Re: Looking for feedback on what epics users require Claude Saunders
- 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
|