<?xml version="1.0" encoding="utf-8"?><!DOCTYPE article  PUBLIC '-//OASIS//DTD DocBook XML V4.4//EN'  'http://www.docbook.org/xml/4.4/docbookx.dtd'><article><articleinfo><title>MrDevelopers</title><revhistory><revision><revnumber>16</revnumber><date>2013-03-07 21:22:56</date><authorinitials>localhost</authorinitials><revremark>converted to 1.6 markup</revremark></revision><revision><revnumber>15</revnumber><date>2010-03-01 15:53:33</date><authorinitials>StefanHetzer</authorinitials></revision><revision><revnumber>14</revnumber><date>2009-11-11 15:09:42</date><authorinitials>RhodriCusack</authorinitials></revision><revision><revnumber>13</revnumber><date>2009-11-11 15:09:04</date><authorinitials>RhodriCusack</authorinitials></revision><revision><revnumber>12</revnumber><date>2009-11-11 15:06:27</date><authorinitials>RhodriCusack</authorinitials></revision><revision><revnumber>11</revnumber><date>2009-11-11 15:05:21</date><authorinitials>RhodriCusack</authorinitials></revision><revision><revnumber>10</revnumber><date>2009-11-11 15:05:02</date><authorinitials>RhodriCusack</authorinitials></revision><revision><revnumber>9</revnumber><date>2009-11-11 15:04:49</date><authorinitials>RhodriCusack</authorinitials></revision><revision><revnumber>8</revnumber><date>2009-11-11 15:04:38</date><authorinitials>RhodriCusack</authorinitials></revision><revision><revnumber>7</revnumber><date>2009-11-11 15:02:47</date><authorinitials>RhodriCusack</authorinitials></revision><revision><revnumber>6</revnumber><date>2009-11-11 15:00:24</date><authorinitials>RhodriCusack</authorinitials></revision><revision><revnumber>5</revnumber><date>2009-11-11 15:00:04</date><authorinitials>RhodriCusack</authorinitials></revision><revision><revnumber>4</revnumber><date>2009-11-11 14:59:45</date><authorinitials>RhodriCusack</authorinitials></revision><revision><revnumber>3</revnumber><date>2009-11-11 14:58:49</date><authorinitials>RhodriCusack</authorinitials></revision><revision><revnumber>2</revnumber><date>2009-11-11 14:58:30</date><authorinitials>RhodriCusack</authorinitials></revision><revision><revnumber>1</revnumber><date>2009-11-11 14:58:13</date><authorinitials>RhodriCusack</authorinitials></revision></revhistory></articleinfo><section><title>Developing New MR Sequences: Good Practice Guide</title><para>If you are developing IDEA or ICE sequences for the scanner at the CBU, please follow this practice.  </para><section><title>Virus prevention</title><para>Viruses have been common on other machines in the scanner room, and we must take precautions to stop these ever being transferred to the scanner.  </para><itemizedlist><listitem><para>Only use the two USB memory sticks labelled &quot;Scanner only&quot; for transferring sequences to the scanner. </para></listitem><listitem><para>Only put these USB sticks into CBU maintained computers that are running Anti-Virus software (NOT the stimulus delivery machines, which do not run antivirus and are often infected). </para></listitem></itemizedlist></section><section><title>Scanner settings</title><itemizedlist><listitem><para>Don't change any settings on the scanner (e.g., using the ideacmdtool) that will disrupt regular scanning in any way. </para></listitem><listitem><para>If you're not sure, ask </para></listitem></itemizedlist></section><section><title>Acoustic resonances</title><para>Sequences that oscillate the gradients at particular frequencies can set up resonances that can damage the system. Please get in contact with <ulink url="https://imaging.mrc-cbu.cam.ac.uk/imaging/MrDevelopers/imaging/StefanHetzer#">StefanHetzer</ulink> for checking all new sequences before using them on the Tim Trio. A special tool will be used to analyse the acoustic spectrum of the pulse sequence based on information created during a sequence simulation under the Siemens sequence developer environment IDEA. </para></section><section><title>Sequence version control</title><itemizedlist><listitem><para>Try not to overwrite any sequence that some other developer is using. </para></listitem><listitem><para>Don't change any sequence that is already in use (even in a way that improves it) without being absolutely sure none of the users will have a problem. I would suggest only allowing users to use &quot;releases&quot; of software, and not deleting earlier releases as new ones come along. A suggested naming convention is EPI_ISSS_r01, EPI_ISSS_r02 and so on </para></listitem><listitem><para>Keep users of your sequence, and the wiki record, updated so that everyone is aware of the strengths/pitfalls/versions of your sequences as you discover them. </para></listitem><listitem><para>Keep the radiographers aware of new sequences and releases </para></listitem></itemizedlist></section><section><title>Software upgrades</title><itemizedlist><listitem><para>In advance of any scanner software upgrade, work out whether it will break your sequence (probably!) and then alert your users that the sequence will stop working on this date. </para></listitem><listitem><para>Try to make upgrades available when practical. </para></listitem></itemizedlist></section><section><title>Working in the facility - local rules</title><itemizedlist><listitem><para>Don't ever go in the magnet room unless there is a radiographer or scanning buddy (who must have done the safety course) also in the facility. </para></listitem><listitem><para>Don't ever put a human volunteer in the scanner without a radiographer present </para></listitem><listitem><para>Read the SOPs </para></listitem></itemizedlist></section></section></article>