USB M-Code I/O Interface Kit
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.
Re: USB M-Code I/O Interface Kit
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.
Re: USB M-Code I/O Interface Kit
Could you not bring the Button to an USBIO input then map that to Halui.program.start ??
(;-) TP
Re: USB M-Code I/O Interface Kit
Yes, that should work but you'd have to reapply the changes with each PP update.
Re: USB M-Code I/O Interface Kit
Quote:
Originally Posted by
vmax549
Could you not bring the Button to an USBIO input then map that to Halui.program.start ??
(;-) TP
Have you tried it?
Step
Re: USB M-Code I/O Interface Kit
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.
Re: USB M-Code I/O Interface Kit
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.
Re: USB M-Code I/O Interface Kit
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
Re: USB M-Code I/O Interface Kit
Quote:
Originally Posted by
jwatte
...because the USB based turn-around time will be too laggy in my experience...
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?
Step
Re: USB M-Code I/O Interface Kit
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.
Re: USB M-Code I/O Interface Kit
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.
Re: USB M-Code I/O Interface Kit
Quote:
Originally Posted by
TurboStep
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?
Step
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.
Re: USB M-Code I/O Interface Kit
Quote:
Originally Posted by
mountaindew
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.
Hi MD
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.
Quote:
Originally Posted by
kstrauss
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 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.
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
Re: USB M-Code I/O Interface Kit
Quote:
Originally Posted by
TurboStep
Hi MD
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.
The interface code for the ShuttleExpress (Tormach jog shuttle) is part of the standard LinuxCNC distribution and is a C module.
Re: USB M-Code I/O Interface Kit
[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!
Re: USB M-Code I/O Interface Kit
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.
Re: USB M-Code I/O Interface Kit
Quote:
Originally Posted by
jwatte
... 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...
Do you have such an encoder on your Tormach???
Step