Still the G-Code execution is on the controlling computer where there's plenty of horsepower to do neat things such as integrating various custom signals into the G-code path planning system.Īt this point I will say the the line between what you describe and what I'm talking about is blurred such that we're really talking about the same thing. I understand that some of the larger commercial systems use ethernet to control motors. In fact, most commercial LinuxCNC installations typically use MesaNet cards or equivalent. As parallel ports vanish, cheap MesaNet cards often replace them. This is because parallel ports are cheap and reliable, don't require extra hardware, and can be driven in real time. These include mill conversions, 3D printers, and plasma tables. There are a lot of home CNC setups these days using LinuxCNC and many of them use parallel ports to control stepper drivers. I'm aware of how CNC works, both g-code generation and execution. But reliable, proven, and capable of high frame rates. The microprocessor runs a purpose-built firmware.
The USB bus is essentially a glorified serial port link that communicates between the microprocessor and the host computer.
Like most devices attached to the USB bus, the data acquisition board you link to has it's own onboard microprocessor that does the actual ADC measuring, and reads and writes the I/O ports, and then sends the data (in response to commands) back to the computer. In fact gamers often go for PS/2 keyboards because USB keyboards have a latency that makes their game play more difficult, believe it or not. The USB bus and protocol just isn't designed for it. USB cannot be used directly for interfacing with and controlling hardware (as you can do with an Arduino) because USB does not allow real-time signalling. Parallel ports are hard to find these days, so a lot of CNC machinery and data acquisition use I/O interface boards plugged into the PCIe bus. Parallel ports are still commonly used to control CNC machines because they are one of the few interface standards that have direct connections into the CPU's bus and can be controlled in real time by the processor. So the hardware from the controller along with the FreeBASIC getJoyStick function could be used to input digital data.Īlthough you considered the K8055 to be rubbish the fact is it worked, albeit a bit slow, to send commands and read inputs without having to solder your own versions of its support circuitry.
I see the controller has a single chip in it between the usb port and the buttons.
h4tt3n has a financial motivation.įreeBASIC has the getJoystick() function which I just tested with a Logitech game controller so who ever wrote that function must know how it is done.
I couldn't get my code to run fast enough to keep up with the commands coming in over serialĪs back then I don't seem to have the motivation to work through all this the way I used to in the old days. Also caseih wrote: By the way, BasicCoder, my little Arduino LCD screen project ended in a sort of failure. I noted the Arduino was too slow for D.J.Peters. If I ever do I will write a proper fully explained step by step tutorial.
BasicCoder2 wrote:Haven't found your "working" Arudino code yet.It's in the old thread, where we've discussed your robotics project.