Low Voltage Vontrol Applications

From GlueXWiki
Jump to: navigation, search

MPOD Low Voltage Crate Control

Wiener MPOD Hardware Configuration

Fernando got a Wiener MPOD crate with a controller and one MPV.8008L card and one EHS F205p-F card. I obtained a IP address for this controller on 36 subnet. First I did not do any USB-based installations and in principle it worked on the network:

harpo:snmp> sudo /sbin/arping halldmpod1
ARPING from eth0
Unicast reply from [00:50:C2:2D:CC:01]  1.862ms
Unicast reply from [00:50:C2:2D:CC:01]  1.850ms
Sent 2 probes (1 broadcast(s))
Received 2 response(s)

There was some problem getting it on the network. When it boots, it seems to obtain the correct address via DHCP, which is evident from the IP number shown on the front-panel display. But does not respond to pings. When I manually put static IP address through the front panel, then it responds to pings. The MPOD controller has an Ethernet interface that provides an SNMP-based service. I quickly checked that the controller responds to SNMP commands. But I could not access the chassis using web browser. It might be related to a bug which Andreas Ruben told Fernando in an email. Therefore, I decided to update the firmware and setup the chassis again via USB port using the instructions in the MPOD Technical Manual .

To update the firmware I downloaded their software MUSEcontrol software, version 2.0.1491.0. I also downloaded their MPOD software bundle. The bundle also contained the MUSEcontrol program, but an older version, 2.0.1437.0, so I did not use it. I installed firmware version 2.1.1496.0 from the bundle. Version 2.0.1399.0 was installed in the controller. After firmware upgrade I setup the network via USB port using the MUSEcontrol software from Wiener, it is now using static IP address and seems to work right after power recycling without having to play with the front panel.

I see a mismatch between the nominal voltage reading on the LCD screen on the chassis and the browser on one hand, and the MUSEcontrol via USB on the other hand. If I change the nominal voltage setting on MUSEcontrol, then the measured values change on the browser, LCD and the MUSEcontrol, but the nominal voltage setting in the browser and the LCD screen do not change. If I change the nominal setting on the LCD screen with the rotating knobs, then I see the change in the browser and in the MUSEcontrol program. The same thing happens with the current limit nominal setting. This is something which might not be a big deal, but may be it can be fixed easily. I sent an email to Andreas Ruben regarding this issue.

Yi also noticed that MPOD crates stop communicating over Ethernet, both SNMP and the web browser. There is no response to ping either. Yi uses Labview driver over SNMP. We observe the same thing when we prepare for mini BCAL test in Hall B. the network settings are set to DHCP. The frequency of rebooting seems to depend on the intensity of the activities. On average it happens about twice a day. To restart the communications one needs to pull out the Ethernet cable, turn the main switch off on the front panel of the chassis, turn it back on, and after a few seconds reconnect the Ethernet cable. We decided to try to fix some of the ports on the Hall D switch in EEL 126 to the 36 subnet, and then use static IP addresses for MPOD crates, and see if this still happens.

We will use the SNMP over Ethernet to control the low and bias voltages on the MPOD boards.

SNMP Driver/Device Support from NCSL

I got a generic EPICS SNMP driver/device support from John A. Priler (priller@nscl.msu.edu) called snmp-nscl-0.9.8. It was their version of the SNMP driver which apparently they originally obtain from DESY. We probabhly could have used the one from DESY. But NCSL actually used this package for MPOD crate control, so I decided to use that instead. John also sent me an example of an EPICS database file which utilizes their SNMP device support.

I went ahead and un-tarred the tar-ball in /group/halld/Online/controls/epics/support/ directory. Then I had to modify the configure/RELEASE file adding the following two lines to it:


I was able to compile the snmp-nscl-0.9.8 for 32-bit RHEL5 Linux. But compilation of 64-bit Ubuntu 10.04 failed because of some syntax error:

make[3]: Entering directory `/group/halld/Online/controls/epics/support/snmp-nscl-0.9.8/snmpApp/src/O.linux-x86_64'
perl /group/halld/Online/controls/epics/base/bin/linux-x86_64/makeIncludeDbd.pl base.dbd devSnmp.dbd ../O.Common/snmpInclude.dbd
Expanding dbd
/group/halld/Online/controls/epics/base/bin/linux-x86_64/dbExpand  -I . -I .. -I ../../../dbd -I/group/halld/Online/controls/epics/base/dbd  -o ../O.Common/snmp.dbd ../O.Common/snmpInclude.dbd
Installing created dbd file ../../../dbd/snmp.dbd
/usr/bin/g++ -c  -D_POSIX_C_SOURCE=199506L -D_POSIX_THREADS -D_XOPEN_SOURCE=500           -D_X86_64_  -DUNIX  -D_BSD_SOURCE -Dlinux  -D_REENTRANT   -O3   -Wall      -m64     -g -fPIC -I. -I../O.Common -I. -I.. -I../../../include/os/Linux -I../../../include -I/group/halld/Online/controls/epics/base/include/os/Linux -I/group/halld/Online/controls/epics/base/include  -I/group/halld/Online/controls/epics/extensions/include        ../devSnmp.cpp 
../devSnmp.cpp: In constructor ‘devSnmp_device::devSnmp_device(devSnmp_manager*, devSnmp_group*, dbCommon*, link*, char*, bool*)’:
../devSnmp.cpp:2659: error: cannot convert ‘unsigned int*’ to ‘size_t*’ for argument ‘3’ to ‘int get_node(const char*, oid*, size_t*)’
../devSnmp.cpp:2660: error: cannot convert ‘unsigned int*’ to ‘size_t*’ for argument ‘3’ to ‘int read_objid(const char*, oid*, size_t*)’
make[3]: *** [devSnmp.o] Error 1
make[3]: Leaving directory `/group/halld/Online/controls/epics/support/snmp-nscl-0.9.8/snmpApp/src/O.linux-x86_64'
make[2]: *** [install.linux-x86_64] Error 2
make[2]: Leaving directory `/group/halld/Online/controls/epics/support/snmp-nscl-0.9.8/snmpApp/src'
make[1]: *** [src.install] Error 2
make[1]: Leaving directory `/group/halld/Online/controls/epics/support/snmp-nscl-0.9.8/snmpApp'
make: *** [snmpApp.install] Error 2

Note, that this package was not pure "support", but it also contains an IOC and an example database file for some router control. To avoid conflicts I commented out some lines in the src/Makefile which were building the IOC and were also compiling some registration functions. Instead, I moved the two source files snmpRegister.cpp and snmpSessShow.c into our application.

< #devSnmp_SRCS += snmpRegister.cpp
< #devSnmp_SRCS += snmpSessShow.c
> devSnmp_SRCS += snmpRegister.cpp
> devSnmp_SRCS += snmpSessShow.c
< #PROD_IOC = snmp
> PROD_IOC = snmp
< #DBD += snmp.dbd
> DBD += snmp.dbd
< #snmp_DBD += base.dbd
> snmp_DBD += base.dbd
< #snmp_DBD +=  devSnmp.dbd
> snmp_DBD +=  devSnmp.dbd
< #snmp_SRCS += snmp_registerRecordDeviceDriver.cpp
< #snmp_SRCS_DEFAULT += snmpMain.cpp
< #snmp_SRCS_vxWorks += -nil-
> snmp_SRCS += snmp_registerRecordDeviceDriver.cpp
> snmp_SRCS_DEFAULT += snmpMain.cpp
> snmp_SRCS_vxWorks += -nil-
< #snmp_OBJS_vxWorks += $(EPICS_BASE_BIN)/vxComLibrary
> snmp_OBJS_vxWorks += $(EPICS_BASE_BIN)/vxComLibrary
< #snmp_LIBS +=  devSnmp    #main devSnmp lib
> snmp_LIBS +=  devSnmp    #main devSnmp lib
< #    snmp_SNCFLAGS += +r
< #    snmp_DBD += sncExample.dbd
< #    snmp_SRCS += sncExample.stt
< #    snmp_LIBS += seq pv
>     snmp_SNCFLAGS += +r
>     snmp_DBD += sncExample.dbd
>     snmp_SRCS += sncExample.stt
>     snmp_LIBS += seq pv
< #    PROD_HOST += sncProgram
< #    sncProgram_SNCFLAGS += +m
< #    sncProgram_SRCS += sncProgram.st
< #    sncProgram_LIBS += seq pv
< #    sncProgram_LIBS += $(EPICS_BASE_HOST_LIBS)
>     PROD_HOST += sncProgram
>     sncProgram_SNCFLAGS += +m
>     sncProgram_SRCS += sncProgram.st
>     sncProgram_LIBS += seq pv
>     sncProgram_LIBS += $(EPICS_BASE_HOST_LIBS)

This way I only crate the support part The library gets installed in nmp-nscl-0.9.8/lib/$EPICS_HOST_ARCH directory, similar to ether_ip support.

Later we decided to crate $EPICS/drivers directory for Hall D where we will keep the drivers that are need for Hall D slow controls but are not considered as an integral part of EPICS and not readily downloaded from the web. Nerses moved the NCSL EPICS support for SNMP to the $EPICS/drivers/snmpApp directory. All our SNMP-based EPICS applications should work through this library.

In order to be able to work with NCSL SNMP EPICS driver I had to modify src/dbStatic/dbStaticLib.c to increase the length of the links from 80 to 256. This was done following the recommendation by John Priller who provided me with the driver from NCSL. Seems to work.

    case DBF_FWDLINK: {
	    DBLINK	*plink;
	    char	string[256];
	    char	*pstr = string;
	    int		ind;

	    if (!pfield)
	        return S_dbLib_fieldNotFound;

First MPOD Chassis Application

In order to control our MPOD chassis using SNMP we need to create EPICS application utilizing an SNMP driver. I tried to use the SNMP driver which came with the VME/VXS power supply application, but somehow writing "ao" records failed with that SNMP driver. So I decided to use the NCSL SNMP driver at least to control MPOD chassis in Hall-D. For the first try, I created an application called mpodChassis which contained the EPICS database and the IOC executable code. The database is based on an example from NCSL. At this point separate executables are used for MPOD and VME crates, but when VME crates are moves to the NCSL SNMP driver we will use a single executable for all SNMP devices.

  • One of the tricky thing in the syntax for the INP and OUT fields was the mask parameter. When I asked John Priller about it he told me the mask specifies where to start reading the string from the SNMP when trying to convert to numerical values. Usually the mask is something like "INTEGER:" telling the driver to start readings the integer number after ":" symbol. But for instance for enumerated type the mask is "(" so that an SNMP string like "outputOn(0)" yields an integer value zero which is between the brackets.
  • When MPOD crate is turned OFF all readback voltages stop to exist for SNMP requests, and the corresponding EPICS record status turns INVALID with RED alarm. When the chassis is turned back ON all channels come back in OFF state and the voltage set points are set to zero for the EHS HV card. On the 8008 card the voltage set-point is preserved, but the channel still is restored in OFF state. So, somehow the status and set-points of the channels needs to be remembered on the IOC. So, the best practice would be to never turn off the chassis and implement chassis- and board-wide operations in the EPICS application.
  • Dealing with SNMP type BITS turned out to be a little bit of hassle. BITS themselves are octet strings like "80 01", but when NCSL SNMP driver reads them in addition to the octet string we get an interpretation of the octet string "80 01 outputOn(0) 15", where "outputOn(0) 15" is supposed to tell us that in "80 01" octet string bits "0" and "15" are set and that bit "0" is called outputOn and bit "15" does not have ant name. Fortunately, BOY allows scripts to run before displaying the values, so in the screens I crated for this application I parsed the SNMP string in the stringin type EPICS record and extracted the numerical parts and the bit names, whichever was needed for a given widget on the BOY screen.
  • The database for this application is loaded via templates using substitution files from the common db directory, which means that the EPICS database is defined at make-time. This is because, as far as I know, there is no way to load a template with that itself has a macro that can be assigned a value at the loading time. What we would like to have is a system, both for HV and LV, that configures its database (and the alarm system) at loading time so that we do not need to re-make the application each time a small change made in the hardware configuration.

Tagger microscope Bias Voltages

Embedded computer

To interface with microscope control boards with EPICS we needed an robust embedded computer with at least two Ethernet ports. I ordered two V24002LX embedded computers from MOXA to serve as the bridge between UCONN protocol and the EPICS ChannelAccess. The computers arrived and looked very niced, clearly without any fans, holes for ventilation etc. Although I ordered the power cords that they were recommending on their web site, the cord that came was simply a laptop pwer cord, while what MOXA needs is basically someone to wire the power lines into the green connector on the back of the enclosure box. This was not much of a big deal though.

Problem with the installation of Debian on MOXA

In general the Debian 5 (lenny) that MOXA came with worked fine. But when I tried to install EPICS on it it turned out the there are serious issues with the compiler. It could not find the location of the C++ include file, and even when I pointed the location of the include files through Makefile variables, it still could not resolve its own include files. It was clear that installing Linux system was very desirable. I decided to use Ubuntu 12.04 LTS since it was closer to Debian than RedHat. For installation of the Ubuntu, I created an USB installation disk out of the CD image file using Linux tools for creating a bootable USB disk.

Linux installation

I used the follwing partitioning for the MOXA hard drives for Ubuntu 12.04 LTS installation

  • Use all of the /dev/sda as swap area
  • Install the rest of the system on the 8GB SanDisk Extreme CompactFlash 60MB/s drive (/dev/sdb)
  • Note that when I do this, the bootable partition is still /dev/sda1, so this disk will need to be cloned as well to make a backup, at least the master boot record. I used user "hovanes" as the forst user to setup the operating system. The packages that need to be installed after CD installation with updating are:
emacs synaptic ssh bootp libreadline6-dev procServ gnome-system-tools tcsh g++ bum re2c 

The packages that need to be uninstalled after CD installation with updating to safe space on disk are:

  • Create a new user "hdops" with the hdops standard password (uid=8374(hdops)).
  • Using "sudo passwd root" enable root password so that this computer can be managed by Hall D people who know the standard online root password.
  • Using Boot-Up manager enable "ssh" service and disable "acpi-support"

EPCIS Installation

  • Get the EPICS BASE version R3-14-12-3, unzip it in /usr/local/epics/R3-14-12-3, create a soft link called "base->base-3.14..12.3"change the EPICS variables in the "base/startup/Site.cshrc" file and build the EPICS base using standard make without any other modifications.
  • Bring in the following support modules into the "/usr/local/epics/R3-14-12-3/support" directory:
asyn4-21.tar.gz  ipac-2.11.tar.gz  seq-2.1.12.tar.gz

Unzip the files, change the configure/RELEASE files to have the following content:

include $(TOP)/../RELEASE_2_INCLUDE

and create the RELEASE_2_INCLUDE file in the support directory with a content like this




Build the support modules in the order they are listed in the RELEASE_2_INCLUDE file. For each support module first clean and make the "configure" directory, then go one directory up and build the support module.