> 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
- Replies:
- Re: [EXTERNAL] Beckhoff BK9000 support survey Dunning, Michael via Tech-talk
- References:
- Beckhoff BK9000 support survey Dunning, Michael via Tech-talk
- RE: [EXTERNAL] Beckhoff BK9000 support survey Pearson, Matthew R. via Tech-talk
- Navigate by Date:
- Prev:
Re: How is 'exit()' different for the IOC shell? Kasemir, Kay 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
- Navigate by Thread:
- Prev:
Re: [EXTERNAL] Beckhoff BK9000 support survey Eric Norum via Tech-talk
- Next:
Re: [EXTERNAL] Beckhoff BK9000 support survey Dunning, Michael 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
|