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: Torsten Bögershausen via Tech-talk <tech-talk@aps.anl.gov>
To: Jörn Dreyer <j.dreyer@hzdr.de>, <tech-talk@aps.anl.gov>
Date: Tue, 2 Jul 2019 10:34:29 +0200
Hej Jörn and all,

I think that we have a driver here:

<https://bitbucket.org/europeanspallationsource/m-epics-twincat-ads/src/master/>

(However, I am working on an implemtation without the Beckhiff ADS library,
and written in C)

BR
/Torsten



On 01/07/19 13:45, Jörn Dreyer via Tech-talk wrote:
Hi Torsten,

some time ago I was thinking about writing an EPICS driver based on asyn and
libADS from Beckhoff. But that got stalled due to other more urgent projects .

For me that would also make sense, as you can thencan  talk to a PLC program
running on an BX or CX Controller. Otherwise you need to implement some
communication method in your PLC program, resulting in additional license fees
for the corresponding TwinCAT module.

Regards
Jörn

Am Montag, 1. Juli 2019, 13:01:43 CEST schrieb Torsten Bögershausen via Tech-
talk:
Hej Hinko,

the short answer: No.

The longer answer:
The BK9000 is part of a series of terminals that are from the
pre-EtherCAT time.
Still useful, still in use, terminals are named EKxxxx.

What ESS is heading for is EtherCAT as a standard, and that does
exclude the BK9000.

The general question is, why do you (or anybody else) want to use the
BK9000 together with EtherCAT sustems (the ELxxxx terminals)

So in theory the ECMC can be enhanced to talk to the BK900.
but we don't see a use case for this.
(And feel free and invited to visit us in the motion lab).

Another question; If somebody want to  use ADS (instead of modbus)
to connect the EPICS IOC with the Beckhoff world, please let me know.

/Torsten

On 01/07/19 11:30, Hinko Kocevar via Tech-talk wrote:
Hi Han,

would the asyn driver that ESS has work with the coupler in subject -
BK9000?

Thanks,
//hinko
________________________________________
From: tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov> on
behalf of Jeong Han Lee via Tech-talk <tech-talk@aps.anl.gov> Sent:
Sunday, June 30, 2019 4:26:26 PM
To: Dunning, Michael; tech-talk@aps.anl.gov
Subject: Re: [EXTERNAL] Beckhoff BK9000 support survey

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




References:
Beckhoff BK9000 support survey Dunning, Michael via Tech-talk
Re: [EXTERNAL] Beckhoff BK9000 support survey Hinko Kocevar via Tech-talk
Re: [EXTERNAL] Beckhoff BK9000 support survey Torsten Bögershausen via Tech-talk
Re: [EXTERNAL] Beckhoff BK9000 support survey Jörn Dreyer via Tech-talk

Navigate by Date:
Prev: RE: [AsynDriver] getAddress and callbacks Joao Afonso via Tech-talk
Next: Question regarding a waveform record and writeOctet Wlodek, Jakub 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 Jörn Dreyer 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, 02 Jul 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·