| 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 | 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 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: [EXTERNAL] Beckhoff BK9000 support survey |
| From: | Jeong Han Lee via Tech-talk <[email protected]> |
| To: | "Dunning, Michael" <[email protected]>, "[email protected]" <[email protected]> |
| Date: | Sun, 30 Jun 2019 10:26:26 -0400 |
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.pdfWe'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 pointIn 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
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