Introduction

HostMot2 is an FPGA configuration developed by Mesa Electronics for their line of Anything I/Omotion control cards. The firmware is open source, portable and flexible. It can be configured (at compile-time) with zero or more instances (an object created at runtime) of each of several Modules: encoders (quadrature counters), PWM generators, and step/dir generators. The firmware can be configured (at run-time) to connect each of these instances to pins on the I/O headers. I/O pins not driven by a Module instance revert to general-purpose bi-directional digital I/O.

Firmware Binaries

Several pre-compiled HostMot2 firmware binaries are available for the different Anything I/O boards. (This list is incomplete, check the hostmot2-firmware distribution for up-to-date firmware lists.)

5i20, 5i23, 4i65, 4i68 (72 I/O pins): using hm2\_pci module

  • 12-channel servo

  • 8-channel servo plus 4 step/dir generators

  • 4-channel servo plus 8 step/dir generators

5i22 (96 I/O pins): using hm2\_pci module

  • 16-channel servo

  • 8-channel servo plus 24 step/dir generators

3x20 (144 I/O pins): using hm2\_pci module

  • 24-channel servo

  • 16-channel servo plus 24 step/dir generators

7i43 (48 I/O pins): using hm2\_7i43 module

  • 8-channel servo (8 PWM generators & 8 encoders)

  • 4-channel servo plus 4 step/dir generators

Installing Firmware

Depending on how you installed EMC2 you may have to open the Synaptic Package Manager from the System menu and install the package for your Mesa card. The quickest way to find them is to do a search for hostmot2in the Synaptic Package Manager. Mark the firmware for installation then apply.

Loading HostMot2

The EMC support for the HostMot2 firmware is split into a generic driver called hostmot2and two low-level I/O drivers for the Anything I/O boards. The low-level I/O drivers are hm2\_7i43and hm2\_pci(for all the PCI- and PC-104/Plus-based AnyIO boards). The hostmot2 driver must be loaded first, using a HAL command like this:

loadrt hostmot2

See the hostmot2(9) man page for details.

The hostmot2 driver by itself does nothing, it needs access to actual boards running the HostMot2 firmware. The low-level I/O drivers provide this access. The low-level I/O drivers are loaded with commands like this:

loadrt hm2\_pci config=firmware=hm2/5i20/SVST8\_4.BIT
num\_encoders=3 num\_pwmgens=3 num\_stepgens=1

The config parameters are described in the hostmot2 man page.

Watchdog

The HostMot2 firmware may include a watchdog Module; if it does, the hostmot2 driver will use it.

The watchdog must be petted by EMC2 periodically or it will bite.

When the watchdog bites, all the board’s I/O pins are disconnected from their Module instances and become high-impedance inputs (pulled high), and all communication with the board stops. The state of the HostMot2 firwmare modules is not disturbed (except for the configuration of the IO Pins). Encoder instances keep counting quadrature pulses, and pwm- and step-generators keep generating signals (which are not relayed to the motors, because the IO Pins have become inputs).

Resetting the watchdog resumes communication and resets the I/O pins to the configuration chosen at load-time.

If the firmware includes a watchdog, the following HAL objects will be exported:

Pins:

[{.has\_bit:}] (bit i/o) True if the watchdog has bit, False if the
watchdog has not bit. If the watchdog has bit and the has\_bit bit
is True, the user can reset it to False to resume operation.

Parameters:

[{.timeout\_ns:}] (u32 read/write) Watchdog timeout, in
nanoseconds. This is initialized to 1,000,000,000 (1 second) at
module load time. If more than this amount of time passes between
calls to the pet\_watchdog() function, the watchdog will bite.

Functions:

[{pet\_watchdog():}] Calling this function resets the watchdog
timer and postpones the watchdog biting until timeout\_ns
nanoseconds later. This function should be added to the servo
thread.

HostMot2 Functions

[{hm2\_<BoardType>.<BoardNum>.read}] Read all inputs, update input
HAL pins.
[{hm2\_<BoardType>.<BoardNum>.write}] Write all outputs.
[{hm2\_<BoardType>.<BoardNum>.pet-watchdog}] Pet the watchdog to
keep it from biting us for a while.
[{hm2\_<BoardType>.<BoardNum>.read\_gpio}] Read the GPIO input
pins. (This function is not available on the 7i43 due to
limitations of the EPP bus.)
[{hm2\_<BoardType>.<BoardNum>.write\_gpio}] Write the GPIO control
registers and output pins. (This function is not available on the
7i43 due to limitations of the EPP bus.)

Pinouts

The hostmot2 driver does not have a particular pinout. The pinout comes from the firmware that the hostmot2 driver sends to the AnyIO board. Each firmware has different pinout, and the pinout depends on how many of the available encoders, pwmgens, and stepgens are used. To get a pinout list for your configuration after loading EMC2 in the terminal window type:

dmesg > hm2.txt

The resulting text file will contain lots of information as well as the pinout for the HostMot2 and any error and warning messages.

To reduce the clutter by clearing the message buffer before loading EMC type the following in the terminal window:

sudo dmesg -c

Now when you run EMC and then do a dmesg > hm2.txtin the terminal only the info from the time you loaded EMC will be in your file along with your pinout. The file will be in the current directory of the terminal window. Each line will contain the card name, the card number, the I/O Pin number, the connector and pin, and the usage. From this printout you will know the physical connections to your card based on your configuration.

An example of a 5i20 configuration:

{[}HOSTMOT2{]}
DRIVER=hm2\_pci
BOARD=5i20
CONFIG=firmware=hm2/5i20/SVST8\_4.BIT num\_encoders=1
num\_pwmgens=1 num\_stepgens=3The above configuration produced
this printout .
{{[} 1141.053386{]} hm2/hm2\_5i20.0: 72 I/O Pins used:}
{{[} 1141.053394{]} hm2/hm2\_5i20.0: IO Pin 000 (P2-01): IOPort}
{{[} 1141.053397{]} hm2/hm2\_5i20.0: IO Pin 001 (P2-03): IOPort}
{{[} 1141.053401{]} hm2/hm2\_5i20.0: IO Pin 002 (P2-05): Encoder
#0, pin B (Input)}
{{[} 1141.053405{]} hm2/hm2\_5i20.0: IO Pin 003 (P2-07): Encoder
#0, pin A (Input)}
{{[} 1141.053408{]} hm2/hm2\_5i20.0: IO Pin 004 (P2-09): IOPort}
{{[} 1141.053411{]} hm2/hm2\_5i20.0: IO Pin 005 (P2-11): Encoder
#0, pin Index (Input)}
{{[} 1141.053415{]} hm2/hm2\_5i20.0: IO Pin 006 (P2-13): IOPort}
{{[} 1141.053418{]} hm2/hm2\_5i20.0: IO Pin 007 (P2-15): PWMGen #0,
pin Out0 (PWM or Up) (Output)}
{{[} 1141.053422{]} hm2/hm2\_5i20.0: IO Pin 008 (P2-17): IOPort}
{{[} 1141.053425{]} hm2/hm2\_5i20.0: IO Pin 009 (P2-19): PWMGen #0,
pin Out1 (Dir or Down) (Output)}
{{[} 1141.053429{]} hm2/hm2\_5i20.0: IO Pin 010 (P2-21): IOPort}
{{[} 1141.053432{]} hm2/hm2\_5i20.0: IO Pin 011 (P2-23): PWMGen #0,
pin Not-Enable (Output)}
{<snip>...}
{{[} 1141.053589{]} hm2/hm2\_5i20.0: IO Pin 060 (P4-25): StepGen
#2, pin Step (Output)}
{{[} 1141.053593{]} hm2/hm2\_5i20.0: IO Pin 061 (P4-27): StepGen
#2, pin Direction (Output)}
{{[} 1141.053597{]} hm2/hm2\_5i20.0: IO Pin 062 (P4-29): StepGen
#2, pin (unused) (Output)}
{{[} 1141.053601{]} hm2/hm2\_5i20.0: IO Pin 063 (P4-31): StepGen
#2, pin (unused) (Output)}
{{[} 1141.053605{]} hm2/hm2\_5i20.0: IO Pin 064 (P4-33): StepGen
#2, pin (unused) (Output)}
{{[} 1141.053609{]} hm2/hm2\_5i20.0: IO Pin 065 (P4-35): StepGen
#2, pin (unused) (Output)}
{{[} 1141.053613{]} hm2/hm2\_5i20.0: IO Pin 066 (P4-37): IOPort}
{{[} 1141.053616{]} hm2/hm2\_5i20.0: IO Pin 067 (P4-39): IOPort}
{{[} 1141.053619{]} hm2/hm2\_5i20.0: IO Pin 068 (P4-41): IOPort}
{{[} 1141.053621{]} hm2/hm2\_5i20.0: IO Pin 069 (P4-43): IOPort}
{{[} 1141.053624{]} hm2/hm2\_5i20.0: IO Pin 070 (P4-45): IOPort}
{{[} 1141.053627{]} hm2/hm2\_5i20.0: IO Pin 071 (P4-47): IOPort}
{{[} 1141.053811{]} hm2/hm2\_5i20.0: registered}
{{[} 1141.053815{]} hm2\_5i20.0: initialized AnyIO board at
0000:02:02.0}

Note that the IO Pin nnn will correspond to the pin number shown on the HAL Configuration screen for GPIO’s. Some of the Stepgen, Encoder and PWMGen will also show up as GPIO’s in the HAL Configuration screen.

PIN Files

The default pinout is described in a .PIN file. When you install a firmware package .deb, the .PIN file is installed in

/usr/share/doc/hostmot2-firmware-mesa-<board>-hostmot2

Firmware

If you are using Run In Place, you must still install a hostmot2-firmware package.


[The emc2-firmware packages from emc 2.3.x are also compatible with this version of emc2. ]

HAL Pins

The HAL pins for each configuration can be seen by opening up Show HAL Configurationfrom the Machine menu. All the HAL pins and parameters can be found there. The following figure is of the 5i20 configuration used above.

images/5i20-halpins.png

Configurations

5i20 & 5i23 Default Configurations
Firmware & 5i20 & 5i23 & Encoder & PWM & StepGen & GPIOSV12 & X & X
& 12 & 12 & 0 & 0SVST2\_8 & X & & 2 & 2 & 8 & 12SVST2\_4\_7I47 & X
& X & 4 & 2 & 4 & 48SVST4\_8 & & X & 4 & 4 & 8 & 0SVST8\_4 & X & X
& 8 & 8 & 4 & 0SVST8\_4IM2 & X & X & 8 & 8 & 4 & 8SVST8\_8IM2 & & X
& 8 & 8 & 8 & 0
4i65 & 4i68 Default Configurations
Firmware & 4i65 & 4i68 & Encoder & PWM & StepGen & GPIOSV12 & X & X
& 12 & 12 & 0 & 0SVST4\_8 & & X & 4 & 4 & 8 & 0SVST8\_4 & X & X & 8
& 8 & 4 & 0SVST8\_4IM2 & X & X & 8 & 8 & 4 & 8SVST8\_8IM2 & & X & 8
& 8 & 8 & 0
7i43 Default Configurations
Firmware & 200K & 400K & Encoder & PWM & StepGen & GPIOSV8B & & X &
8 & 8 & 0 & 0SV8S & X & & 8 & 8 & 0 & 0SVST2\_4\_7I47 & X & X & 4 &
2 & 4 & SVST4\_4B & & X & 4 & 4 & 4 & 0SVST4\_4S & X & & 4 & 4 & 4
& 0SVST4\_6B & & X & 4 & 4 & 6 & 0SVST4\_6S & X & & 4 & 4 & 6 &
0SVST4\_12B & & X & 4 & 4 & 12 & 0
The 7i43 comes in 200K and 400K gate versions.

Even though several cards may have the same .BIT file you can not use a .BIT file that is not for that card. Different cards have different clock frequencies so make sure you load the proper .BIT file for your card. Custom hm2 firmwares can be created for special applications and you may see some custom hm2 firmwares in the directories with the default ones.

When you load the board-driver (hm2\_pci or hm2\_7i43), you can tell it to disable instances of the three primary modules (pwmgen, stepgen, and encoder) by setting the count lower. Any I/O pins belonging to disabled module instances become gpios.

GPIO

General Purpose I/O pins on the board which are not used by a module instance are exported to HAL as fullGPIO pins. Full GPIO pins can be configured at run-time to be inputs, outputs, or open drains, and have a HAL interface that exposes this flexibility. IO pins that are owned by an active module instance are constrained by the requirements of the owning module, and have a restricted HAL interface.

GPIOs have names like hm2\_<BoardType>.<BoardNum>.gpio.<IONum>.IONum. is a three-digit number. The mapping from IONum to connector and pin-on-that-connector is written to the syslog when the driver loads, and it’s documented in Mesa’s manual for the Anything I/O boards.

The hm2 GPIO representation is modeled after the Digital Inputs and Digital Outputs described in the Canonical Device Interface (part of the HAL General Reference document).

GPIO pins default to input.

Pins

[{.in}] (Bit, Out) Normal state of the hardware input pin. Both
full GPIO pins and IO pins used as inputs by active module
instances have this pin.
[{.in\_not}] (Bit, Out) Inverted state of the hardware input pin.
Both full GPIO pins and IO pins used as inputs by active module
instances have this pin.
[{.out}] (Bit, In) Value to be written (possibly inverted) to the
hardware output pin. Only full GPIO pins have this pin.

Parameters

[{.invert\_output}] (Bit, RW) This parameter only has an effect if
the is\_outputparameter is true. If this parameter is true, the
output value of the GPIO will be the inverse of the value on the
outHAL pin. Only full GPIO pins and IO pins used as outputs by
active module instances have this parameter. To invert an active
module pin you have to invert the GPIO pin not the module pin.
[{.is\_opendrain}] (Bit, RW) This parameter only has an effect if
the is\_outputparameter is true. If this parameter is false,
the GPIO behaves as a normal output pin: the IO pin on the
connector is driven to the value specified by the outHAL pin
(possibly inverted), and the value of the inand in\_notHAL
pins is undefined. If this parameter is true, the GPIO behaves as
an open-drain pin. Writing 0 to the outHAL pin drives the IO
pin low, writing 1 to the outHAL pin puts the IO pin in a
high-impedance state. In this high-impedance state the IO pin
floats (weakly pulled high), and other devices can drive the value;
the resulting value on the IO pin is available on the inand
in\_notpins. Only full GPIO pins and IO pins used as outputs by
active module instances have this parameter.
[{.is\_output}] (Bit, RW) If set to 0, the GPIO is an input. The IO
pin is put in a high-impedance state (weakly pulled high), to be
driven by other devices. The logic value on the IO pin is available
in the inand in\_notHAL pins. Writes to the outHAL pin
have no effect. If this parameter is set to 1, the GPIO is an
output; its behavior then depends on the
is\_opendrainparameter. Only full GPIO pins have this
parameter.

StepGen

Stepgens have names like hm2\_<BoardType>.<BoardNum>.stepgen.<Instance>.. Instanceis a two-digit number that corresponds to the HostMot2 stepgen instance number. There are num\_stepgensinstances, starting with 00.

Each stepgen allocates 2-6 IO pins (selected at firmware compile time), but currently only uses two: Step and Direction outputs.

The stepgen representation is modeled on the stepgen software component. Stepgen default is active high step output (high during step time low during step space). To invert a StepGen output pin you invert the corresponding GPIO pin that is being used by StepGen. To find the GPIO pin being used for the StepGen output run dmesg as shown above.

Each stepgen instance has the following pins and parameters:

Pins

[{.control-type}] (Bit, In) Switches between position control mode
(0) and velocity control mode (1). Defaults to position control
(0).
[{.counts}] (s32, Out) Feedback position in counts (number of
steps).
[{.enable}] (Bit, In) Enables output steps. When false, no steps
are generated.
[{.position-cmd}] (Float, In) Target position of stepper motion, in
user-defined position units.
[{.position-fb}] (Float, Out) Feedback position in user-defined
position units (counts / position\_scale).
[{.velocity-cmd}] (Float, In) Target velocity of stepper motion, in
user-defined position units per second. This pin is only used when
the stepgen is in velocity control mode (control-type=1).
[{.velocity-fb}] (Float, Out) Feedback velocity in user-defined
position units per second.

Parameters

[{.dirhold}] (u32, RW) Minimum duration of stable Direction signal
after a step ends, in nanoseconds.
[{.dirsetup}] (u32, RW) Minimum duration of stable Direction signal
before a step begins, in nanoseconds.
[{.maxaccel}] (Float, RW) Maximum acceleration, in position units
per second per second. If set to 0, the driver will not limit its
acceleration.
[{.maxvel}] (Float, RW) Maximum speed, in position units per
second. If set to 0, the driver will choose the maximum velocity
based on the values of steplen and stepspace (at the time that
maxvel was set to 0).
[{.position-scale}] (Float, RW) Converts from counts to position
units. position = counts / position\_scale
[{.step\_type}] (u32, RW) Output format, like the step\_type
modparam to the software stegen(9) component. 0 = Step/Dir, 1 =
Up/Down, 2 = Quadrature. In Quadrature mode (step\_type=2), the
stepgen outputs one complete Gray cycle (00 -> 01 -> 11 -> 10 ->
00) for each stepit takes.
[{.steplen}] (u32, RW) Duration of the step signal, in
nanoseconds.
[{.stepspace}] (u32, RW) Minimum interval between step signals, in
nanoseconds.

Output Parameters

The Step and Direction pins of each StepGen have two additional parameters. To find which I/O pin belongs to which step and direction output run dmesg as described above.

[{.invert\_output}] (Bit, RW) This parameter only has an effect if
the is\_outputparameter is true. If this parameter is true, the
output value of the GPIO will be the inverse of the value on the
outHAL pin.
[{.is\_opendrain}] (Bit, RW) If this parameter is false, the GPIO
behaves as a normal output pin: the IO pin on the connector is
driven to the value specified by the outHAL pin (possibly
inverted). If this parameter is true, the GPIO behaves as an
open-drain pin. Writing 0 to the outHAL pin drives the IO pin
low, writing 1 to the outHAL pin puts the IO pin in a
high-impedance state. In this high-impedance state the IO pin
floats (weakly pulled high), and other devices can drive the value;
the resulting value on the IO pin is available on the inand
in\_notpins. Only full GPIO pins and IO pins used as outputs by
active module instances have this parameter.

PWMGen

PWMgens have names like hm2\_<BoardType>.<BoardNum>.pwmgen.<Instance>.. Instanceis a two-digit number that corresponds to the HostMot2 pwmgen instance number. There are num\_pwmgensinstances, starting with 00.

In HM2, each pwmgen uses three output IO pins: Not-Enable, Out0, and Out1. To invert a PWMGen output pin you invert the corresponding GPIO pin that is being used by PWMGen. To find the GPIO pin being used for the PWMGen output run dmesg as shown above.

The function of the Out0 and Out1 IO pins varies with output-type parameter (see below).

The hm2 pwmgen representation is similar to the software pwmgen component. Each pwmgen instance has the following pins and parameters:

Pins

[{.enable}] (Bit, In) If true, the pwmgen will set its Not-Enable
pin false and output its pulses. If enableis false, pwmgen will
set its Not-Enable pin true and not output any signals.
[{.value}] (Float, In) The current pwmgen command value, in
arbitrary units.

Parameters

[{.output-type}] (s32, RW) This emulates the output\_type load-time
argument to the software pwmgen component. This parameter may be
changed at runtime, but most of the time you probably want to set
it at startup and then leave it alone. Accepted values are 1 (PWM
on Out0 and Direction on Out1), 2 (Up on Out0 and Down on Out1), 3
(PDM mode, PDM on Out0 and Dir on Out1), and 4 (Direction on Out0
and PWM on Out1, for locked antiphase).
[{.scale}] (Float, RW) Scaling factor to convert valuefrom
arbitrary units to duty cycle: dc = value / scale. Duty cycle has
an effective range of -1.0 to +1.0 inclusive, anything outside that
range gets clipped.
[{.pdm\_frequency}] (u32, RW) This specifies the PDM frequency, in
Hz, of all the pwmgen instances running in PDM mode (mode 3). This
is the pulse slot frequency; the frequency at which the pdm
generator in the AnyIO board chooses whether to emit a pulse or a
space. Each pulse (and space) in the PDM pulse train has a duration
of 1/pdm\_frequency seconds. For example, setting the
pdm\_frequency to 2e6 (2 MHz) and the duty cycle to 50% results in
a 1 MHz square wave, identical to a 1 MHz PWM signal with 50% duty
cycle. The effective range of this parameter is from about 1525 Hz
up to just under 100 MHz. Note that the max frequency is determined
by the ClockHigh frequency of the Anything IO board; the 5i20 and
7i43 both have a 100 MHz clock, resulting in a 100 Mhz max PDM
frequency. Other boards may have different clocks, resulting in
different max PDM frequencies. If the user attempts to set the
frequency too high, it will be clipped to the max supported
frequency of the board.
[{.pwm\_frequency}] (u32, RW) This specifies the PWM frequency, in
Hz, of all the pwmgen instances running in the PWM modes (modes 1
and 2). This is the frequency of the variable-duty-cycle wave. Its
effective range is from 1 Hz up to 193 KHz. Note that the max
frequency is determined by the ClockHigh frequency of the Anything
IO board; the 5i20 and 7i43 both have a 100 MHz clock, resulting in
a 193 KHz max PWM frequency. Other boards may have different
clocks, resulting in different max PWM frequencies. If the user
attempts to set the frequency too high, it will be clipped to the
max supported frequency of the board. Frequencies below about 5 Hz
are not terribly accurate, but above 5 Hz they're pretty close.

Output Parameters

The output pins of each PWMGen have two additional parameters. To find which I/O pin belongs to which output run dmesg as described above.

[{.invert\_output}] (Bit, RW) This parameter only has an effect if
the is\_outputparameter is true. If this parameter is true, the
output value of the GPIO will be the inverse of the value on the
outHAL pin.
[{.is\_opendrain}] (Bit, RW) If this parameter is false, the GPIO
behaves as a normal output pin: the IO pin on the connector is
driven to the value specified by the outHAL pin (possibly
inverted). If this parameter is true, the GPIO behaves as an
open-drain pin. Writing 0 to the outHAL pin drives the IO pin
low, writing 1 to the outHAL pin puts the IO pin in a
high-impedance state. In this high-impedance state the IO pin
floats (weakly pulled high), and other devices can drive the value;
the resulting value on the IO pin is available on the inand
in\_notpins. Only full GPIO pins and IO pins used as outputs by
active module instances have this parameter.

Encoder

Encoders have names like hm2\_<BoardType>.<BoardNum>.encoder.<Instance>.. Instanceis a two-digit number that corresponds to the HostMot2 encoder instance number. There are num\_encodersinstances, starting with 00.

Each encoder uses three or four input IO pins, depending on how the firmware was compiled. Three-pin encoders use A, B, and Index (sometimes also known as Z). Four-pin encoders use A, B, Index, and Index-mask.

The hm2 encoder representation is similar to the one described by the Canonical Device Interface (in the HAL General Reference document), and to the software encoder component. Each encoder instance has the following pins and parameters:

Pins

[{.count}] (s32, Out) Number of encoder counts since the previous
reset.
[{.index-enable}] (Bit, I/O) When this pin is set to True, the
count (and therefore also position) are reset to zero on the next
Index (Phase-Z) pulse. At the same time, index-enable is reset to
zero to indicate that the pulse has occurred.
[{.position}] (Float, Out) Encoder position in position units
(count / scale).
[{.rawcounts}] (s32, Out) Total number of encoder counts since the
start, not adjusted for index or reset.
[{.reset}] (Bit, In) When this pin is TRUE, the count and position
pins are set to 0. (The value of the velocity pin is not affected
by this.) The driver does not reset this pin to FALSE after
resetting the count to 0, that is the user's job.
[{.velocity}] (Float, Out) Estimated encoder velocity in position
units per second.

Parameters

[{.counter-mode}] (Bit, RW) Set to False (the default) for
Quadrature. Set to True for Up/Down or for single input on Phase A.
Can be used for a frequency to velocity converter with a single
input on Phase A when set to true.
[{.filter}] (Bit, RW) If set to True (the default), the quadrature
counter needs 15 clocks to register a change on any of the three
input lines (any pulse shorter than this is rejected as noise). If
set to False, the quadrature counter needs only 3 clocks to
register a change. The encoder sample clock runs at 33 MHz on the
PCI AnyIO cards and 50 MHz on the 7i43.
[{.index-invert}] (Bit, RW) If set to True, the rising edge of the
Index input pin triggers the Index event (if index-enable is True).
If set to False, the falling edge triggers.
[{.index-mask}] (Bit, RW) If set to True, the Index input pin only
has an effect if the Index-Mask input pin is True (or False,
depending on the index-mask-invert pin below).
[{.index-mask-invert}] (Bit, RW) If set to True, Index-Mask must be
False for Index to have an effect. If set to False, the Index-Mask
pin must be True.
[{.scale}] (Float, RW) Converts from countunits to
positionunits. A quadrature encoder will normally have 4 counts
per pulse so a 100 PPR encoder would be 400 counts per revolution.
In .counter-modea 100 PPR encoder would have 100 counts per
revelution as it only uses the rising edge of A and direction is
B.
[{.vel-timeout}] (Float, RW) When the encoder is moving slower than
one pulse for each time that the driver reads the count from the
FPGA (in the hm2\_read() function), the velocity is harder to
estimate. The driver can wait several iterations for the next pulse
to arrive, all the while reporting the upper bound of the encoder
velocity, which can be accurately guessed. This parameter specifies
how long to wait for the next pulse, before reporting the encoder
stopped. This parameter is in seconds.

Examples

Several example configurations are included with EMC for both stepper and servo applications. The configurations are located in the hm2-servo and hm2-stepper sections of the EMC2 Configuration Selector window. You will need the same board installed for the configuration you pick to load. The examples are a good place to start and will save you time. Just pick the proper example from the EMC2 Configuration Selector and save a copy to your computer so you can edit it. To see the exact pins and parameters that your configuration gave you open the Show HAL Configuration window from the Machine menu or do dmesg as outlined above.