Engineer access to the system from LabWindows: Difference between revisions

From GammaSphere DAQ
Jump to navigation Jump to search
No edit summary
No edit summary
Line 34: Line 34:
Starting from Sonata again, enter ssh –Y dgs@dgs1 to connect to the DGS Linux box.  You will be prompted for a password, the “standard Gammasphere password” is required.  This is a full Linux machine, all the standard commands are available.  Various people store files here, I recommend leaving everything alone.  To access the “Carlware” interface to Digital Gammasphere, enter the command dgscommander.  A couple of EDM windows will pop up, the main one looks like this:
Starting from Sonata again, enter ssh –Y dgs@dgs1 to connect to the DGS Linux box.  You will be prompted for a password, the “standard Gammasphere password” is required.  This is a full Linux machine, all the standard commands are available.  Various people store files here, I recommend leaving everything alone.  To access the “Carlware” interface to Digital Gammasphere, enter the command dgscommander.  A couple of EDM windows will pop up, the main one looks like this:


[[File:Gammaware2.JPG]]


A similar technique connects you to DSSD/DFMA.  Once connected to Sonata, enter ssh –Y dgs@nat2 to connect to that system.  The same ‘standard Gammasphere password’ is used.  Once on machine dgs@darek, the command to start up that version of ‘Carlware’ is dfmacommander.  The main window there is essentially identical to that of DGS, save that the title will be FMA-ddaq Main Controller instead of DGS Main Controller.  However, some small other differences become visible when you start clicking things; the FMA-ddaq version has 5 Routers listed under the “trigger’ button but DGS only has 3.


A similar technique connects you to DSSD/DFMA.  Once connected to Sonata, enter ssh –Y dgs@nat2 to connect to that system.  The same ‘standard Gammasphere password’ is used.  Once on machine dgs@darek, the command to start up that version of ‘Carlware’ is dfmacommander.  The main window there is essentially identical to that of DGS, save that the title will be FMA-ddaq Main Controller instead of DGS Main Controller.  However, some small other differences become visible when you start clicking things; the FMA-ddaq version has 5 Routers listed under the “trigger’ button but DGS only has 3.
=== Using ‘Carlware’ ===
Using ‘Carlware’
‘Carlware’ is a fairly obvious GUI although it does have way too many subsidiary windows.  For example, if you want to check the state of the transmit enable register of Router 2 in the trigger system, you have to
‘Carlware’ is a fairly obvious GUI although it does have way too many subsidiary windows.  For example, if you want to check the state of the transmit enable register of Router 2 in the trigger system, you have to
Click the ‘trigger’ button and select router 2; this causes a window to pop up about that Router.
*Click the ‘trigger’ button and select router 2; this causes a window to pop up about that Router.
Click the ‘serdes’ button on that screen.  That pops up another window with SERDES info.
*Click the ‘serdes’ button on that screen.   
Click the ‘Link Controls’ button and select ‘Transmit Pwr’.  A third window pops up for just that register, with buttons for each bit.
**That pops up another window with SERDES info.
*Click the ‘Link Controls’ button and select ‘Transmit Pwr’.   
**A third window pops up for just that register, with buttons for each bit.


Thankfully, Mike Carpenter has made a couple of scripts that do much of the work for standard initialization.
Thankfully, Mike Carpenter has made a couple of scripts that do much of the work for standard initialization.
Specific ‘Carlware’ issues
Specific ‘Carlware’ issues
1. Many registers of the trigger, including all the diagnostic FIFOs, are not accessible from ‘Carlware’.
#Many registers of the trigger, including all the diagnostic FIFOs, are not accessible from ‘Carlware’.
2. There is no generic VME “peek/poke” method that allows access to registers not defined in the interface.
#There is no generic VME “peek/poke” method that allows access to registers not defined in the interface.
3. We’re still finding small bugs in the interface.
#We’re still finding small bugs in the interface.


Changes to ‘Carlware’ are still occurring at LBNL; they are currently on version 10.5 and the version in use at Gammasphere is based upon LBNL version 9.22.  Tim Madden and Mike Carpenter are making incremental changes, although at some point full divergence will become necessary.
Changes to ‘Carlware’ are still occurring at LBNL for the GRETINA system, but their versions and versions found here at DGS and DFMA have differences and continue to diverge.


A weird startup requirement of the system is that, when crates are power-cycled, one must wait until all of the digitizer crates have completely rebooted, and then manually reboot the trigger processor a second time or the system won’t runThis is apparently because the trigger crate’s processor hosts a number of ‘global’ EPICS process variables and these aren’t properly initialized unless that processor boots after everyone else.
For those not familiar with EPICS, recall that global process variables have to be hosted somewhere.  In the DGS and DFMA implementations of EPICS, this is done on a Soft IOC running on the Linux machineIf the Soft IOC isn't running, many features will not work.
VME Peek and Poke
 
==== VME Peek and Poke using 'Carlware' ====
It is possible to directly access registers within the VME modules by use of the console interface of each processor board (called an “IOC”, for Input/Output Controller).  Clicking on the ‘Terminals’ button gives access to the different terminals.  The ‘Soft IOC’ is a virtual IOC emulated in software; the others are all ‘real’ processors.  From the console port various commands are available; the only three of interest to most people are
It is possible to directly access registers within the VME modules by use of the console interface of each processor board (called an “IOC”, for Input/Output Controller).  Clicking on the ‘Terminals’ button gives access to the different terminals.  The ‘Soft IOC’ is a virtual IOC emulated in software; the others are all ‘real’ processors.  From the console port various commands are available; the only three of interest to most people are


‘d’, the command that displays memory locations,
*‘d’, the command that displays memory locations,
‘m’, the command that modifies memory locations, and
*‘m’, the command that modifies memory locations, and
‘reboot’, to soft-boot the processor.
*‘reboot’, to soft-boot the processor.


Since VME addresses are memory-mapped within the IOC processor, judicious use of the ‘d’ and ‘m’ commands provides a form of peek-and-poke access to registers within the module.  Examples of using them are shown below.
Since VME addresses are memory-mapped within the IOC processor, judicious use of the ‘d’ and ‘m’ commands provides a form of peek-and-poke access to registers within the module.  Examples of using them are shown below.
Peeking into registers
 
==== Peeking into registers ====
To ‘peek’ we use the ‘d’ command.  The proper format of ‘d’ is d <addr>,<nunits>,<wordwidth> where <addr> is the address,  in processor memory space, where you want to start the display.  <nunits> is the number of words to display and <wordwidth> is the size, in bytes, of each word.  By default, VxWorks sets the base address of the VME window to 0xe8000000.  Then you have to know which board in the system you want to talk to, because triggers and digitizers use geographic addressing, and then you need to know what register to play with.
To ‘peek’ we use the ‘d’ command.  The proper format of ‘d’ is d <addr>,<nunits>,<wordwidth> where <addr> is the address,  in processor memory space, where you want to start the display.  <nunits> is the number of words to display and <wordwidth> is the size, in bytes, of each word.  By default, VxWorks sets the base address of the VME window to 0xe8000000.  Then you have to know which board in the system you want to talk to, because triggers and digitizers use geographic addressing, and then you need to know what register to play with.



Revision as of 18:49, July 23, 2013

Tunneling to Digital Gammasphere – crib notes

This document will summarize how to remotely access the 'engineering PC' in the data room at Gammasphere to allow diagnosis of issues from remote machines. This PC runs Windows and has on it a program called 'GammaWare'. GammaWare is a LabWindows (copyright of National Instruments, see http://www.ni.com/lwcvi/) program that provides low-level register/bit access.

General Notes

  1. The subnet for all machines in the data room of Gammasphere is “onenet”. To get to “onenet” you must have an X windows package running on your Windows machine and then connect to sonata.phy.anl.gov.
  2. For the X windows package, I’m currently using Cygwin. Cygwin is huge but it works. You can use Putty plus some other X windows package if you like.

Connecting to Sonata

  1. Once you’ve got an X windows package running on your machine, the Unix/Linux command to connect is ssh –Y sonata.phy.anl.gov. You have to use the –Y to pass graphics.
  2. When I connect with Cygwin it passes my login name from the PC to sonata.
    1. You may get a couple of notes/errors/warnings about not being able to create /home/xxx/.ssh. Big deal, who cares, ignore.
    2. You may also get an error about not being able to establish the authenticity of sonata.phy.anl.gov, so answer ‘yes’ to continue anyway.
  3. You should then see the ANL/DOE splash about security and then must enter your ANL domain password.
  4. Another warning about ‘No xauth data; using fake authentication data for X11 forwarding’ may occur that is also safe to ignore.
  5. After those warnings and nags you should have a Linux prompt. There are no files to find and what few directories are present you don’t have permission to explore. All you can do from here is SSH to somewhere else. There are three places of interest to go:
    1. The PC at Gammasphere
    2. The DGS linux machine
    3. The DSSD linux machine

Accessing the Windows PC at Gammasphere

Assuming you have connected to sonata, to get to the PC at Gammasphere do the following:

  1. Enter the command rdesktop wdgs –g 1280x1024. This will pop up a Windows login screen. The machine’s name is wdgs; the –g 1280x1024 sets the aspect ratio and size of the viewing area.
  2. Enter the user name topoadmin. This used to be the topological trigger test stand machine, so we kept the username.
  3. The password is the “standard Gammasphere password” used on all the onenet machines. All you leftover hippies from the 60s will remember it easily.
  4. Once you’ve connected to the PC, you may then run the LabWindows program to access Digital Gammasphere’s trigger system. For example, here’s a screenshot.

Gammaware1.JPG

This is a standard PC of limited power loaded with LabWindows, CSDiff (file comparison), ConText, IE, Acrobat and OpenOffice. The intent is that it is used for running the LabWindows program.

To terminate the connection, simply click the red ‘x’ to close.

Connecting to Digital Gammasphere and DGS

Starting from Sonata again, enter ssh –Y dgs@dgs1 to connect to the DGS Linux box. You will be prompted for a password, the “standard Gammasphere password” is required. This is a full Linux machine, all the standard commands are available. Various people store files here, I recommend leaving everything alone. To access the “Carlware” interface to Digital Gammasphere, enter the command dgscommander. A couple of EDM windows will pop up, the main one looks like this:

Gammaware2.JPG

A similar technique connects you to DSSD/DFMA. Once connected to Sonata, enter ssh –Y dgs@nat2 to connect to that system. The same ‘standard Gammasphere password’ is used. Once on machine dgs@darek, the command to start up that version of ‘Carlware’ is dfmacommander. The main window there is essentially identical to that of DGS, save that the title will be FMA-ddaq Main Controller instead of DGS Main Controller. However, some small other differences become visible when you start clicking things; the FMA-ddaq version has 5 Routers listed under the “trigger’ button but DGS only has 3.

Using ‘Carlware’

‘Carlware’ is a fairly obvious GUI although it does have way too many subsidiary windows. For example, if you want to check the state of the transmit enable register of Router 2 in the trigger system, you have to

  • Click the ‘trigger’ button and select router 2; this causes a window to pop up about that Router.
  • Click the ‘serdes’ button on that screen.
    • That pops up another window with SERDES info.
  • Click the ‘Link Controls’ button and select ‘Transmit Pwr’.
    • A third window pops up for just that register, with buttons for each bit.

Thankfully, Mike Carpenter has made a couple of scripts that do much of the work for standard initialization.

Specific ‘Carlware’ issues

  1. Many registers of the trigger, including all the diagnostic FIFOs, are not accessible from ‘Carlware’.
  2. There is no generic VME “peek/poke” method that allows access to registers not defined in the interface.
  3. We’re still finding small bugs in the interface.

Changes to ‘Carlware’ are still occurring at LBNL for the GRETINA system, but their versions and versions found here at DGS and DFMA have differences and continue to diverge.

For those not familiar with EPICS, recall that global process variables have to be hosted somewhere. In the DGS and DFMA implementations of EPICS, this is done on a Soft IOC running on the Linux machine. If the Soft IOC isn't running, many features will not work.

VME Peek and Poke using 'Carlware'

It is possible to directly access registers within the VME modules by use of the console interface of each processor board (called an “IOC”, for Input/Output Controller). Clicking on the ‘Terminals’ button gives access to the different terminals. The ‘Soft IOC’ is a virtual IOC emulated in software; the others are all ‘real’ processors. From the console port various commands are available; the only three of interest to most people are

  • ‘d’, the command that displays memory locations,
  • ‘m’, the command that modifies memory locations, and
  • ‘reboot’, to soft-boot the processor.

Since VME addresses are memory-mapped within the IOC processor, judicious use of the ‘d’ and ‘m’ commands provides a form of peek-and-poke access to registers within the module. Examples of using them are shown below.

Peeking into registers

To ‘peek’ we use the ‘d’ command. The proper format of ‘d’ is d <addr>,<nunits>,<wordwidth> where <addr> is the address, in processor memory space, where you want to start the display. <nunits> is the number of words to display and <wordwidth> is the size, in bytes, of each word. By default, VxWorks sets the base address of the VME window to 0xe8000000. Then you have to know which board in the system you want to talk to, because triggers and digitizers use geographic addressing, and then you need to know what register to play with.

Generally, the DGS and DSSD systems are set up so that the IOC is in slot 0 (leftmost) and the boards are located in slots 2,3,4,5. The DSSD trigger crate, though, is completely stuffed with the IOC in slot 0 and triggers in slots 1,2,3,4,5 and 6. By convention, the Master is the left-most trigger, but that is not a requirement. The slot number is the third hex digit in the address. So, a correctly formed read of the read-only registers of the Router in slot 2 of the DSSD crate would be d 0xe8200100,64,4 as the 0xe820 means ‘slot 2’, the following 0100 means ‘starting at address 0x100 within slot 2’, the 64 means read 64 registers and the 4 means the registers are accessed as 4-byte (32 bit) elements. The result of this (in the DSSD system) is


And a quick sanity check shows that register 0x0158 (CODE_DATE) is the expected 0x0410 (last code revision is dated April 10th) and that register 0x015C (CODE_REVISION) is the expected 0x21FF (board pcb revision 2, board type 1 (router), code revision FF (experimental)). This read also shows that the SERDES links A-H have had 1 or 2 lock losses by the values in 0x01B0 – 0x01CC. A similar read of the Router in slot 5 shows that two of the digitizers are misbehaving as shown by the large counts in 0x01C4 and 0x01C8.


Conversely, writing to a register is also possible. While not generally recommended for anyone except a complete expert, the technique is to use the ‘m’ command. The form is m <address>,<width> and it allows you to go through multiple locations. ‘m’ displays the current value and assumes you are entering a new value. Simply hitting ‘enter’ skips to the next location leaving the current one unchanged. You have to type a ‘q’ and hit ‘enter’ to exit the ‘m’ mode. It is critical to use the <width> parameter correctly or garbage gets written into the module. For DGS/DSSD modules, <width> must be set to 4.