EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  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  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: MODBUS communication with H2-ECOM100 AuotmationDirect DL205 system?
From: Rolf Keitel <[email protected]>
To: Mark Rivers <[email protected]>
Cc: tech-talk <[email protected]>
Date: Sat, 24 Feb 2007 08:42:20 -0800
Hi Mark,

funny that you should write this today. I was working on the stuff for the last few days, because I need to talk to Modicon PLCs form Linux, too. We have some problems - intermittent IOC hang-ups on the several days to weeks level - running VxWorks on Intel architectures. I hope running modtcp on Linux will help us to zoom in on the VxWorks problem.

I had asyn in the back of my mind, but am not with the Asyn Driver. As I don't know if and when I will have time to look at asyn, , I chose to go the quick and dirty route:
I took the NSLS port to linux and merged it with my latest version.
What I have at the moment (not yet stress-tested) is structurally the same as the old modtcp.
It compiles/builds for Linux (EPICS 3.14) and VxWorks (EPICS 3.13 and 3.14).
It supports both Modicon PLCs and Siemens PLCs (with TCP/IP module using the Siemens Fetch/Write paradigm). The WAGO support is a conditional compile, I just took over the NSLS mods. This could easily be parameterized instead of the conditional compile.


If you want to move this over to Asyn, I would urge you to start on this newer version because of the included Siemens support.

- rolf -

Mark Rivers wrote:
Hi Rolf and Ivan and all,
I've taken the NSLS version of modtcp and got it running on our Linux system, talking to the Automation Direction PLC. Thanks for all the work.
The main problems with the current versions are that the Triumf version on works on vxWorks, and the NSLS version only works on Linux (and only on the Wago PLC because some offsets and conversion are hardcoded in it).
Here is my first question:
- Do you know of any other sites that might have already done a 3.14 OSI conversion? How are new accelerators (Diamond, Australian, Canadian) communicating to PLCs from EPICS? Are they using MODBUS or some other protocol?
Assuming the work has not already been done, here are my plans:
- Convert the underlying TCP support to eliminate modtcpLib.c and replace it with the asyn TCP/IP driver. That way it is portable to Windows and other platforms. It also allows turning on more specific debugging for a single PLC and for specific layers (device support, driver support, etc.).
- Convert drvModtcp.c so that its interface to device support is the asynInt32 and asynUInt32Digital interfaces of asyn, rather than the modtcpWrite and modtcpRead functions. With this change devModtcp.c is no longer needed, because the generic asyn EPICS device support can be used. I think the only enhancement to the generic asyn device support that is needed is to support both bipolar and unipolar device readings, which I think is not currently done. That is easy to add.
- Convert all code to replace vxWorks specific calls with EPICS OSI calls, rather than using the conversion libray that NSLS used.
- Change all of the time values that are used in the startup script from ticks to msec. That way integers can still be used from the vxWorks shell (where doubles are not allowed on PowerPC). Convert all time parameters to doubles (in seconds) when the functions are not to be called from the vxWorks shell.
- Make the MODBUS read and write offsets be parameters to modtcpDrvCreate, rather than hardcoded to 400000. This will allow for the WAGO to be supported, since it has a different offset for one operation. I think some PLCs can use 300000 rather than 400000 as well, right?
Rolf, I had a few questions for you.
- How important is the SO_KEEPALIVE socket option? I looked at the asyn TCP/IP driver and it does not seem to use that. - There does not seem to be any semaphore to prevent device support from reading the buffer memory at the same time as the read polling task is writing to it. Similarly there is no semaphore to prevent the write task from copying from the buffer at the same time device support is modifying it. Is this because you used task priorities to prevent conflicts? If so, we need to think about how to do this in 3.14 where some systems I believe don't have priority scheduling.
I'd appreciate any comments or suggestions on my plans.
Thanks,
Mark




--
| Rolf Keitel, TRIUMF | Electronics and Controls Groups Manager
| Engineering Division
| Tel: (604) 222-7453 Fax: (604)222-7307
| e-mail: [email protected]



References:
RE: MODBUS communication with H2-ECOM100 AuotmationDirect DL205 system? Mark Rivers
RE: MODBUS communication with H2-ECOM100 AuotmationDirect DL205 system? Mark Rivers

Navigate by Date:
Prev: RE: MODBUS communication with H2-ECOM100 AuotmationDirect DL205 system? Mark Rivers
Next: RE: MODBUS communication with H2-ECOM100 AuotmationDirect DL205 system? Denison, PN (Peter)
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: MODBUS communication with H2-ECOM100 AuotmationDirect DL205 system? Mark Rivers
Next: RE: MODBUS communication with H2-ECOM100 AuotmationDirect DL205 system? Denison, PN (Peter)
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Nov 2011 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·