Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Sat, 24 Feb 2007 08:27:57 -0600

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System