EMC2 running on Raspberry Pi?

mungkie wrote:

....
I have spent a lot of time and money messing with this, and sort of feel a bit possesive especially as some people will probably make money from this and everyone hopefully will save money by its use.

We all do. Some more, some less. Some considerably more than you have. So please see it in context.

I am a bit fuzzy what the funds are to pay for. If it is for your time - good luck with the effort; I have some doubts this is a fruitful avenue. You are addressing a very small market indeed.

If it is for code proper, you better research the license context of your work very thoroughly. There might be some minefields you want to think about twice before crossing. The policies set forth by the FSF you suggest donating to might not be particularly helpful here.

If you want to make money of that, I think the best route would be to find somebody/some company willing to integrate this into a product. There might be some consulting revenue to be made.

Note that the Raspberry - besides all the hype - is not exactly what a company worth its powder would bet on - that product is positioned as an educational tool, and for good reasons - you might also read this as "think twice before betting the farm on this". I dont want to sound overly negative, but in summary I think the Raspberry is a fringe platform for this kind of application. This has been discussed at length on the developer list.

Be aware that your contribution (if you mean the HAL driver) is just a small piece of an overall effort. Also, you might be a tad early thinking about fundraising - get it to have some exposure first, like moving some real machines of several people. Asking money too early for a something which isnt a marketable product yet is a surefire way of killing it, and there are some examples even in this community.

If you want to contribute the code to the LinuxCNC project, that would be most welcome, and I am happy to help at merging it once it is mature enough.

- Michael

Quick update, I got mungkie's code to drive a rpi to run my 3 axis CNC router. I have a brief movie of likely poor quality I'll try and get uploaded and linked to tomorrow. I'm really guessing at how to tune the scaling, etc. I may take what I have kind of working and look at it on a scope. Anyway it can run a 3 axis machine, and I think it will be able to do so somewhat smoothly. Good stuff.

Pete

can I encourage you folks to polish up this work, and prepare a patch for LinuxCNC ?

suggested shopping list:

- a README which could serve as a manual fragment
- man page(s) for component(s)
- a working configuration
- build notes if required

- Michael

Hi, I'm just waiting on some stuff for my raspberry pi (HDMI-> VGA adapter, keyboard, etc.) which should be here tomorrow. After verifying that the Rpi does work under raspian with my setup I'm going to give mungkie's code a try. Hopefully I'll be back on here with a success story in the next few days, then I might have a look at doing some documentation.

Cheers,
Rex

mhaberler wrote:

can I encourage you folks to polish up this work, and prepare a patch for LinuxCNC ?

suggested shopping list:

- a README which could serve as a manual fragment
- man page(s) for component(s)
- a working configuration
- build notes if required

- Michael

Michael,

I'm happy to help with whatever I can. As far as I can tell the source for the rpi driver is not in the image, so it's a blob at this point. We can make a cleaned up image, and document config settings etc to work with it but that will limit it's use to the rpi. I'd love to be able to extend LinuxCNC to ARM more broadly. There are numerous Allwinner A10 boards, out and Freescale and Samsung ARM boards that have more horsepower and options, but I don't think the DMA code would work directly with these other boards. These boards also tend to have different GPUs, like the Mali, which may be better or worse for LinuxCNC.

In the bigger picture, we need to see what Mungkie wants to do.

The video is here. Be kind it was after midnight and I'd spent about 7 hours working on getting it running, the machine is running rougher than it does with it's normal control as it needs more tuning. Also I didn't pull some sheet metal dust control pieces that rattle badly, sorry about that, I'll try again this weekend before I put the machine back together.

Try this, for the video, it didn't want to embed the link.
LinuxCNC on rpi - Youtube

great to see metal moving!

well I hope I didnt discourage Mungkie too much with my sobering words.. that was not my intent.

That said: no binary contributions & no exceptions.

- Michael

OK,

I think I may be at the end of what I can accomplish. I pulled the configuration bits from my x86 based setup for this machine, added them to the rpi configs and nothing changes. It is quite possible I'm misunderstanding configuration options in particular, or LinuxCNC in general, but what I observed with the CW250 drivers is that they need a long steplen and dirhold. I have them set to 22500 in my x86 Config. When I use these values in the rpi config, nothing seems to change. I looked at the values in the Hal Configuration -> rpi_stepgen -> [AXIS] -> dirhold and steplen with the stock and then my updated hal file variables and they remain at 60000.

Is this the right place to look? I'm assuming these values should change? I can post my config files in anyone wants to look. I see the same references to steplen and dirhold in the stepgen.so and rpi_stepgen.so when I run strings on them. I don't see a rpi_stepgen.c file at all so I can't look there. If anyone has ideas of things to try or test, I'm willing to try, but will need to get my machine back together and running under the x86 control pretty soon.

Thanks

Pete

I got some good advice from Andy, and spent another day playing with the RPi code. I learned a lot more about hal, and believe that the driver still has hard coded values, that are messing with my attempts to get it working correctly with my drivers. I think the driver could work OK, but it's too hard to work with given it's current behavior, and the inability to verify what's happening by looking at the code.

Pete

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