The HAL configuration for the Logitech gamepad has only a few changes from the decade-ago (!) version.
The HAL driver will reverse the direction of the Y and Z axes by feeding -127.5 to the
flat inputs make sure the joystick knob has a dead zone around the rest position; otherwise, the axes tend to crawl off without a hand on the controls.
The gamepad doesn’t emit any values until you poke a button or move a joystick, the driver starts up with all zeros in its
counts registers, so the HAL axis
position pins emit XYZA = -1 +1 +1 -1 just as if you had the joysticks jammed hard at their upper-left corners. The only way out is to squelch the joystick until a button gets pressed and the machine is turned on:
The Gamepad-Valid signal forcibly disables all four axes:
That’s from an earlier iteration of the axis priority logic, before I got the Kicad annotate-starting-at-100 code working.
I somewhat finessed the startup issue by dedicating two of the gamepad’s back-panel buttons to clearing the initial E-Stop and turning the machine on:
However, if you flip those two conditions with the LinuxCNC GUI, the joysticks will remain zeroed until you do poke a button or move a knob. So, without the
Gamepad-Valid logic, the Sherline will take off for the far upper left corner at a pretty good clip, which is not what you want.
The gamepad outputs remain valid for the rest of the session, so there’s no need to reset the
Gamepad-Valid flipflop. HAL does not take kindly to hotplugging USB devices, so (AFAICT) you can’t hard-reset the gamepad + driver to the initial no-data-yet condition.
Earlier versions of the top two schematics used CONSTANT symbols, but it turns out PARAMETER symbols work just as well and the resulting
setp commands eliminate the need for nets and real time functions.