Experimental Physics and
Industrial Control System

"Pawel Kowalski - BiRa Systems Inc." <[email protected]> · Thu, 12 Mar 2009 13:48:30 -0600

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.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System