RE: Getting started talking to a device

["Leblanc, Gregory via Tech-talk" <tech-talk at aps.anl.gov>]

Gary,

 

Thanks for the feedback.  I’m new to the nuclear physics business, but we talked to these devices all the time using Kepware and various PLCs in my last life.  Like most programming projects, I’m trying to scratch an itch.  I have this temp controller installed, and it doesn’t talk to our existing in-house software, so EPICS seemed like it might be a good fit.  OTOH, I might be biting off more than I can chew here. There are only 2 engineers for the lab, and both of us know just enough programming to be dangerous. 

     Greg

 

From: Taufer, Gary <tauferga at ornl.gov>
Sent: Tuesday, August 10, 2021 11:02 AM
To: Paduan Donadio, Marcio <marcio at slac.stanford.edu>; tech-talk at aps.anl.gov; Leblanc, Gregory <leblanc at ohio.edu>
Subject: RE: Getting started talking to a device

 

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.

 

 

Gary Taufer

DAQ Integration Software Engineer

Instrument Data Acquisition Integration Group

Neutron Technologies Division

 

1 Bethel Valley Road

P. O. Box 2008, MS6430
Oak Ridge, TN 37831-6430

Office: 865-574-2559 |  Fax: 865-241-6770

Email: tauferga at ornl.gov

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Paduan Donadio, Marcio via Tech-talk
Sent: Friday, August 6, 2021 11:16 PM
To: tech-talk at aps.anl.gov
Subject: [EXTERNAL] Re: Getting started talking to a device

 

Hello, Greg.

 

All you have is the git repo that you've mentioned?

 

To build an IOC you will need a configure directory, with configure/RELEASE (or configure/RELEASE.local) pointing to the needed modules, like Asyn. You will also need a Makefile on your IOC application root directory. The st.cmd file usually goes inside an iocBoot/<ioc_name> directory.

 

My recommendation: assuming that you have EPICS base installed, create a new directory where you want to place your IOC application and, inside it, start a new IOC application directory structure using

 

makeBaseApp.pl -t ioc <name_of_your_ioc_application>

 

Then copy the contents of the Watlow-PM/Watlow_PM862FJ-3LEJAA_Module/watlowApp/Db/ directory to <name_of_your_ioc_application>App/Db.

 

Next, change your configure/RELEASE file, by adding the path to where you've installed Asyn. You must add to the <name_of_your_ioc_application>App/src/Makefile, the Asyn library and dbds:

 

<your_application>_DBD += asyn.dbd

<your_application>_DBD += drvAsynIPPort.dbd

<your_application>_LIBS += asyn

 

The DBDs provides you with the functions used in the IOC shell, like drvAsynIPPortConfigure.

 

See if issuing make brings a successful build.

 

Still inside the IOC application top directory use

 

makeBaseApp.pl -i -t ioc <name_of_your_ioc>

 

This will create an iocBoot/<name_of_your_ioc> directory. Overwrite the st.cmd file with "st.cmd.ModbusAddresses Only" and rename it back to st.cmd.

 

This st.cmd from the repo only initializes the driver but doesn't load the databases. Without loading the databases, you will have no PV to read/write in the network.

 

I hope that the IOC application maintainer can contact you to describe which databases to load for your case. I know nothing about the Watlow controller and couldn't help with this.

 

HTH.

 

 

Márcio Paduan Donadio | Control Systems Engineer Advanced Control Systems Department SLAC National Accelerator Laboratory | Menlo Park, CA p: 650.926.5007 | w: slac.stanford.edu

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Leblanc, Gregory via Tech-talk <tech-talk at aps.anl.gov>
Sent: Friday, August 6, 2021 1:27 PM
To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Getting started talking to a device

 

Hi folks,

 

I’m still poking around at this whole EPICS thing, attempting to get my feet wet.  I thought that I might try to talk to a temp controller I have on our Cs Sputter source here.  Currently we only adjust the setpoint by walking into the vault and using Bluetooth on our phones.  The controller is an EZ-ZONE model number PM6C1CA-GAAAAAA.  We have an ethernet module for it, and it’s picked up an address from DHCP, which I can ping from the Raspberry Pi where I’ve installed EPICS Base. 

 

I found the pieces that Gary published at https://github.com/tauferg/Watlow-PM though I can’t find the controller mentioned on the Watlow website.  I cloned via git and determined that the second parameter to drvAsynIPPortConfigure should be the ip address.  From Watlow_PM862FJ-3LEJAA_IOC/st.cmd.ModbusAddresses\ Only I have:

drvAsynIPPortConfigure("watlow1", "10.0.0.196", 0, 0, 0)

 

The next step, per README.md is to “Rename the files and place in the appropriate directories.”  Which files need to be renamed, and where do they need to be placed?  What is the next step here, or do I need to back up and continue working on the st.cmd file?  Any pointers appreciated.

     Greg

 

--

Gregory Leblanc

Accelerator Engineer

Edwards Accelerator Lab - Ohio University

123 University Terrace

Athens, OH 45701

leblanc at ohio.edu

M: (401) 52-OUAL1 or (401) 526-8251