EMC2 running on Raspberry Pi?

I had a play around with rockhopper yesterday. On the Pi I can get the webpage up but can't start Linuxcnc. I can get it to work fully on my laptop with Linuxcnc in simulator mode. My thoughts as to what's stopping rockhopper in the Pi are as follows:
1. Linuxcnc won't start because of a lack of x11 server locally.(I'm sshing into the Pi as I have no monitor near my CRO)
2. Linuxcnc won't start because of some problem in the configuration not letting it be run normally(I think there is some thing with it being set up to be run in place not installed which could be a problem due to a lack of /usr/bin/linuxcnc or similar)

I'm going to have a look at option 2 today, and possibly see if I can set up Linuxcnc to use a lighter weight UI then axis.

Cheers,
Rex

Ok I can confirm that Rockhopper does work and can control Linuxcnc on the Pi, because we are just running in place I have added /home/pi/emc-dev-8b9ff03/bin and /home/pi/emc-dev-8b9ff03/scripts to my PATH variable.

rexhunt wrote:

Just to throw my hat into the ring... I can get mungkie's image to boot and load axis.

Just wondering about the possibilities of having a 2 stage setup? Use a Rpi to drive the motors and ssh into it with a non-realtime device to drive the UI?

Cheers,
Rex

emc2web works fine on RPi.

I'm currently using tkmini over rdesktop. It is useable provided you don't enable backplotting.

Axis can also be used as long as you disable live plot.

Cheers!

emc2web works fine on RPi.

Do you have a link? I can't seem to find it with google.

Axis can also be used as long as you disable live plot.

How do you disable that? Is it simething in the .ini file?

rexhunt wrote:

Do you have a link? I can't seem to find it with google.

See here: www.raspberrypi.org/phpBB3/viewtopic.php?p=354382#p354382

How do you disable that? Is it simething in the .ini file?

It's under the "view" menu, play with all the "show ..." entries.

PS. Sorry it's emcweb and not emc2web

I have not done anything with the raspberry pi for a while as I cannot really see a usable system being attainable for quite a while yet as the rpi still needs some infrastructure that will improve performance.

I have all sorts of thoughts but don't really know if any are useful or if others would want to work on them, unfortunatly I am too busy and too disorganised to get much done, and only just realised that Michael Haberler had sent me an email months ago with git repo details to upload my work.

I think my current driver works in most circumstances, but it is not totally deterministic and it is possible for the dma buffers to get out of sync with the real time servo loop in some circumstances, although I partially implemented flagging of when the dma was running out steps, i have not implemented anything to automatically increase the number of steps written by the servo loop stepgen.

My main aim is to get a decent gui cnc system working on the rpi, I know linuxcnc runs okay headless but I would like the cheap gui working if its possible.

As the axis system works very poorly on the rpi I am waiting for other things to happen, maybe wayland/weston and gtk/glade on weston will be implemented, or maybe a fast cross platform python gles system will be created. There are also load of other considerations that maybe need to be addressed with the kernel and locking dma, and interupts and other stuff, and the RT_PREEMPT patches are apparently quite a hack job still.

I was considering rewriting a gui in python with gles widgets avoiding a need to gtk or other dependencies that can slow things down, but think maybe that is too much work. Also I was thinking about some sort of direct control and path creation from a 3d model rather than gcode, using opengl clipping planes to calculate tool paths and access. All stuff way beyond what I have time to do and probably also beyond skill level, so I was just wasting time.

Anyways as regards licences of my code all the stuff I have published is GPL unless otherwise stated. And if/when I get around to writting a full hal rpi dma io driver I will release it as GPL, but I doubt I will get around to doing much more anytime soon until other parts of the system are working better or unless someone pays me to do it.

Sorry if other people are waiting for a decent linuxcnc system on the rpi, but I think there is not much point my hacking on it anymore until other parts of the system are working better, I may have another look at things once xwayland is working on the rpi.

andypugh wrote:

mungkie wrote:

As the axis system works very poorly on the rpi

There are several other GUIs available,..
... maybe even Gscreen are probably worth a try too.

Gscreen as-is is a bit aggressive using the gtk idle polling mechanism to update status, so it might look it uses a bit much CPU

however, this is relatively easy to fix in gscreen proper
second, downstream (like end of year) we will have the NML middleware stack replaced by a messaging stack which will not rely on polling the way NML does

meaning: tweak it a bit for now, things will get better ontop

- Michael

I am starting to pick things up again with linuxcnc on the rpi and am wondering what has happened with the linuxcnc source tree and general development.

Which git branch should I grab?
What is happening with the universal RTOS thing?
How should I post my dma based stepgen driver?
Does anyone have overview or suggestions about what/how/when to make some contributions?

I have spent last weekend making a vmware devel image with ubuntu 12 and basics for creating rpi kernels, I compiled 3.8.y kernel with xenomai and with RT_PREEMPT and also put on my previous 3.2.27 kernel with RT_PREEMPT.

Not really got much further until last night I actually tried a few tests on the xenomai kernel (first time I ever used xenomai on rpi), I found the userspace stuff did not compile and there were lots of problems with usb keyboard (lots missed and stuck key presses), dunno if I made a mistake with the patching?.

I was hoping the rpi infrastructure would be a lot more mature by now, but RT kernel patching is still problematic.

Anyone else looking at the rpi still, have any advice about realtime kernels?