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 Emcfirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/emc-users