interesting.
maybe we need a raspberry cnc software kit. something simpler than emc perhaps.
Printable View
That doesn't mean it can't be done.
Most of the discussion from real time purists is that events must happen precisely at the scheduled clock time (latency is typically 5us or so).
For driving a servo, where you only send updates every 1ms, you can be pretty lax in your updates (not too slow though, or the machine will wander).
As for real time ethernet, I've been playing around with microcontrollers to act as the client side (LinuxCNC still on a PC, talking RTNET to the client, which does simple GPIOs, encoder counting and PWM generation). When I get time, I'm going to try this with a Beagle Bone.
Pretty big obstacle. Without that, something like kmotion (dynomotion) for Linux is needed ?
Someone mentioned that earlier.
Additional hardware somewhat works against the small/cheap argument. If the user was already inclined to pass control to external board(s) the small/cheap argument has merit.
As I understand it, Mach does a lot of stuff within the PP driver that you wouldn't necessarily expect to be done there e.g. backlash compensation. Thus Smoothstepper has to duplicate a lot of that functionality within its firmware. This is probably why SS is Mach specific.
bob
When I click on your drivers link, I get an ebay auction for a book. Parallel ports are a lot more reliable than USB ports because the control software can lock the port for only it's use. Timing issues are the biggest problem with USB. LinuxCNC can use the USB ports for things like joypad controls, but you have to use either the parallel port or motion control cards like the Mesa or Pico cards for motion control.
Mark
cnczone is putting in annoying word ads. are they that desparate from money? :P
i didnt post the usb board. its somewhere in the xzero thread.
anyway, you have not answered my question. usb is reliable for cnc, its proven that to me. parallel port is NOT. its proven that to me also, very clearly in both mach and emc2 (though its marginally better in emc2).
so your opinion aside, what stops emc2 from using usb for control? can drivers not be written at all?
:)
From what I grasp (and it isn't much :) ) USB port is rubbish for the type of data transmission needed for motion control. For these USB boards to work they need to BE the control and in that situation USB is fine. The information they cue up from the motion planner (Mach, Kmotion, whatever) only needs to be transmitted reliably enough, the 'black box' takes care of the time critical stuff.
Maybe linuxcnc is built in a way that makes accommodating these USB boards difficult. The planner and the control could be inseparable ?
Or maybe no developer with the skills has an interest in this path.
In any case it's starting to look like linuxcnc (emc2) won't be a solution for the raspberry pi any time real soon.
Just my two cents based on nothing but some reading.
.
well yes, the usb cant be use the same way as the parallel, thats obvious. mach3, as i understand it, creates bundles of steps, and sends them out over usb, with board then creating the realtime stream. latency in the usb becomes a non issue as long as theres enough buffer.
Hi folks. I come at this from the pov as both a programmer of embedded systems (including projects for the ARM), and also as a hobby machinist - I own a Sieg SC4 hobby lathe. I'm considering getting a milling machine, thinking about CNC, and thinking that the Raspberry Pi would make a perfect CNC computer. Put "Raspberry Pi" and "CNC" into search engine and here I am.
I'd like to comment on some of the things I've been reading here. Now mostly I'm going to be disagreeing (otherwise I wouldn't have been motivated to join), so I hope that doesn't make me seem disagreeable! :)
Memory: from the pov of an embedded programmer, 512MB is a humungous amount of memory. You guys are spoiled by your bloated commercial OS.
I would point out that all the hard stuff can be done on a PC and stored on the SDcard as a data file - a kind of script to follow. All the RPi would have to do is read and write a few PIOs. I would have thought the application should be relatively trivial, doable in a few hundred bytes! Of course we'll need bootstrap and sdcard code on top of that - so call it a few thousand bytes. 512MB? And you think that won't be enough? Sheesh!
Everyone seems to be assuming that some fancy OS is needed: Android or Linux. What for? If you want real time deterministic operation then the simpler the stuff is between your app and the hardware, the better. We need a couple of device drivers and the app. We don't need a full blown OS, we don't need USB and Ethernet, blah blah, and fact all that stuff could only get in the way. You just have the app itself and a minimal HAL.
USB is what you use on PCs because you don't have PIOs, and the OS won't let you fiddle with the 2nd best choice - parallel port pins reliably - i.e. you use USB on PCs because you have no other choice. Otherwise it's a terrible choice with little or no control over timing. There is nothing unreliable about parallel ports, it's the bloated OS interfering that makes them unreliable. But still, real PIOs are better than a parallel port.
To someone who commented on only needing to update position every 1ms. That might be true, but there's a fundamental difference between frequency and precision. How accurately do we need to hit that 1ms mark?
Yes, that would make it reliable. Basically in that case the external board is the real CNC computer, USB only being used as a medium to copy the data - not to directly control the operation.
The RPi board could directly replace the external board... but since data can be copied via sdcard, you can eliminate the USB complication.
i think you have fully misunderstood the idea here. we dont want to replace an external control board. we want to replace the PC.
if you cant replace the pc, there absolutely no point to the endeavour because theres already a direct connection to the drives from the pc.
in any case, the raspberry has to talk to the drives, which has to be done either by usb, or by gpio. given the available usb solutions, they seem the best route to me. it just needs an os that supports it.