Experimental Physics and
Industrial Control System

The links to the Modbus and asyn module documentation should be updated to these:

 

https://epics-modbus.readthedocs.io/en/latest                                                                   Modbus Protocol manual.

https://epics-modules.github.io/master/asyn/R4-42/asynDriver.html#drvAsynIPPort     Asyn Support manual, the version we are using at my facility.

 

Mark

 

 

 

 

 

Hi Greg,

 

It’s ironic the first EPICS device support you take on was also the first I worked on.  This support was a challenge in several ways but we finally got it figured out.  First to address the device itself, the Watlow temperature controller.  My experience with these devices is not tremendous but what I had found during the development is you will need to have a good reference of the functions and Modbus addresses of these functions for your specific module.  The part numbers identify the features in the module and not everything is equivalent between the model numbers, not even if they are in the same series.  This device support I developed covers a large portion of the capabilities within this specific module so you might consider trimming that down initially to the simple set and read the temperature.  I will check on the part number I have published on the Github site to make sure it’s correct.  Also, there are two Modbus addressing schemes.  With this device support we used Map 2 addressing.

 

Marcio made several good points about what needs to be updated to make the IOC function.  Refer to the EPICS Developers Guide and the Record Reference Manual as well as these references to use when reconstructing the IOC if you don’t already have them:

 

https://cars9.uchicago.edu/software/epics/modbusDoc.html                                                     Modbus Protocol manual.

https://epics.anl.gov/modules/soft/asyn/R4-18/asynDriver.html#drvAsynIPPort                  Asyn Support manual, the version we are using at my facility.

 

 

The reasons behind why the information was removed from the IOC is due to the unique nature of how our network architecture would vary as compared to any other facility such as yours.  Also, how our macro naming conventions would not be applicable to other facilities.  This information needs to be provided by the end user.  The ‘st.cmd.ModbusAddresses Only’ will not function without several additional fields added, again, to maintain generic functionality.  Once you run the command ‘makeBaseApp.pl -i -t ioc <name_of_your_ioc>’ as Marcio mentioned you would be able to plug in the Asyn and Modbus information from the ‘st.cmd.ModbusAddresses Only’ file.

 

Also, in the substitution files, the macro needing defined, the ‘s’ field, will need updated as you will define them for your facility.  We use this macro as our instrument identifier but you can use it however works best for you.  I just realized not all of those are necessary, such as the ioc_sns_db group so they can be removed.  We have also implemented the putCallback function and the Autosave function, as seen in these substitution files.  If you do not plan to use these or initially use them, either delete them or comment them out respectively.

 

Once you have your macros defined you will need to go into the OPI files and update those macros as well.  As for remaining any files, I don’t believe that is necessary unless you have reasons to on your side.