Re: MODBUS communication with H2-ECOM100 AuotmationDirect DL205 system?

[Rolf Keitel <rolf@triumf.ca>]

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: rolf@triumf.ca