Recipes for ngFEC server

Upload firmware to FC7 board

Check if the process ngCCM is running:

ps -ef | grep ng

If not, you need to log in to and run the following command and wait for a few minutes.


To start the client, type:

/opt/ngFEC/ngFEC.exe -c -p 64100

Upload the firmware using the ngFEC server:

tput fec-fg go_offline
boot fec /home/wusx/fc7_top

Some tests suggested by Alan Campbell

# a few ngccm CLI commands
# these commands can be run at BU
# start the CLI and attach to server on port 64100
/opt/ngFEC/ngFEC.exe -c -p 64100
# the CLI will start and print a few lines of help
# it also loads the list of variables defined in the server so that they are known to the
# get and put commands
# normally a CLI returns a reply line to each command line
# when typing commands by hand it can be more readable to allow a tabular layout of replies
# this is toggled with command
# there is a further variant of this 'table compact'
# also it can be useful to have the time printout with each reply
# this can be toggled with
# now we have the CLI setup we can issue a command to the server
get ccmserver_version
# get is the basic command to read a variable
# it supports command completion with TAB
# you can recall the last command with up arrow key and rerun it with enter key
# you can also give multiple variables and specify ranges in square brackets eg
get fec-sfp[1-12]_ngccm_dv fec-cdce_pll_unlock_clock_cnt
# HE1-fec_bx_delay is a parameter in the FEC
get HE1-fec_bx_delay
# to write to a parameter use the put command
#put parameter value
put HE1-fec_bx_delay 1
# this also supports parameter name completion with TAB
# and multiple parameters and values in the same command 
# the server distiguishes between read-only R , read-write P and writeonly W parameters
# the server assigns parameters to guardians , the guardians are organised in a tree structure
# the guardian is responsible for periodic readback of its R parameters, readback and verification of its P parameters
# and can be told to write out all its P and W parameters to the hardware
# in addition the guardian defines a state from the state of all its variables
# and guardians with name ending in -Xg with X a letter have a special task defined by the letter X
# the commands tget and tput are useful for interecting with guardians
# tget is used like get but is appended with an additional string of letters which selects the information you want:
# n:name f:flag r:read_value w:write_value s:run_state R:read_only_items
# W:write_only_items P:readwrite_items digit:recursion_depth I:immediate_read
# a:show_a_flag D:show_disabled_only X:show_extra Y:show_less
# The guardian at the top of the tree is always called ccmserver-g , so a useful command to see what has been declared for the server is
tget ccmserver-g fns3G
# this says ... give me the status flag f , the name n, the state s , to 3 levels up the tree 3 , and show guardians
# we see that there is a fec named fec defined. It has a guardian fec-ig and above that a guardian fec-fg .
# The fec-ig guardian handles ipbus failures , the fec-fg guardian handles all the fec internal variables.
# The HE*-lg guardians handle the front end links.
# look another 3 levels up from RBX HE1 with:
tget HE1-lg fns3G
# we see the guardians responsible for the CCM -cg , the backplane power -pg , the RMs and SIPM control -x-g , -xs-sg and CU -calib-g
# to get a list of all the R ( read-only ) variables in the FEC we use:
tget fec-fg fnrR1
# here we ask for flag f , name n , readback value r from R variables , to depth 1
# this displays the current values known to the server, so the values read on the servers last readback cycle
# you can force a reread from the hardware by adding an I ( immediate_read )
tget fec-fg fnrR1I
# the tget command can also be used for variables as well as guardians eg
tget fec-qie_reset_ontime_cnt fnrRI
# will read and display fec-qie_reset_ontime_cnt
# alternatively the get command can be used to force an immediate read and display by appending _rr to the variable name
get fec-qie_reset_ontime_cnt_rr
# another example :
tget HE1-lg fnrw1P
# this asks for the flag f ,name n ,readback value r , written value w to depth 1 of parameters P ( readwrite variables ) in HE1-lg guardian
# you see in the result
_ HE1-fec_bx_delay 1 1
# as the HE1-fec_bx_delay although physically in the FEC should be written whenever the RBX is setup and so is assigned to the -lg guardian
tget HE1-fec_bx_delay fnrw
# can be used to get the same result
# the tput command is used to send a one word command to guardians or variables
# the word is given after the variable list
# tput variables push
tput HE1-lg push
# this will attempt to setup all the hardware in RBX HE1
# it will write all the values as given in the latest put commands.
# Should the hardware be off when a put command is issued, the hardware write will fail and the flag will include an S ( stale ).
tput HE2-lg disable
# this will tell the server to ignore HE2 , flags will contain D disabled
# you can also disable individual variables or RMs
# this can be useful to prevent the logs from filling with failed access attempts to hardware which is defined in setup but not actually
# currently installed


Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r3 - 18 Jun 2019 - SiqiYuan
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2023 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback