Argonne National Laboratory

Experimental Physics and
Industrial Control System

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  <20192020  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  <20192020 
<== Date ==> <== Thread ==>

Subject: Re: [EXTERNAL] Beckhoff BK9000 support survey
From: "Wallace, Alex via Tech-talk" <tech-talk@aps.anl.gov>
To: GAGET Alexis <alexis.gaget@cea.fr>, "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Wed, 3 Jul 2019 15:58:39 +0000

Hi Alexis,


That's awesome! This is pretty much what we're interested in getting going. And I completely agree with the reasons for working on the EK9K. Would you mind sharing your device support?


Our plan was to get something working and then publicize it. It seems our initial targets for the EL modules match what you have already.


We're also interested in the EL704* modules. It sounds like you put the terminal into PTP mode and now there are some "tuning" CoE parameters to find.


-Alex


From: GAGET Alexis <alexis.gaget@cea.fr>
Sent: Wednesday, July 3, 2019 1:54:35 AM
To: Wallace, Alex; tech-talk@aps.anl.gov
Subject: RE: [EXTERNAL] Beckhoff BK9000 support survey
 
Hi everybody,
Here at CEA we are using the EK9000 coupler on several project with the standard Modbus driver, it works well with most of the simple Modules (ES1xx,2xxx,3xxx,4xxx).
The reason why we left the EtherCAT coupler EK1101 is that we didn't need RT and it implied a lot of troubles (compiling RT Linux, kernel modules etc...).
I'm currently working on using the EL7041-0052 motion control modules with the EK9000 (really simple need : "move on 1 axe to  position"), hopefully most of the essential parameters are accessible through the Modbus registers but otherwise I've managed to access to all the Coe index through the EK9000 register provided for this purpose.
Unfortunately for the moment my motor moves but not completely the way I want (craaaazy acceleration) and beckhoff support doesn't seems completely comfortable with the EK9000.

Alex I have noticed that you are developing EK9000 device support and I'm interested. Will your code be accessible ?

Cheers

Alexis GAGET
CEA Saclay - DRF/Irfu/DIS/LDISC
alexis.gaget@cea.fr


-----Message d'origine-----
De : tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov> De la part de Wallace, Alex via Tech-talk
Envoyé : lundi 1 juillet 2019 18:33
À : tech-talk@aps.anl.gov
Objet : RE: [EXTERNAL] Beckhoff BK9000 support survey

Hi everyone,

I strongly recommend to anyone asking about EtherCAT or Beckhoff IO to use either the BK9000 or EK9000 coupler. SLAC has used BK9000 couplers and the KL**** terminals extensively for slow EPICS IO at LCLS and elsewhere.

We have also deployed EL**** and EP**** (EtherCAT) terminals using the Diamond EtherCAT IOC and EtherLab master. This solution is good, with the drawback of requiring kernel modules and a bit more overhead than a basic EPICS IOC. However, there is another way to use the EtherCAT (EL) terminals from Beckhoff.

The EK9000 creates a Modbus interface for the EL terminals similar to how the BK9000 creates one for the KL terminals. Unfortunately it's not exactly the same so we have to write new device support. I am happy to report it's in progress right now!

We have a talented intern assigned to work on EK9000 support using Mark River's Modbus module, R3-0. He's making good progress, we should be ready for a hardware demo this week.

If you have any questions about the development, please feel free to send me an email.

-Alex

-----Original Message-----
From: tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov> On Behalf Of tech-talk-request@aps.anl.gov
Sent: Sunday, June 30, 2019 10:00 AM
To: tech-talk@aps.anl.gov
Subject: Tech-talk Digest, Vol 13, Issue 281

Send Tech-talk mailing list submissions to
        tech-talk@aps.anl.gov

To subscribe or unsubscribe via the World Wide Web, visit
        https://mailman.aps.anl.gov/mailman/listinfo/tech-talk
or, via email, send a message with subject or body 'help' to
        tech-talk-request@aps.anl.gov

You can reach the person managing the list at
        tech-talk-owner@aps.anl.gov

When replying, please edit your Subject line so it is more specific than "Re: Contents of Tech-talk digest..."


Today's Topics:

   1. Re: [EXTERNAL] Beckhoff BK9000 support survey (Jeong Han Lee)


----------------------------------------------------------------------

Message: 1
Date: Sun, 30 Jun 2019 10:26:26 -0400
From: Jeong Han Lee <citadel.lee@gmail.com>
To: "Dunning, Michael" <mdunning@slac.stanford.edu>,
        "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Subject: Re: [EXTERNAL] Beckhoff BK9000 support survey
Message-ID: <3d5b228f-8d0a-84ca-cdae-a619f90bc0e9@gmail.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Hi Mike,

   ESS has a bit unique and generic EPICS support based on asyn. Please look at the following talk

http://accelconf.web.cern.ch/AccelConf/icalepcs2017/talks/mocpl05_talk.pdf

   We've called it as ecmc (EtherCat Motion Control), but we extend it to generic I/O supports. The current support modules in the enclosed file.

   Unfortunately, they are within the closed repository, but we are willing to share it within EPICS community.

   HTH,
   Han




On 6/27/19 5:38 PM, Dunning, Michael via Tech-talk wrote:
> Thanks everybody for the responses so far.
>
> I should add that, as Davide mentioned, for some modules we need to
> access the Beckhoff "hidden" registers which can only be accessed
> through other registers.  This makes the modbus "driver" approach
> necessary if we want to cover all modules.  In our case we've needed
> to access these registers for changing configuration parameters, e.g.
> changing thermocouple types or ADC scaling, or for motor
> configuration.
>
> Mark - thanks for pointing out the new C++ version of modbus.  It
> sounds like we could get rid of our custom modbus driver code and
> instead call modbus functions directly from our asynPortDriver.  This
> should simplify things and make maintenance a bit easier.  This
> definitely sounds like something we should pursue.
>
> Thanks again to all who have responded.
>
> Mike
>
>
>
>
>
>
>
>
> Michael Dunning
> SLAC National Accelerator Laboratory
> 2575 Sand Hill Road
> Menlo Park, CA 94025
> (650) 926-5200
> On Thu, Jun 27, 2019 at 11:52 AM Mark Rivers <rivers@cars.uchicago.edu> wrote:
>>
>>> I would only do this if the application is complex enough that you
>>> need to move logic from the database down into C++ code. I'd still
>>> make use of the standard modbus support module and use it like a
>>> library to handle the modbus protocol (since it's been around for
>>> 10+ years and is well tested, that would be my starting point
>>
>> In the new asynPortDriver branch you can do the following:
>>
>>
>>
>>          drvAsynIPPortConfigure("Koyo1","camaro:502",0,0,1);
>>          asynSetOption("Koyo1", 0, "disconnectOnReadTimeout", "Y");
>>
>>
>>
>>          modbusInterposeConfig("Koyo1", modbusLinkTCP, 5000, 0);
>>
>>
>>
>>          // Use absolute addressing, modbusStartAddress=-1.
>>          drvModbusAsyn *pModbus = new drvModbusAsyn("K1", "Koyo1", 0,
>> 2, -1, 256, dataTypeUInt16, 0, "Koyo");
>>
>>          // Write 10 bits at address 2048
>>          memset(data, 0, sizeof(data));
>>          data[0] = 1;
>>          data[2] = 1;
>>          data[4] = 1;
>>          data[6] = 1;
>>          data[8] = 1;
>>          printf(" Writing [1 0 1 0 1 0 1 0 1 0] to adddress 2048\n");
>>          /* asynStatus doModbusIO(int slave, int function, int start, epicsUInt16 *data, int len); */
>>          pModbus->doModbusIO(0, MODBUS_WRITE_MULTIPLE_COILS, 2048,
>> data, 10);
>>
>>
>>
>>          Because the drvModbusAsyn constructor was called with startAddress=-1 doModbusIO can write to any address with any function code.
>>
>> Mark
>>
>> Sent from my iPhone
>>
>> On Jun 27, 2019, at 12:23 PM, Pearson, Matthew R. via Tech-talk <tech-talk@aps.anl.gov<mailto:tech-talk@aps.anl.gov>> wrote:
>>
>> Hi,
>>
>>
>> One version uses only the epics modbus module.  This has no driver so
>> requires less maintenance, but makes setting up IOCs more time
>> consuming and results in a lot of code duplication.
>>
>>
>> If the only problem with this method is the code duplication in each IOC then it's best to move the database into templates in a support module. Then all the IOC has to do is include them in a substitutions file. You could have one template per module type. And if there is common database code between modules then separate that out into common template files that are included in the per-module templates.
>>
>> Then in the IOC startup script you may have a large list of calls to drvModbusAsynConfigure in order to setup the modbus ports for different address ranges. You can also put this in the support module, and just include it in the IOC st.cmd, passing in macros as necessary. For example, this is what I do for one of my applications for the Moxa ioLogik modules:
>>
>> #E1214 Unit (6 DI and 6 Relay)
>> epicsEnvSet("IP_ADDR","192.168.200.177:502")
>> epicsEnvSet("IP_PORT","m1ip")
>> epicsEnvSet("PORT","m1")
>> < $(MOXA)/st_scripts/st_common.cmd
>>
>> Where st_common.cmd is just a list of calls to drvModbusAsynConfigure. You may or may not need a different list for each type of module, depending on the modbus registry maps.
>>
>> Another version uses asynPortDriver and some custom modbus code. 
>> This is designed to make setting up IOCs easier, but requires
>> maintenance of the driver code.
>>
>> I would only do this if the application is complex enough that you need to move logic from the database down into C++ code. I'd still make use of the standard modbus support module and use it like a library to handle the modbus protocol (since it's been around for 10+ years and is well tested, that would be my starting point).
>>
>>
>> Another uses custom epics device support.  This requires writing
>> device support for each bus terminal, and has resulted in a pretty
>> ugly codebase.  This is our least favored solution going forward.
>>
>>
>> There's no need to write support this way anymore, since Asyn gives you the device support for free.
>>
>> Cheers,
>> Matt
>>
>>
-------------- next part --------------
ecmcAI.template
ecmcAO.template
ecmcAsynAxisDiagArray.db
ecmcAsynControllerGeneral.db
ecmcAsynGenericAnalogInput.db
ecmcAsynGenericAnalogOutput.db
ecmcAsynGenericDigitalInput.db
ecmcAsynGenericDigitalOutput.db
ecmcAsynGenericRecordsAnalogInput.db
ecmcAsynGenericWaveformInput.db
ecmcBI.template
ecmcBO.template
ecmcControllerGeneral.db
ecmcDataRecorder.db
ecmcDataStorage.db
ecmcDefaultAsynParamsAxis.db
ecmcDefaultAsynParamsEc.db
ecmcDefaultAsynParamsEcSlave.db
ecmcDUT_AxisStatus_v0_01.db
ecmcEcSlave.template
ecmcEL1014.substitutions
ecmcEL1018.substitutions
ecmcEL10XXEL11XX.template
ecmcEL1252.substitutions
ecmcEL2004.substitutions
ecmcEL2124.substitutions
ecmcEL2502-chX.template
ecmcEL2502.substitutions
ecmcEL2521.substitutions
ecmcEL2521.template
ecmcEL2522-chX.template
ecmcEL2522.substitutions
ecmcEL2612.substitutions
ecmcEL2808.substitutions
ecmcEL2808.template
ecmcEL2819.substitutions
ecmcEL2819.template
ecmcEL3002-0010.substitutions
ecmcEL3004.substitutions
ecmcEL300X-chX.template
ecmcEL3162.substitutions
ecmcEL3164.substitutions
ecmcEL32XX-chX.template
ecmcEL3602.substitutions
ecmcEL3632-chX.template
ecmcEL3632.substitutions
ecmcEL37X2_100.substitutions
ecmcEL37X2_10.substitutions
ecmcEL37X2.substitutions
ecmcEL37XX-chX.template
ecmcEL3XX2.substitutions
ecmcEL3XX4.substitutions
ecmcEL3XX5.substitutions
ecmcEL3XX8.substitutions
ecmcEL4004.substitutions
ecmcEL4102.substitutions
ecmcEL4104.substitutions
ecmcEL4122.substitutions
ecmcEL4XX2.substitutions
ecmcEL4XX4.substitutions
ecmcEL4XXX-chX.template
ecmcEL5001.substitutions
ecmcEL5001.template
ecmcEL5002.substitutions
ecmcEL500X-chX.template
ecmcEL5021.substitutions
ecmcEL5021.template
ecmcEL5101.substitutions
ecmcEL5101.template
ecmcEL7037.substitutions
ecmcEL7041-1000.substitutions
ecmcEL70X7.template
ecmcEL72XX_DRV.substitutions
ecmcEL72XX_DRV.template
ecmcEL72XX_ENC.substitutions
ecmcEL72XX_ENC.template
ecmcEL9410.template
ecmcEL9505.template
ecmcEL9576.template
ecmcEvent.db
ecmcExpression.db
ecmcFB_DriveVirtual_v1_01.db
ecmcFIODrive_DRV.substitutions
ecmcFIODrive_DRV.template
ecmcFIODrive_ENC.substitutions
ecmcFIODrive_ENC.template
ecmcGeneral.db
ecmcGenericAnalog.db
ecmcGenericAnalogInput.db
ecmcGenericAnalogOutput.db
ecmcGenericDigital.db
ecmcGenericDigitalInput.db
ecmcGenericDigitalOutput.db
ecmcIPOS4808_AUX.substitutions
ecmcIPOS8020_AUX.substitutions
ecmcIPOSXXXX_AUX.template
ecmcIPOSXXXX_DRV.substitutions
ecmcIPOSXXXX_DRV.template
ecmcIPOSXXXX_ENC.substitutions
ecmcIPOSXXXX_ENC.template
ecmcMbbiDirect.template
support_list.txt

------------------------------

_______________________________________________
Tech-talk mailing list Tech-talk@aps.anl.gov https://mailman.aps.anl.gov/mailman/listinfo/tech-talk


End of Tech-talk Digest, Vol 13, Issue 281
******************************************

References:
RE: [EXTERNAL] Beckhoff BK9000 support survey Wallace, Alex via Tech-talk
RE: [EXTERNAL] Beckhoff BK9000 support survey GAGET Alexis via Tech-talk

Navigate by Date:
Prev: Usage of pvlist Shen, Guobao via Tech-talk
Next: Re: Fwd: cross-compiling (kind of) with Buildroot Pierrick M Hanlet via Tech-talk
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  <20192020 
Navigate by Thread:
Prev: RE: [EXTERNAL] Beckhoff BK9000 support survey GAGET Alexis via Tech-talk
Next: Re: [EXTERNAL] Beckhoff BK9000 support survey Jeong Han Lee via Tech-talk
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  <20192020 
ANJ, 03 Jul 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·