AUSTRALIAN NATIONAL UNIVERSITY

 

System Design Note 11.10

 

Created: 6 September 2001

Last modified: 6 September 2001

 

---

 

TESTING NIFS SOFTWARE USE OF THE OREGON VME8 INTELLIGENT MOTOR CONTROLLER

 

Mark Jarnyk

 

Research School of Astronomy and Astrophysics

Institute of Advanced Studies

Australian National University

 

Revision History

 

Revision No.

Author &

Date

Approval &

Date

Description

Revision 1

Mark Jarnyk

15 August 2001

Peter Young

20 August 2001

Original document.

 

 

 

 

 

 

Contents

 

1 Purpose. 1

2 Applicable Documents. 2

3 Introduction. 2

3.1 Modify The Database. 2

3.2 Modify drvSimConf 2

3.3 Set Card Jumpers. 3

3.4 Measuring Output 4

3.5 Running the Software. 4

Appendix A: List of Figures. 5

 

 

1 Purpose

 

This document describes how the Gemini Near-infrared Integral Field Spectrograph (NIFS) software controlling the Oregon VME8 Intelligent Motor Controller cards was tested. In particular it shows how to modify the software to test the card. As such, it acts as a template for testing other hardware with the components controller software.

 

2 Applicable Documents

 

Document ID

Source

Title

 

Oregon Micro Systems

User’s Manual – Intelligent Motor Controllers – VME8 Family

 

RSAA

NIFS Critical Design Review Documentation Vol 1

 

 

 

 

 

3 Introduction

 

The Gemini Near-infrared Integral Field Spectrograph (NIFS) uses two Oregon Motor Controllers to control the five stepper motors for the components of the components controller, the three stepper motors for the OIWFS, and the two cryo-cooler motors. This document describes the steps that should be taken to test the software used to control the motor controllers for the cryo-coolers.

 

3.1 Modify The Database

 

Change to the NIFS directory and type

source nifsLogin

Open the schematic, tmpSim.sch, in Capfast. Select the one symbol on the page, and select properties->edit. Change the tmot label to “OMS VME8, VME44”. This tells the software to use devHoms device support and the drvHoms driver.

 

Note the values of the two labels, tm1 and tm2. These will be used to calculate the address of the motor to be controlled. They should look like #C0 S7 and #C1 S7. This will be interpreted by the device handler as signal 7 (in the range 0-7) of card 0 and signal 7 of card 1. Do not worry about the interpretation of this just now, I’ll describe it fully later.

 

3.2 Modify drvSimConf

 

Edit the file ENG/bin/mv2700/drvSimConf, adding the line

homsSetup(2,8, 0xFC80, 0, 5, 6)

at the bottom of the file. The startup file bin/mv2700/startupSim executes

< ENG/bin/mv2700/drvSimConf

and now this will initialize the driver. The function’s arguments are:

 

 

The source of homsSetup is found in drvHoms.c and the interested reader can find more information on how these arguments are used there  (Be aware that if you modify the source file ENG/startup/drvSimConf.VWS and do a make, then this file will be evaluated and copied over the top of ENG/bin/mv2700/drvSimConf.).

 

3.3 Set Card Jumpers

 

On the Oregon boards there are four sets of jumpers to be set J25, J27, J15 and J26. To set the address of the first card to 0xFC80 set the jumpers as in Figure 1.

Figure 1: Address settings for the first controller.

 

A jumper sets the value to 0 and the last four bits, A3..A0 are zero, so the address shown in Figure 1 reads as FC80. The device handler expects successive Oregon controller cards to have their address offset from the base address by 0x10, so the second card requires the address 0xFC90. This is set with the jumpers as shown in Figure 2.

 

The addresses that were set up in the database, #C0 S7 and #C1 S7 are used to calculate the address of the card, based on the base address passed to homsSetup as part of drvSimConf. The number after the C – call it N - determines the address as follows:

                addr = base_address + N * 0x10

So #C0 says we are using 0xFC80 and #C1 says we are using 0xFC90.

Figure 2: Address settings for the second controller.

 

We are using IRQ5. This is set on the cards by jumpers J15 and J26 as shown in Figure 3. Refer to the Oregon controller manual for more detail about setting the jumpers.

 

Figure 3: IRQ jumper settings for both cards.

 

3.4 Measuring Output

 

We have configured the cryo-cooler motor to use signal 7, which is the S output on the P2 connector. The S step output floats and is taken to ground on a pulse, therefore, it is necessary to pull this output high. Connect a 1k resistor between a +5V supply and pin 29 of row C on the connector. Use the oscilloscope to measure the signal between pin 29 of row C and pin 31 (ground) of row A. Refer to Table 4-1 of the Oregon controller manual for other signals.

 

3.5 Running the Software

 

Change to the NIFS directory and type gmake. When this is done, reboot the IOC and type

<startupSim

on the IOC. When this has finished loading, type in

hsLockTmp=1.

 

On the workstation type:

./nifsStart

Now you can use the engineering screens to control the coolers. Go to the nifs->low-level-engineering->temperature screen and set the cooler to Low or High. You should see pulses on the oscilloscope. If you do not then it is time to debug. Set the debug levels for the device handler, driver and record by typing:

devHOMSdebug=255

drvHOMSdebug=255

recHmotordebug=255

on the IOC. Experiment with different levels to exclude different messages. Setting them to zero turns off debugging. (Make sure that the files, recHmotor.c, devHOMS.c and drvHOMS.c are compiled with the #undef NODEBUG macro.)

 

Appendix A: List of Figures

 

Figure 1

figure.gif

Figure 2

 

Figure 3