Skip to content

Troubleshooting

On this page, you'll find quick fixes for the most common problems you may encounter.

Your feedback matters!

Ran into an issue that's not listed here? Let us know!

"Error using mr.makeArbitraryGrad"

This error will be raised in Matlab while trying to compile a sequence if you are defining gradients that are not compatible with the selected system specifications. There are two variants that can appear: "Slew rate violation" or "Requested area is too large for this gradient". In both cases, either reduce the gradient moment (for example, fewer twists for a spoiler) or increase the gradient duration.

Stimulation limit exceeded

This may be one of the most common issues you'll run into. Even if you double-checked all parameters, the sequence compiled without errors, and the PNS simulation predicted moderate values, your scanner might not execute your sequence (or abort halfway through) and display a warning that the stimulation limit was exceeded. Luckily for you, in most cases this is also an easy fix. You'll need to reduce the slew rate. The first step would be to analyze the PNS simulation figure in detail. By comparing the peaks to the sequence diagram, you should be able to identify which events cause the highest PNS. For the specific module, you can then reduce the slew rate. Per default, most modules already reduce the system's nominal slew rate maximum by a factor of sqrt(3).

PNS calculation

You will only be able to create the estimated PNS diagram for your sequence if you have access to the .asc file for your scanner. If not, you'll have to find the problematic gradient by trial and error.

If you're unsure how to reduce the gradient or slew rate limits for a specific event, just open the corresponding ..._init function. In there, you will find a passage that defines the default value. Here's an example for the T2 preparation crushers:

T2_init.m
function T2 = T2_init(T2, FOV, system)
[...]
    if ~isfield(T2, 'crush_lim_grad')
        T2.crush_lim_grad = 1/sqrt(3); % reduce crusher gradient amplitude from nominal limit
    end    
    if ~isfield(T2, 'crush_lim_slew')
        T2.crush_lim_slew = 1/sqrt(3); % reduce crusher gradient slew rate from nominal limit to avoid stimulation
    end
[...]

Here's an example showing how to initialize the T2 preparation using the default limits versus using explicitly reduced slew rate:

T2.exc_mode   = 'adiabatic_BIR4';
T2.rfc_dur    = 2 *1e-3;   % [s]  duration of composite refocusing pulses
T2.bir4_tau   = 10 *1e-3;  % [s]  bir4 pulse duration
T2.bir4_f1    = 640;       % [Hz] maximum rf peak amplitude
T2.bir4_beta  = 10;        % [ ]  am waveform parameter
T2.bir4_kappa = atan(10);  % [ ]  fm waveform parameter
T2.bir4_dw0   = 30000;     % [rad/s] fm waveform scaling
T2.prep_times = [40 80] * 1e-3;  % [s] inversion times
T2            = T2_init(T2, FOV, system);
T2.exc_mode   = 'adiabatic_BIR4';
T2.rfc_dur    = 2 *1e-3;   % [s]  duration of composite refocusing pulses
T2.bir4_tau   = 10 *1e-3;  % [s]  bir4 pulse duration
T2.bir4_f1    = 640;       % [Hz] maximum rf peak amplitude
T2.bir4_beta  = 10;        % [ ]  am waveform parameter
T2.bir4_kappa = atan(10);  % [ ]  fm waveform parameter
T2.bir4_dw0   = 30000;     % [rad/s] fm waveform scaling
T2.prep_times = [40 80] * 1e-3;  % [s] inversion times
T2.crush_lim_slew = 0.5;
T2            = T2_init(T2, FOV, system);

Trajectory measurement aborted

There seems to be an issue when trying to acquire very large scans - we've only ever encountered this problem with trajectory measurements on Siemens scanners (especially when using more than a hundred unique trajectory orientations). This might have to do with memory limitations, but we didn't yet do an in depth analysis to find the exact limits and causes. What will happen is that the measurement will start but eventually abort without an obvious reason. There is a quick-and-dirty fix: just split the trajectory measurement up in multiple parts. The separate parts will later be recombined automatically. Below is an example.

Acquisition: pulseq_traj_meas.m

Assume your MRF acquisition features 299 unique trajectory orientations (TRAJ.NR=299).

Per default, the variable loop_NR runs from 1 through TRAJ.NR (line 78).

[...]
if strcmp(TRAJ.method, 'robison')
    for loop_xy = [1 5]
        ndummy = TRAJ.Ndummy;
        for loop_NR = 1 : TRAJ.NR            
            loop_traj = loop_xy;
            for loop_av = 1 - ndummy : TRAJ.Nav
                loop_traj = loop_xy;
                TRAJ_add();
                loop_traj = loop_xy + 2;
                TRAJ_add();
                loop_traj = loop_xy + 1;
                TRAJ_add();
                loop_traj = loop_xy + 3;
                TRAJ_add();
            end           
            ndummy = 0;
        end
    end
end
[...]

Instead, the measurement can be split up. In the following example, line 78 is modified so that the resulting sequence only measures the first 100 unique trajectory orientations.

[...]
if strcmp(TRAJ.method, 'robison')
    for loop_xy = [1 5]
        ndummy = TRAJ.Ndummy;
        for loop_NR = 1 : 100            
            loop_traj = loop_xy;
            for loop_av = 1 - ndummy : TRAJ.Nav
                loop_traj = loop_xy;
                TRAJ_add();
                loop_traj = loop_xy + 2;
                TRAJ_add();
                loop_traj = loop_xy + 1;
                TRAJ_add();
                loop_traj = loop_xy + 3;
                TRAJ_add();
            end           
            ndummy = 0;
        end
    end
end
[...]
To measure the trajectory in all orientations in this example with TRAJ.NR=299, you would then have to compile two more sequences, replacing line 78 with for loop_NR = 101 : 200 and for loop_NR = 201 : TRAJ.NR, respectively.

Use in MRF reconstruction

The recombination of a split up trajectory measurement is straightforward. In reco_mrf.m, just replace the variable study_name_traj (usually a string) by a cell array of strings, containing the names of the separate parts of the trajectory calibration acquisition.