Printable View
I am interested in adding "cycle start" and "feedhold" physical button to my slant pro. I have no problem understanding how to hook this up and add push buttons to my console. What I'm wondering is from the pathpilot side can I tie the inputs to those functions? From the description it sounds like it is designed for G and M codes, but I am not having much luck finding any real detail.
The USBIO unit allows you to control relays and read switches via gcode. I don't think that is what you want.
By far the easiest way to get functions that have a keyboard shortcut (CycleStart, Reset, etc) is via a keyboard emulator. You use an Arduino or Teensy or... to make PP think that you have typed whatever on the keyboard. I have been happily using such for years on my 770. The best part is that no changes to PP are required; it just works. Total parts cost is perhaps $25. I wrote an article for Digital Machinist magazine that provided detailed instructions and there is other material online.
Could you not bring the Button to an USBIO input then map that to Halui.program.start ??
(;-) TP
Yes, that should work but you'd have to reapply the changes with each PP update.
Have you tried it?Quote:
Originally Posted by vmax549
Step
David at millfastproducts.com is hooking me up with a version of his module pre-programmed for the two buttons I want. Barely more than buying (2) MAME programmable usb buttons and this way I can wire cycle start and feedhold to buttons on the console I built off Keen's design.
For cycle start (Alt-R,) feedhold (space) and stop (Escape) I agree -- just map it to a keyboard key!
It's great if you can buy a pre-programmed device.
Otherwise, doing this with a Teensy LC (about $12, plus some wiring) is quite easy if you have any software development experience. (And there are examples on the web if you're not ...)
For more interactive control, like jog wheels, you really do want them to go through the HAL, because the USB based turn-around time will be too laggy in my experience, but as long as you're just looking for "stop/go" then USB is by far the simplest! And it doesn't need any re-configuration, so works with the upgrades, too.
I do not has a usbio to test with but you may try this.. Add these lines to the HAL file and add the switches to the usbio pins 0,1
net run-btn <= usbio.input-0 => halui.mode.auto => halui.program.run
net stop-btn <= usbio.input-0 => halui.program.stop
(;-) TP
So, let's talk numbers here. What exactly do you regard to be your "USB based turn-around time" to be (in milliseconds) and what speeds would you need to achieve (in milliseconds) for a successful jog wheel implementation?Quote:
Originally Posted by jwatte
Step
Well, haptics research tells us that you really need 2 kHz to be "like real" and the USB bus interval is only 1 ms, so you already missed that boat :-)
That being said, if you get 5 ms latency from encoder to pulse out, I think it will feel alright, and you *may* be able to get away with 10 ms. More than that, I would eye with significant skepticism, and, more importantly, something with variable latency would be terrible.
I base this more on my experience with low-latency media and VR than with low-latency machining, though.
At that level, basically anything that has to go through the Python level of the PathPilot, is likely to fail, because there are already several milliseconds in the USB bus and driver and kernel, even for a "high performance" streaming device. Python is not only sluggish and single-threaded, but it also randomly waits a little bit for garbage collection. So, if that's the way you want to go, I'd suggest some kind of HID event device that the LinuxCNC HAL can read directly. I don't know if suitable low-level plugins already exist, or if you need to write one. Also, you'd need to encode "number of ticks" in each HID event, because 200 Hz / 5 ms is not enough to get good precision on "velocity" when doing precision work if you just have "tick or not" as the signal.
As an alternative viewpoint the Tormach jog shuttle works OK for me. It is USB attached but uses a C rather than Python interface module.
I know from experience the shuttle puck has to be plugged directly into computer. NO usb hub! Plugging control puck into usb hub caused significant problems on my lathe.Quote:
Originally Posted by TurboStep
Hi MDQuote:
Originally Posted by mountaindew
I doubt the shuttle was the reason behind your problems because it has very low demands on the USB interface. It works in a completely different way to a "conventional" encoder with the exception of the middle wheel which has only 10 pules per rotation and you can't really turn that very fast.
I suspect the interface is programmed in C but it could also be compiled Python. It doesn't make any real difference because it connects python code in PP anyway.Quote:
Originally Posted by kstrauss
I've modified my USB Pendant (pictured in the other thread) to show that it CAN be done. I'll post a video in the next day or two.
Step
The interface code for the ShuttleExpress (Tormach jog shuttle) is part of the standard LinuxCNC distribution and is a C module.Quote:
Originally Posted by TurboStep
[quote}As an alternative viewpoint the Tormach jog shuttle works OK for me.[/quote[
Sure! But that's not a "hand wheel/encoder" setup -- it's more of a substitute for the arrow keys, or a joystick.
If that's all you want, have at it! You could probably also make a wired Xbox game controller work fine, too. (Actually, that might be kinda neat!)
For "pendants" I expect the desired behavior is a "hand wheel" that feels more or less like a manual mill; you turn it X amount, and the table moves exactly X, right away. For that level of response, you need much higher data/sample rates, and the best technical option is to use a high-resolution encoder and sampling it using the hardware pins on the Mesa controller.
Depending on your specific demands, there are many ways to skin that cat!
Perhaps I'm less critical than you but I find moving the mill with the jog shuttle to be very smooth and intuitive. I leave mine set to steps of 0.0001 inch and move quickly with the multi jog rate rotating switch rather than the encoder. When I'm within a few thou I use the encoder. On the other hand I've repackaged my shuttle with a paddle handle and a proper knob for the switch plus wheel with knob for the encoder. As with a manual mill I often make cuts completely controlled by the shuttle.
Do you have such an encoder on your Tormach???Quote:
Originally Posted by jwatte
Step