Hi All,
Thanks Torsten for this clear answer.
Still, not for the production, but I think, it is enough to see the
ethercat master (open source) performance to match a PLC level.
I am sure that test results are limited due to "kernel version, RT
configuration, OS type, and Intel hardware".
It is a good subject which we can present to the EPICS community this
Fall, or next Spring meeting.
FYI, the test platforms are
* CentOS 7 (RH 3.10 kernel + CERN RT packages) with ethercat generic
and native e1000e driver
* Debian 9 (Vanilla 4.9 kernel + Debian RT packages) with ethercat
generic and native e1000e driver
* On several old Intel NUC PCs, and Concurrent CPU (old, discontinued)
We saw the performance of the native driver (e1000e) is much better
than a generic one, and Debian is better than CentOS. :)
HTH,
Han
On 7/1/19 7:01 AM, Torsten Bögershausen wrote:
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: [email protected] <[email protected]> on
behalf of Jeong Han Lee via Tech-talk <[email protected]>
Sent: Sunday, June 30, 2019 4:26:26 PM
To: Dunning, Michael; [email protected]
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
<[email protected]> 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
<[email protected]<mailto:[email protected]>> 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 Pearson, Matthew R. via Tech-talk
- Re: [EXTERNAL] Beckhoff BK9000 support survey Mark Rivers via Tech-talk
- Re: [EXTERNAL] Beckhoff BK9000 support survey Dunning, Michael via Tech-talk
- Re: [EXTERNAL] Beckhoff BK9000 support survey Jeong Han Lee 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
- Navigate by Date:
- Prev:
EPICS Documentathon Timo Korhonen via Tech-talk
- Next:
RE: [EXTERNAL] Beckhoff BK9000 support survey Wallace, Alex 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
<2019>
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: [EXTERNAL] Beckhoff BK9000 support survey Torsten Bögershausen via Tech-talk
- Next:
Installing 'std' module to use epid record Christopher Herrmann 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
<2019>
2020
2021
2022
2023
2024
|