This would make a stellar machine controller

[lumberjack_jeff]

Would it be practical to port EMC2 (including the required RTAI kernel OS) to this? Is there talk of developing a parallel port shield?

[Warringer]

The Pi currently has 8 bit parallel GPIO, 2 wire I2C, 3 wire SPI made accessible through a header. Sadly only at 3.3V.

But Gert has made a nice IO board for the Pi already that is going to be buyable when the Pi comes out IIRC.

As for the EMC2, the Pi runs Linux out of the Box and it should be possible to write a nice plugin for the EMC2 for the Pi and the GertBoard.

In any case you can always use USB interfaces supported by EMC2.

[Joules]

What USB devices does EMC2 support? I have run EMC2 for several years with a CNC router and have never come across any support for USB as the data clocking can't be locked in.

Yeah, I too am interested in the idea of machine control and power management.

[Wooloomooloo]

Warringer said:


In any case you can always use USB interfaces supported by EMC2.


There are no USB interfaces supported by EMC2. At least, according to their own wiki. And you can definitely forget about parallel port emulation via USB.

There seems to be a Russian guy playing with EMC2 on an ARM board, although he uses web-based control for his box instead of the standard EMC2 GUI. Perhaps he might be interested, once the Pi becomes available. Anyway, a standard Linux without real time support is not going to work.

[Warringer]

Not knowing EMC2, not the lack of interest through, just the lack of money to build a machine and interface, it was just a thought that there may be a USB supported device.

But I'm reasonably sure that you could do the interfacing with the GPIO, I2C or SPI interfaces. Would require you to program a driver through...

Anyway, since you can put everything you want on the Pi, it should be possible to build yourself a Real Time Kernel for the Pi.

[CombatWombat42]

I suspect this board would not be fast enough for most emc2 applications. I would have to run the PID loops onboard and run the gui, I doubt its fast enough for that. If you wanted to command it with another computer and have it just run the PID that would work but you might at well use an fpga or standard micro-controller.

[mung]

As I assume the boards will be on sale in the next 3 weeks I am starting to think about EMC2 and the Pi board.

I am also wondering when the gertboard will be available, as its probably not worth starting work unless a release to the IO board is iminent also.

I thought about USB interfaces for proper emc2 control and the general consensus is that its not possible due to latency and minimum usb packet size, though I thought maybe it could be possible if two seperate usb controllers were used?.

Has anyone started work on compiling EMC2 for the Pi yet?

The link above to the russian guy(miniemc2 on google code) looks like he is making a hacked down version and uses Xenomai and FIQ (not something I know anything at all about but I heard Xenomai has an rtai compatability skin). As far as I know rtai supports ARM and it should be possible to do a full emc2 compile and install if the rtai kernel can be built(I am not an expert though!!!)

I have done a very quick browse of the russian site linked above and it looks like a lot of good work has been done, but it makes me think that maybe hacking at the miniemc2 project may be beyond me.

I compiled emc2 and a rtai patched 2.4 kernel for a 486 system I had a couple of years ago but had problems getting things working with that and unfortunately lost interest.

I think there may be some HAL patching problems for the kernel with rtai on ARM?

If others are interested and it looks like the Pi and IO boards will be available I may give rtai kernel compile a quick try (thought my tries are often unsuccessful). Maybe an interesting project to  see if it is easy and quick to get a full and proper emc2 compilation working?.

[mole125]

Using it as a brains of a lazer CNC is what my first plans for it are. Not looked at the software stack side yet but this certainly looks like a promising option.

I was planning to just integrate the hardware directly rather than waiting for the Gertboard - though I may get one of them later when prototyping other projects as well.

The plan is to use cheap hobby motors rather than stepper motors to control the movement, using the sensor from a mouse to track actual movement and outputting PWM to control the speed. How well and accurately this will work we will have to see - and whether this can be done on the standard kernel or require a real time version.

[mung]

running emc2 will require realtime kernel support, I have just spent the morning trying to compile the kernel without luck.

I THINK REALTIME KERNEL IS AN IMPORTANT THING FOR PI.

As with most things I do, the more I do the harder it seems

I thought I should post this link as realtime kernel seems very important to me!

realtime kernel thread

I am about to make a post to show step by step how far I have got in compiling the kernel this morning.

Unfortunatly I am alreadying begining to lose interest and think that the task is beyond me.

Maybe will look again tomorrow, but would be very pleased if someone else picks this up and fixes it.

[mung]

cannot post to forum???

[Gert van Loo]

mung said:


cannot post to forum???



Yes you can!

[mung]

I do not like to post off topic but, maybe I should elaborate on my previous statement!

It seems impossible to cut and paste any text into a thread posting if:

1) the pasted text is more than  14lines

2) the pasted text has more than 2 web addresses in

3)the pasted texts does not have more than 2 lines of manually typed text

4)a few variations and permutations of the above circumstances?

Probably admin have put my user ID on a spam list??

[Bakul Shah]

Wooloomooloo said:


Anyway, a standard Linux without real time support is not going to work.


May be you can offload hard realtime logic to the Gertboard?

[mole125]

From what I can tell from the website the need for a real time kernel is to ensure that servo motors are driven at a constant accurate rate. Access to the hardware level PWM functionality should hopefully allow for a bit more tolerance of timing variation - though I don't know what this would do for positional accuracy.

[mung]

Bakul said:


Wooloomooloo said:


Anyway, a standard Linux without real time support is not going to work.


May be you can offload hard realtime logic to the Gertboard?



From what I saw of the gertboard there is a pic controller on it so what you say is possible, but unfortunately offloading the realtime logic sort of removes the whole point of running EMC2?.

I am not an EMC expert so my opinion may be totally wrong and there is a lot more to EMC2 than just the realtime control such as path planning and kinematics calculations and tool simulation and display, but I feel part of the appeal is that EMC2 has direct  incremental  readings of position which allow the system to be easier to setup, program and handle errors should the machine crash.

I also am starting to get the feeling that maybe this forum is not the place to be discussing how to compile EMC2.

Probably the project should be divided into :

1)getting the realtime kernel running and rtai compiled for the pi (handled on the pi forum)

2)compiling EMC2 for arm (handled on the EMC2 forum where there are experts that know about the system)

3)working out low level GPIO drivers and interfaces to EMC2 for the pi  (handled on pi and EMC2 forums)

[mung]

Just thought I would post some links to what seem like other relevant forum posts:

http://www.raspberrypi.org/for.....3d-printer

http://www.raspberrypi.org/for.....3d-printer

[109jb]

I just wanted to make a few comments about this topic.  I recently purchased a Raspberry Pi in the hopes that I will be able to use it as a machine controller using LinuxCNC/EMC2. I will anxiously await its arrival.

First off, I believe that the RPi would make a fine dedicated machine control computer. It won't be for everyone, as some people want to be able to run the machine controller, CAD and CAM software, etc. The way I would use it is as a dedicated controller running basically only the linux OS and EMC2.

In regard to RTAI, I believe it is absolutely necessary for this application and offloading the real time processing to another board would be useless. If that were the only option I would just go to an ATOM based board that would be capable of running anything I want, but that would be like driving a nail with a jackhammer as far as I am concerned.

As for the I/O, as I understand it, the UART, SPI, and I2C pins can be reprogrammed as GPIO which would give up to 17 pins available for GPIO. For a typical 3-axis machine the following would be the minimum:

1 out - enable (enables all axes of the machine)

6 out - (1 step and 1 direction pin for each axis)

3 in - one limit/home switch for each axis

1 in - Emergency stop

That is a total of 11 pins used which would leave up to 6 additional pins available for additional axes, spindle control, etc. Certainly enough for most hobby CNC machines.

As for the I/O interface, I think I would just go with an optically isolated breakout board. Stepping up the 3V3 output to 5V0 would not be a problem, it would be cheap, and it would protect the RPi from any misapplied electron coming from the other direction.

RTAI is the first step though.

[Serac]

I also am starting to get the feeling that maybe this forum is not the place to be discussing how to compile EMC2.

Probably the project should be divided into :

1)getting the realtime kernel running and rtai compiled for the pi (handled on the pi forum)

2)compiling EMC2 for arm (handled on the EMC2 forum where there are experts that know about the system)

3)working out low level GPIO drivers and interfaces to EMC2 for the pi  (handled on pi and EMC2 forums)

1) Realtime control is an interest of mine, so the first task was to compile a patched kernel. Using the latest ipipe patch from the Adeos team (this is the basis for both RTAI and Xenomai), 3.2.21 compiled without errors with the cross-compiler toolchain. A quick pass of the RTAI code shows significant bitrot for the arm architecture - Not insurmountable, but a debatable undertaking considering that Xenomai already works on many arm platforms and the team is very active in supporting the architecture.

2) Looked at the EMC2 code and it is real ugly and convoluted. The "build" system has all the hallmarks of a sick puppy up chucking every time it is let out the door. Forget cross compiling - This means having to compile on the Rpi and having ALL the development packages installed on your SD card or NFS mount. You'll then end up with a shedload of duff & cruft that makes no sense in having around on an embedded system. No point in having drivers for PCI cards when you don't have a PCI bus !

A better starting point may be grbl or parts from the RepRap project. There have also been other derivatives of the (original NIST) EMC code that might prove to be a more viable starting point.

3) The Rpi I/O is severely limited, but with the SPI/I2C bus handling the bulk of any non-critical (speed wise) I/O, there looks like there'd be sufficient pins left for three stepper motors. An alternative may be to use all the available I/O pins to implement a simple bus to communicate with an external FPGA board e.g.:http://papilio.cc/. What ever route is followed for I/O, the driver need not be complicated (unless you really want to follow the EMC2 model).

In closing, the Rpi has plenty of power to run as a realtime CNC control, onboard graphics adds to the appeal, as does the low cost. Interfacing is not an insurmountable obstacle, nor is the software - It really boils down to how much effort you are prepared to put in to get a project like this to fly.

[servant74]

EMC2 renamed itself to LinuxCNC officially after some 'lawyer mail' from EMC Corporation. The re-branding had been there for a long time, but the push by EMCs lawyers made it happen several months ago.

Yes, the LinuxCNC code is not pretty, but it does SO many things. It is also not easy to get running outside of the many pre-configured options. But it can be done, and their support group is very helpful. Linux CNC started out as a government project for an 'Enhanced Machine Controller' to help kickstart automated manufacturing many years ago (thus the EMC moniker). It now is capable of driving without to much problems gantry type machines that do additiive (think Reprap) or subtractive (think laser cutter, plasma torch cutter, rotary cutters like mills (think buildyourcnc.com or mechmate.com, but not limited to them), and much more.

One very powerful aspect of LinuxCNC is the ability to be a PLC or programmable logic controller ( en.wikipedia.org/wiki/Programmable_logic_controller ).

Or even drive a hexapod (Stewart Platform) machine lik http://www.youtube.com/watch?v=G_UmhUjZhNo

And so much more ... Yea I am a fan. ... The guts may be ugly, but it does so much with so little.

[AndrewS]

There's a bunch of other related posts on these forums too (with more information)
http://www.raspberrypi.org/phpBB3/searc ... s=linuxcnc

[Serac]

EMC2 renamed itself to LinuxCNC officially after some 'lawyer mail' from EMC Corporation. The re-branding had been there for a long time, but the push by EMCs lawyers made it happen several months ago.

The only evidence presented for this name change is hearsay and a claim that letters had been sent. No copies of this alleged 'lawyer mail' has ever been presented to the developers as a group. The name change has been imposed by a minority of one or two on the pretext that they control the project.

Politics aside, there is some code within EMC that can be used to make a controller fly on a Raspberry Pi - Bear in mind that the early releases of the original EMC code ran quite happily on a 166MHz X86 box with 64MB of memory. Cut the bloat and ugly cruft, and there is no reason why it shouldn't run on a Pi.

Only two real issues exist - 1) IO limitation of the Pi board. 2) Performance of generating step/dir pulses with the current arm processor - Both may well be better addresses by using either an FPGA board or an Arduino+shield.

Weekend tonight, so I get time to test the latest RT patched kernel

[mung]

I see that there are some discussions going on on the emc-dev mailing list......

http://www.mail-archive.com/emc-develop ... 06885.html

Emc(linuxcnc) does compile in sim mode on the RPI for most debian dists, I had a brief problem when I switched to raspbian but found that was dependency problems probably due to my own stupidity.

I think the runtests script fails on 2 tests, but there should not be too much problem fixing this.

I have not really spent any time looking at the kernel code or what problems drivers may cause to real time scheduling, but patching the cboot 3.2 kernel with RT_PREEMPT patches seems to compile okay but does not boot.

Getting the realtime kernel working will be the hardest part followed by writing IO drivers for emc.

I have not really done anything about looking at the kernel, I was messing with interfacing an AVR chip and i2c last weekend.

Looking at raspbian I think the RPI kernel still has some problems in the USB or networking drivers I get fairly frequent system freezes and USB device resets (maybe my keyboard or mouse are no good???), but seems to be worse when the ethernet is plugged in.

Unfortunately kernel hacking always seemed to take a huge amount of time working out what code was doing and how it needed to be changed, and I always leave the hard and arduous things till last in the hope someone else will do them

I get the feeling some genius behind the scenes may get realtime working within 3-4 months, as it seems to me most of the talented don't bother wasting time posting on forums until they solved the problem. I am really posting here in the hope that someone more talented than I will get interested and get realtime kernel working.

Checkout the realtime thread here:

http://www.raspberrypi.org/phpBB3/viewt ... =63&t=2376

[mung]

Just thought I would make a screen grab on linuxcnc compiled as simulator on raspbian, the problems I had I think were due to conflicting versions of tcl and tk.

emc64.png (52.09 KiB) Viewed 13729 times

I was messing around with interfacing electronics at the weekend rather than looking at the kernel, I think I will not be looking at kernel RT compilation until things get a bit more stable on my PI (maybe kernel problems or maybe I need new keyboard or mouse??)

rpipcirc4.jpg (61.23 KiB) Viewed 13729 times

[onlyjus]

Any progress updates?

I have been thinking about this recently. There are stepper driver boards that just need two inputs (step and direction), thus you only need to use 6 GPIO for a 3 axis machine. Maybe a good way to go? Of course if you want limit switches, E-stop etc. that needs more but my machine doesn't have any

Also, Why is there a need for a real time OS? I guess what you really need is for all the steppers to step at the exact same time? Why not just multi-thread each stepper control code, but use blocks to fire all step pins at the same time?

[onlyjus]

The other thing I was thinking about is why not combine an arduino with the raspberry pi?

Why not use a stripped down EMC on the PI (gcode interpreter, connectivity, gui, motion planning)
and send the steps to an arduino running grbl? That way you do not need a real time kernel, avoid the limitations of grbl on the pi and leverage the signfiicant amount of work put into developing both EMC2 and grbl.