[Halld-controls] [Halld-online] Agenda for Hall D Online meeting next week, 13-Oct

Hovanes Egiyan hovanes.egiyan at gmail.com
Sun Oct 24 21:28:48 EDT 2010 

Hello Matt,

as an example I posted  on CUE some of the files for the EPICS driver  
for particular type of HV
mainframes and boards. We  made that driver for CAEN HV chassis in Hall B a
couple of years ago, and they work fine. The HV chassis had an  ability 
to communicate
through the Ethernet port. And from what I heard this is similar to 
what  you may do for FCal.

At this point the main  purpose of this example
would be to look at a couple of source files without trying to compile 
the whole thing because
I am not sure how well it will work. Successfully compiling an EPICS 
application which was written
for an older version of EPICS may take too much time and may not be very 
useful
for this.

Please take a look in the following directory on JLab CUE machines :
/group/halld/Users/hovanes/CaenExample/Driver

In particular the source files are the analogues for what would be needed
to connect the FCAL HV application to EPICS:
sy1527.c
sy1527.h
sy1527epics1.h
sy1527epics1.c

The "sy1527.h" and "sy1527.c" are the HV application itself. The 
application synchronizes
the states of the HV chassis with the memory in the Linux host which is 
running
the EPICS Input/Output Controller (IOC). This shadowing was done to 
avoid problems when
users  send a large number requests directly to hardware.

"sy1527epics1.h" and "sy1527epics1.c" are the interface to EPICS. These 
comprise the
set of functions which  EPICS needs to operate the HV mainframes. In 
principle
these kind of calls are ALL that EPICS would need, but what happens 
behind these functions
needs to be well designed.

In Hall B case  the actual driver for communicating to the chassis 
through Ethernet port
was only available to us in the form of binary files 
("O.linux-x86/libsy1527epics1.a"
and "O.linux-x86/libsy1527epics1.so"), CAEN refused to give us the 
source files. The
header file for these  functions are in "CAENHVWrapper.h" file. I hope  
this situation is
not going to be the case for your system.

The set of functions here (sy1527epics1.h) was chosen specifically to 
the CAEN HV boards and
chassis (and what we intended to make available to the users).
For FCAL they may be different, and we need to come up with the 
appropriate set.

Although this driver is written in C it did not have to be. We can 
easily accommodate
C++ in EPICS as well, and that would be my preference at this time.

This is example of course assumes that we go directly to EPICS with the 
FCAL HV application.

Regards,
         Hovanes.



On 10/06/2010 08:52 AM, Matthew Shepherd wrote:
> Hovanes,
>
> We have tested and used this device with success:
>
> http://www.anagate.de/en/products/AnaGateCANquattro.htm
>
> A year or two ago, this seemed to be the best product on the market for us.
>
> Right now we plan roughly 30 CAN busses each with about 100 bases on them.  (The FCAL will have a total of 2800 channels.)  I think we'll need to get a full busload of them before we can start to understand any bandwidth limitations and how that might affect setup time or monitoring loops.  The base firmware only responds when talked to -- in other words, there is no monitoring loop running on the bases (at this stage).  We'll need to periodically poll each bus to check for failures, etc.
>
> I really don't know anything about EPICS.  If there is some example to start to work with, we can begin to design a control system using the control libraries that we have already developed.
>
> -Matt
>
>
> On Oct 6, 2010, at 8:43 AM, Hovanes Egiyan wrote:
>
>    
>> Hi Matt, Elliott and Fernando,
>>
>> If there is already a  configuration allowing  Ethernet control of the
>> HVs then using PLC beyond that is not an efficient thing to do.
>> EPICS would probably be our best choice, and depending on the hardware
>> there might already be an EPICS driver available.
>> Otherwise we need to write an EPICS application based on some basic driver
>> using Ethernet, which I understood is what Matt already has.  Here I am talking about a
>> set of functions sending simple messages like setting a voltage or a trip current,
>> reading voltages and status etc. The application details would depend on the number
>> of Ethernet ports and channels that we need to control.
>>
>> For instance we can have a thread per bus running on a single EPICS
>> host in the counting house which is keeping track of the state in which channels are
>> in a bus and is keeping an image of the bus in the memory. The thread will synchronize
>> the memory in the host and the state of the channels in the hardware every
>> second in a synchronized manner.   This way there will not be too much traffic
>> generated depending what the EPICS users wants to do, the user will be isolated
>> from the hardware which will prevent too many request to the hardware. For this
>> it would be useful to have functions for dealing with more channels at once for
>> certain operations.
>>
>> If the number of channels is small compared to the capabilities of these "chassis"
>> with Ethernet ports then the the application can  be much simpler,
>> with an EPICS variable directly requesting and sending information to the
>> hardware channel. But what exactly we do depends very much on what the hardware
>> is (brand and models of the modules) and how the channels are distributed in
>> the CAN buses, and how many CANs are connected to a single Ethernet port. Is there
>> a web site or a presentation  where I could look how this is going to be built?
>>
>> It may be also useful for us to know what scaler modules and discriminator modules
>> you are planning to use for FCAL so that we can start thinking about that part
>> of the slow controls as well.
>>
>> Regards,
>>             Hovanes.
>>
>>
>>
>> On 10/06/2010 04:13 AM, Matthew Shepherd wrote:
>>      
>>> Hi Elliott and Fernando,
>>>
>>> Yes -- to elaborate a little more.  I envision we will provide some chassis with about 30 different ethernet sockets (one for each CAN bus).  We can provide a library that implements calls like:
>>>
>>> setHV( busID, baseID, value )
>>> readHV( busID, baseID )
>>> readCurrent( busID, baseID )
>>> ..
>>>
>>> In order to be able to practically use this, there needs to be some interface between the user and these modular components.  A stand-alone program would work, but this is not ideal as you probably desire a common framework for generating alarms, recording status etc.  This part of the system is a bit nebulous to me, but seems to be the heart of a well-designed control framework.  Practically, what does the interface look like?  We want to start building that interface over the next 2-3 months so that we can use it to power, test, and monitor 500 CW bases.
>>>
>>> -Matt
>>>
>>>
>>> On Oct 5, 2010, at 10:40 PM, Fernando J. Barbosa wrote:
>>>
>>>
>>>        
>>>> Hi Elliott,
>>>>
>>>> Maybe I am missing something here but some time ago you decided on using the PLC. I believe Matt already has the ethernet-to-CAN controller (off-the-shelf). The custom box I mentioned in the past was for the CDC and the FDC LV distribution, not for the CW bases.
>>>>
>>>> This suggests that you need to have a cohesive plan for all the controls in place soon.
>>>>
>>>> Best regards,
>>>> Fernando
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Elliott Wolin wrote:
>>>>
>>>>          
>>>>> Hi Matt,
>>>>>
>>>>> There are a number of approaches to control all those CAN channels in the FCAL C-W bases (by the way, did you determine how many CAN buses we'll need, i.e. how many channels per bus is acceptable?).
>>>>>
>>>>> My favorite would entail direct PLC control of the CAN system, but I don't think the PLC and CAN worlds overlap much, at least I haven't found anything that directly and simply bridges the two.  The PLC can talk Ethernet/IP, but I haven't come across an Ethernet/IP CAN control system (but I haven't looked in a while).
>>>>>
>>>>> We plan to use EPICS to tie all the disparate control systems in the hall together by providing a thin layer on top of autonomous, intelligent devices.  I'm also hoping that the "autonomous, intelligent devices" are not PC's strewn about the hall running programs written by undergrads who are long gone.  Experience at JLab is that such systems almost always have to be redone, and thus we might as well do it right at the beginning.
>>>>>
>>>>> So, how to make an robust, intelligent, autonomous multi-bus CAN control system that controls the bases and can talk to EPICS, preferably one that is not just a PC on a table in the hall?
>>>>>
>>>>> I once looked at the National Instruments cRIO line.  Last I looked they had 2-channel CAN modules that mount in a cRIO chassis, eight slots (16 buses) per chassis.  The chassis contains a Labview-programmable cpu and FPGA.  It was a bit expensive, but one could make a robust, autonomous, stand-alone, EPICS compatible controller this way.  AT the time they were offerering me big discounts, probably because cRIO was new and they were looking for applications they could brag about.
>>>>>
>>>>> I also saw some devices on the web with many CAN controllers in them, but didn't investigate.
>>>>>
>>>>> Fernando once thought GlueX should build a custom box for this purpose, maybe he still does.  I don't know what he had in mind.
>>>>>
>>>>> What are your thoughts?
>>>>>
>>>>>                 Sincerely,
>>>>>                     Elliott
>>>>>
>>>>>
>>>>> ================================================================================
>>>>>
>>>>>
>>>>> Those raised in a morally relative or neutral environment will hold
>>>>>             no truths to be self-evident.
>>>>>                   Elliott Wolin
>>>>> Staff Physicist, Jefferson Lab
>>>>> 12000 Jefferson Ave
>>>>> Suite 8 MS 12A1
>>>>> Newport News, VA 23606
>>>>> 757-269-7365
>>>>>
>>>>> ================================================================================
>>>>>
>>>>>
>>>>>
>>>>> Matthew Shepherd wrote:
>>>>>
>>>>>            
>>>>>> Hi Elliott,
>>>>>>
>>>>>> We are expecting to build 500 of the CW PMT bases in the next few months.  Once we get them we will want to begin design of the CW slow control system.  As of now we are planning to use an ethernet to CAN converter that we have tested and written some libraries for.  However, we would prefer to have to have to redesign it later to integrate into the Hall D control system.  Any advice or guidance you can provide on the design would be helpful.  Is there a particular framework that you would like us to work within?
>>>>>>
>>>>>> -Matt
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Oct 4, 2010, at 3:21 PM, Elliott Wolin wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>              
>>>>>>> Hi,
>>>>>>>
>>>>>>> We haven't met in a while, so status reports and updates on all topics are appropriate.  Also, anything notable that has happened in the past two months (designs, construction efforts, test results, conferences, etc).
>>>>>>>
>>>>>>> Please send me topics.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>>
>>>>>>>                 Sincerely,
>>>>>>>                     Elliott
>>>>>>>
>>>>>>>
>>>>>>> ================================================================================
>>>>>>>
>>>>>>>
>>>>>>> Those raised in a morally relative or neutral environment will hold
>>>>>>>             no truths to be self-evident.
>>>>>>>                   Elliott Wolin
>>>>>>> Staff Physicist, Jefferson Lab
>>>>>>> 12000 Jefferson Ave
>>>>>>> Suite 8 MS 12A1
>>>>>>> Newport News, VA 23606
>>>>>>> 757-269-7365
>>>>>>>
>>>>>>> ================================================================================
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Halld-online mailing list
>>>>>>> Halld-online at jlab.org
>>>>>>> https://mailman.jlab.org/mailman/listinfo/halld-online
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>>
>>>>>>              
>>>> <barbosa.vcf>
>>>>
>>>>          
>>>
>>>        
>>      
>

More information about the Halld-controls mailing list