EMC2 running on Raspberry Pi?

mungkie wrote:

mhaberler wrote:

this tree compiles, and on xenomai it runs HAL+RTAPI, plus Gladevcp. I did not get Axis or one of the other UI's to work, mostly because of the OpenGL problem I mentioned, maybe some others. Did you get axis to run on the Pi? if so, I would be very interested in the list of installed packages on your Pi
If you have some cleaned patches, that would be most welcome!

- Michael

I really have not made any tests of any of the other programs except axis, axis seemed to run fine previously though the software stegen has never been good on it and the graphical update seemed to be about 1 frame every 5 seconds.

I just tried your './configure --with-platform=raspberry -enable-simulator' suggestion and it compiled okay though there are a few compiler warnings, I ran axis and it seems to run same as before.

Now that is what I call an interesting result. Thanks for getting my branch to execute Axis; it really must be an installed package problem then on my side; thanks for the list.

Did you run axis on the local console or with a remote X display?

I will try doing a RT_PREMPT compile at the weekend or maybe tomorrow evening if I get time, and try and get some of the driver code to a dist stage.

Just make sury you do this in git, so you have history. We cannot make much use of binary blobs or tgz files without history. I would btw be very much interested in having a RT_PREEMPT kernel for the raspberry, really just to make measurements.

As far as the packages required, I loaded the most recent raspbian image available from the raspberry pi web site downloads section.

To update the required packages I used the following commands:

sudo apt-get update
sudo apt-get install gettext autoconf libpth-dev bc gcc g++ make git libncurses5-dev libxaw7-dev libreadline-dev tcl8.5-dev tk8.5-dev bwidget blt libgtk2.0-dev python-dev python-tk python-lxml libboost-python-dev libtk-img python-imaging-tk python-xlib python-configobj python-gnome2 python-glade2 python-numpy libgl1-mesa-swx11 libgl1-mesa-swx11-dev python-gtkglext1 python-opengl freeglut3 libglu1-mesa libglu1-mesa-dev

Hi all, just got my hands on a Pi yesterday and I have tried the following:

To get the code and packages
Then build

this gives me
and when I then try "make" I get a lot of these warnings:
the build stops att an error when compiling sim_rtapi_app.cc

any ideas?

thanks,
Anders

there is something wrong with either the branch, or the autogen/configure step

could you pastebin the top few lines of 'git log', as well as the src/configure?

- Michael

mhaberler wrote:

there is something wrong with either the branch, or the autogen/configure step
could you pastebin the top few lines of 'git log', as well as the src/configure?

When doing the debian install I installed "debian-desktop" also. This may have been a mistake since it is quite slow and not really suitable for web-kiosk or similar use. Does anyone know what lightweight X/desktop envirionment people use on the Pi?

It seems my Pi now has some problems because after the X login screen it seems the window-manager does not start. I just get a screen with the debian background-image and the mouse works - but nothing else. The machine is alive as there are text-consoles with ctrl-alt-F1 etc.

So I will probably have to do a re-install and report back after that...

Anyway my first impression of the Pi is that it is disappointingly slow for desktop use with debian-desktop Makes me want to use ITX/Atom boards for my projects instead.

awallin wrote:

mhaberler wrote:

there is something wrong with either the branch, or the autogen/configure step
could you pastebin the top few lines of 'git log', as well as the src/configure?

When doing the debian install I installed "debian-desktop" also. This may have been a mistake since it is quite slow and not really suitable for web-kiosk or similar use. Does anyone know what lightweight X/desktop envirionment people use on the Pi?

It seems my Pi now has some problems because after the X login screen it seems the window-manager does not start. I just get a screen with the debian background-image and the mouse works - but nothing else. The machine is alive as there are text-consoles with ctrl-alt-F1 etc.

So I will probably have to do a re-install and report back after that...

Anyway my first impression of the Pi is that it is disappointingly slow for desktop use with debian-desktop Makes me want to use ITX/Atom boards for my projects instead.

Try using the standard X installation that comes with the raspbian distribution it is about 5 times faster for X performance than the debian-desktop package!

Download from downloads.raspberrypi.org/images/raspbia...-wheezy-raspbian.zip

You can write it to SD card using win32diskimager on ms windows or dd if you are in linux

Also I would suggest not using the rpi if you can afford a decent ITX/Atom board, this is only a hack/experimental development at present and does not work correctly.

I compiled the rtos preview for RT_PREEMPT this morning and found that:

1) Will not compile for kernel threads option of ./configure
2) latency-test totally locks up the system when run for user threads rt-preempt compile
3) axis seem to run but shows missed deadlines and page faults.

So my question is what exactly is a realtime page fault and how can it be fixed?


I think rpi will become a usable system if there are enough talented people willing to work on fixing problems and finding work arounds, I am not sure if I have enough talent to fix it myself.

Unfortunately I also feel linuxcnc has a bias to x86 arch (In fact I get the feeling the project goals state it will only support x86), also the idea of creating lower cost hardware does not leave chance for large profits so does not encourage anyone to work on this as something supporting a business, and possibly pisses a lot of people off as it would put them out of business.

I would love it if there was an x86 based board that was available off the shelf for $35 and would run linuxcnc, and I would dump the rpi if there was, but I doubt this will happen in the forseeable future.

I am going to have a bit of a hack this weekend, but looking at my previous code and the problems I am having with the rtos preview is making me feel getting a system working is really a full time job, as I have a lot of work to do just getting back to the point I was at a couple of months ago as I have forgotten some of the changes I made to the previous codebase and I really am a newbie to RTOS.

I was looking at integrating an arduino over i2c to offload the stepgen, but dont really know what the best way to do this would be yet.

I hope to mess about with the rtos preview for at least 10 hours this weekend, so maybe will have a lot of questions to ask soon, or I will just give up and realise that that actually adding anything to the linuxcnc project is beyond me!

I would love it if there was an x86 based board that was available off the shelf for $35 and would run linuxcnc,

That is just it, you can buy a complete P4 ex corporate desktop for £19.99
www.ebay.co.uk/itm/Fujitsu-Computer-Pent...&hash=item3a7a543c5e

I have 3 of these and they return sub 10K latency.

Getting rtai and linuxcnc to run on a low power ARM board with restricted ports and no expansion slots is a fascinating academic exercise, but the practical use is probably only for specialist embedded systems / hobby robotics etc.

Anyone who wants to run a CNC machine, can just buy something like the computer above and have minimum hassle.

ArcEye wrote:

Getting rtai and linuxcnc to run on a low power ARM board with restricted ports and no expansion slots is a fascinating academic exercise, but the practical use is probably only for specialist embedded systems / hobby robotics etc.

Anyone who wants to run a CNC machine, can just buy something like the computer above and have minimum hassle.

I'm not so sure about the academic aspect. You might overlook a large potential community out there, the reprap folks, which will eventually graduate from their arduinos once they hit the problems which are already addressed in LinuxCNC. And some of the hardware out there has features which will likely blow away everything PC's can generate in terms in stepping frequency and precision - just see what Bas has done. But it is unrealistic to entice them into using LinuxCNC with the current hardware/architecture/RT OS lock-in.

Relying on junk sales PC hardware and an RT OS base of questionable future is a strategy bound for failure for the LinuxCNC project per se, even if it is a reliable solution for you right now.

I would also think the separation of LinuxCNC into a hard-RT part and a non-RT UI part is a necessary step; the current architecture can go only so long before the build base rots away completely, and we are pretty far down that alley - Ubuntu 10.04 LTS has 5 months to go before the 'LTS' is removed and we're dabbling with a Linux equivalent of Windows XP, and no sequel RTAI kernel in sight. Some rely on hope; that isnt a sound strategy.


- Michael

mungkie wrote:

I compiled the rtos preview for RT_PREEMPT this morning and found that:

1) Will not compile for kernel threads option of ./configure

I never said this is anything implemented or supported, but if you give an _exact_ command and log we might be able to help. What were you trying to do?

So far I do not even know which platform you are using - if you want to contribute, please send a realistic error report to the developers list. It is very unlikely you find developers in this forum.

2) latency-test totally locks up the system when run for user threads rt-preempt compile
3) axis seem to run but shows missed deadlines and page faults.

So my question is what exactly is a realtime page fault and how can it be fixed?

A page fault in a realtime thread.

- Michael

I think rpi will become a usable system if there are enough talented people willing to work on fixing problems and finding work arounds, I am not sure if I have enough talent to fix it myself.

Unfortunately I also feel linuxcnc has a bias to x86 arch (In fact I get the feeling the project goals state it will only support x86), also the idea of creating lower cost hardware does not leave chance for large profits so does not encourage anyone to work on this as something supporting a business, and possibly pisses a lot of people off as it would put them out of business.

I would love it if there was an x86 based board that was available off the shelf for $35 and would run linuxcnc, and I would dump the rpi if there was, but I doubt this will happen in the forseeable future.

I am going to have a bit of a hack this weekend, but looking at my previous code and the problems I am having with the rtos preview is making me feel getting a system working is really a full time job, as I have a lot of work to do just getting back to the point I was at a couple of months ago as I have forgotten some of the changes I made to the previous codebase and I really am a newbie to RTOS.

I was looking at integrating an arduino over i2c to offload the stepgen, but dont really know what the best way to do this would be yet.

I hope to mess about with the rtos preview for at least 10 hours this weekend, so maybe will have a lot of questions to ask soon, or I will just give up and realise that that actually adding anything to the linuxcnc project is beyond me!

The crux or issue I am at(others?) is that my old P4 is dying, and I'd rather not have another old salvaged computer that is relatively inefficeint compared to what we have now. So right now things work, but when things finally croak should I shell $150 on an atom board, or get another piece of junk.... (I even considered a smooth stepper for a minute :LOL: )
I don't particularily want anything but a solid controller, having a working self contained unit that is specifcally used for one thing seems key. (I'm almost from a consumers prespective willing to say people would "pay" / donate / kickstarter??? for a port)
I also agree and see that the 3d printer crowd's arduinos will only get them so far, perhaps drawing them here for development purposes would help?