Here at the CNC workshop I had an opportunity to plug in a device which
identifies as
I: Bus=0003 Vendor=0b33 Product=0020 Version=0117
N: Name="Contour Design ShuttleXpress"
The bottom of the device says
Shuttle Xpress
Model No. S-XPRS
S/N: 0 0 4 7 x x x
and there doesn't seem to be a date code.
While this device is recognized by hal_input, it behaves very oddly--the
way it operates is at odds with other similar devices. I don't think
this device would be useful with emc without device-specific hacks, and
even then it would be problematic. Read on if you'd like a longer
explanation.
In a traditional HID "relative" axis, each report holds the difference
between this report and the prior report. So for instance on a USB
mouse with the wheel being repeatedly clicked in the second direction
the reports would look like "1, 1, 1, 1" with an occasional 2. A report
of 0 is never given. In a HID "absolute" axis, each report holds the
current position of the item. So for instance on a USB joystick moving
an axis from left to right the reports might look like "-100, ..., -50,
..., 0, ..., 50, ..., 100" and on the release of the axis it would go to
"0" as it self-centers.
The ShuttleXpress reports both of its axes as relative, even though the
shuttle portion is absolute. But in the case of both axes, the
reporting is of values appropriate to an absolute axis, not a relative
one.
So when you move the shuttle to the right, it gives a report of "1, 2,
3, 4, 5, 6, 7". When you release it, it snaps back and may report an
intermediate value like "3", but never reports "0". If you move the shuttle
part way to the right and rock it, it gives a report like "3, 4, 3, 4,
3, 4" and the counts quickly accumulate. If you hold the shuttle in
place, it gives repeated reports like "7, 7, 7" every few seconds.
Since hal_input adds the reported value to the accumulated value, this
means the shown "counts" value has gone up to a value like 168 by now,
even though the current position of the shuttle is centered.
But it gets worse! Rotate the jogwheel. It behaves in the same way:
reporting 1, 2, 3, which again sums up to a wildly large "count". There
are at least two more odd things. After 255 or before 1, the next
detent gives you "no count" (i.e., zero). And if both the shuttle and
the jog are displaced from the location they report as 0 counts, they
both count up like gangbusters.
All this works together to make the device completely unusable with
hal_input. I spent a fair part of the evening trying to figure out a
way to turn the events I get from the Linux input driver into something
sane (even if it meant a separate HAL driver from hal_input), and I
can't figure that out yet. For instance, imagine you use the shuttle to
jog in one of 8 slow speeds. When you let go of the shuttle, it snaps
back to the unreported "zero" position, but there's no report for that.
There's no guarantee it reports "1" either. So you can't tell for "a
few seconds" (until a report of a held position would have arrived) that
you've returned the shuttle to home. Do you want your machine to keep
jogging for 5 seconds after you stopped? A resounding "No!".
The jogwheel already isn't very useful due to its small number of
reports per revolution (10), and the fact that 1 report out of 256 is
lost (what's worse, the lost position will be at varying positions of
the spinner since 256 is not a multiple of 12).
As a result of this experience, I do not recommend the Shuttle Xpress to
anyone who hopes to use it with emc2.
Jeff
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
