EMC2 running on Raspberry Pi?

Okay if you sure there are no glitches then I suppose I should continue, and I almost feel hopeful that linuxcnc could soon work very nicely on the rpi (I am also pissed off as I just spent out £25 on pic devel parts to make an offboard controller).

I think should be possible to fix the update_pos function to give correct position so there are no joint follow errors.

Rough outline of maths, the step pattern buffer must be 4000us and the pulse width can be anything down to 1us but there could be large memory requirements as each step requires 168bytes (1us steps would be 4000*168bytes of DMA buffer)

There is probably something that I am not seeing and this will be another fail, but I am guessing I could have the driver finished for testing with an evenings coding so long as I don't get brain overload and start writing nonsense.

Just in case I am missing something I suppose I should ask if anyone knows of any hidden signals that are not listed in the .hal config that secretly connect into tasks that my effect functions in base-thread or servo-thread, I say as an example 'iocontrol.0.user-enable-out iocontrol.0.emc-enable-in' which are used in .hal file but 'iocontrol' do not seem to have an addf hook also same with 'axis'.

I am really a newbie to the linuxcnc internals so if anyone with low level knowledge can offer advice, especially if I am wrong that would be helpful, otherwise I suppose I will just hack on with what I am doing.

Hi

Just in case I am missing something I suppose I should ask if anyone knows of any hidden signals that are not listed in the .hal config that secretly connect into tasks that my effect functions in base-thread or servo-thread, I say as an example 'iocontrol.0.user-enable-out iocontrol.0.emc-enable-in' which are used in .hal file but 'iocontrol' do not seem to have an addf hook also same with 'axis'.

The implementation of some of the startup stuff is hidden from the user config, even though it uses the .ini file.

Have a look at the linuxcnc script in /usr/bin

In section 4 it makes various halcmd calls, which amongst other things load iocontrol and halui based upon .ini file settings.
(they are both actually userspace modules)

You then need to look at the code for halcmd too, to get the two pass loading of all the hal modules listed in the HALFILE entries of the .ini file,

regards

andypugh wrote:

I need to look at your code, but it seems to me that there could be some savings to be made here. I think that 1uS steps are faster than necessary, though I am not sure if you are trying to compete with FPGA step rates or software step rates. A 10uS clock (10uS on, 10uS off on the step pin) gives you 1000rpm at 16x microstepping.
The approach of filling a buffer with steps (basically pre-computing a base thread) allows you to dither the rate, so you may get some smoothness benefit over a typical base-thread stepgen. (note, I am not sure that the LinuxCNC stepgen doesn't already do this).

The code I posted for you to test actually uses 20us pwm clock but it delays twice for each sample in the DMA control block code so each step is 40us (in theory), after looking at this last night I realised its probably wrong to delay twice but may not be depending on how long it takes stepper drivers to respond. The test code only allocates 200 steps of buffer.

The maths was for theoretical maximum step speed, I really imagine that 100kHz is going to be standard for the driver.

There is still a lot of brain dead code in the DMA control block instructions of the test example I posted, a final driver really needs some way to config how the DMA control block loop is setup so that polarity and rise times could be changed (probably not something I would need myself so I doubt I would do that code). I am hoping that the integration of the stepgen with the hardware driver should also cut down quite a bit on context switches so linuxcnc should run quite a lot better than previous attempts I have made.

The linuxcnc driver will probably be very similar to the test code but there are extra position flag blocks that need to be added to the DMA instructions, so that 'static void update_pos(void *arg, long period)' knows where the step position is. I need to workout if I can do some shared memory pointer indirection to stepgen->accum or maybe just copy the value into stepgen->accum when the function is called??

I still not totally sure if I understand how stepgen works yet, its still a case of hack the code and see what happens.

I think things look pretty promsing thought.

I am even considering the possibility of releasing an SD image of the system with RT_PREEMPT kernel (I am sure something will go wrong or I will discover some obvious mistake I have made to stop this happening thought)

Only thing that needs to be done to make linuxcnc run really well is for someone to make a wrapper library to allow python opengl use the rpi openGLES GPU.

Ooooh dear, it always the case that things are more complicated than I assume, I wrote the driver the day before yesterday and had some problems so did not bother trying to code anymore yesterday I decided just having a think about things without actually concentrating on them may help.

I have had a few thought and have some questions which are probably stupid but I will try to explain and them ask what I think maybe problems

I load the driver in axis and get joint follow errors ( I had assumed this was because update_pos was giving incorrect position values), after a little playing with the .hal and .ini files I find that changing FERROR and FERROR_MIN has no effect, eventually I find that the problem is that base-thread period is too high (I set it to the same as servo thread to reduce system load), it seems follow errors are only flagged if the base-thread is too long to generate enough pulses??.

So I now wonder what is the update_pos function in stepgen used for (I assumed it gave position feeback to hal so that follow errors did not occur even though steppers are open loop), is this correct?????.

Next I wonder what other functions run in base-thread I assumed that almost everything ran in servo-thread except stepgen???

Also I wonder what Arc eyes cryptic mention of checking the halcmd code meant??

And then a thought hit me that my request for testing of the code I posted on the forum could well be stupid as I am running it on RT_PREEMPT in X windows which could well totally change the performance and any conflicting interupts or DMA usage (I have no idea is DMA channels are locked from other processes interupting them etc...). The only way for someone to check the system works is runnign as it will be in final production system. So I will have to make a full distro if I want anyone to make tests with DSO or other equipment.

I am starting to worry that this could be another dead end or at least a lot harder than first thought.

So I think I need some more info on how the system works, am I understanding things correctly?

I am really a newbie as far as linuxcnc development, are there any easy to understand idiots guide type docs for how the whole linuxcnc system works together???

If there is nothing else that uses base-thread other than stegen then I probably will continue.

Running the rt_preempt cyclictest for the rt_preempt kernel I have gives max period of 60us (while running X), which I think maybe a lot better than results I vaguely remember getting from the linuxcnc latency test some months ago (I should check back in this thread to see what I posted but I think I did not quote the correct figures anyway)

If I hack together a linuxcnc distro can anyone try it and give some test results feedback ideally with calibrated equipment.

Hope this is not too disordered, I apologise if I am talking nonsense I could be having a bad day and not realise it, maybe next time I look at the code it may work better.

mungkie wrote:

If I hack together a linuxcnc distro can anyone try it and give some test results feedback ideally with calibrated equipment.

Hope this is not too disordered, I apologise if I am talking nonsense I could be having a bad day and not realise it, maybe next time I look at the code it may work better.

Absolutely, more than happy to test it, I've got controllers and motors waiting to CNC a mill I'm working on, I can barrow a rpi from my son, and I think we have a fast enough scope to check the output at our maker space, don't think it's a storage scope though.

I'm looking at an All Winner A10 based board sooner or later too, so I might be able to provide feedback on how it works on a faster ARM setup. Thanks so much for putting so much effort into this.

Pete

andypugh wrote:

mungkie wrote:

I am really a newbie as far as linuxcnc development, are there any easy to understand idiots guide type docs for how the whole linuxcnc system works together???

I am not sue that there are even any docs like that for brainiacs. Have you seen www.linuxcnc.org/docs/EMC2_Developer_Manual.pdf ?

If there is nothing else that uses base-thread other than stegen then I probably will continue.

As I said earlier, lots of things _can_ run in the base thread, but few need to.

If I hack together a linuxcnc distro can anyone try it and give some test results feedback ideally with calibrated equipment.

If it is an SD card image, then I can do that easily.

I sort of checked the developer docs a while back, seemed only the first few pages could have been relevant as most of it is just a list of commands, I don;t think there was any mention of base-thread only traj rate and servo rate, also seemed that naming may have been inconsistent between hal names and source code function names(I only skimmed things so could well be wrong).

I suppose idiots guide for a complex development project is an oxymoron what I should have said was a concise and simple overview, and I know development documentation is very hard, most things seem obvious to the people that wrote the code, writing can either be too indepth and it becomes almost as easy for the reader to just check the source code or so brief that a good overview is not given.

Anyways I am too lazy to spend the time to fully understand everything, I am definitly not a brainiac otherwise I would have understood the system and created a working driver when I first attempted it, I have never worked on any large software project before, so maybe expecting more documentation than is usual.

I hope I should not need further docs, most stuff I do works eventually with enough hacking and trial and error

As far as SD card image, I was hoping I could hack something out today, but it seems mirrordirector.raspbian.org is not online so I cannot update and package up a system until I can access it.

I also could do with some advice about creating some G code tests that will show up missed steps on a DSO (maybe milling very small zig zags or something similar), I don't know what the typical storage capacity of a DSO is and how it would be setup and what to look for on the test results?

I probably should not be saying this yet as I have not hooked up any motors and the scope does not work correctly, but I am guessing maybe I will post a SD image at the weekend.

I have spent a few hours every night this week trying to sort out the raspbian packaging system and the package dependency problems are a nightmare for creating a slim distro. I think I have got most of the image sorted and it should pack to under 350Mb and fit on a 2Gb SD (but there is still huge amounts of unecessary cruft on the system).

The very basic tests show no missed deadlines in RT execution when running axis with a 1ms servo loop (20us DMA virtual base-thread), axis seems a lot snappier with sub second response times (I assume most of this is slowness is due to software based mesa opengl rendering, which could be removed if a OGLES wrapper is created).

The stepgen code ended up requiring a total refactoring and I am not sure about releasing all the code yet as it still requires tiding up and a lot of hardcoded parameters changed to allow configuration via hal.

The only thing required is some testing with motors which I will do over the weekend (I am relying on my cheap chinese stepper board (TB6560) working with the pi 3.3v logic (5v ttl should read 3.3v as high unless there are unusual problems).

If the motors drive okay over the weekend then I will release the SD image, but I have been thinking about what should be done about source release and not sure what to do.

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.

I have released opensource software before and have never made any money or expected to, as I feel so many other people have added to opensource and not been paid it seems unreasonable to expect payment. Unfortunately there are people making money that do not seem to contribute so much and I am having a very hard time finding money for many of my projects. So I am wondering if maybe starting a kickstarter to raise something for the final development of the drivers would be a good idea, I would not want to start the kickstarter until I am sure everything will definitely work as I do not want to promise something I cannot deliver.

I was thinking of doing a kickstarter along the lines of $10,000 goal with donations going to what I feel are worthy causes :
5% going to the FSF,
30% for the raspberry pi foundation,
20% for linuxcnc (I have never seen any mention of donations on the linuxcnc website and am not sure how any money could be used, maybe could be used as prize bounty for further development?)
All remainder raised will go to my favourite charity (Althought I would probably rather have stuff that I need rather than money)

What do other people think, would linuxcnc be able to put any donations to good use, is trying to raise money from my work unreasonable, would 5000 people donate $2 to a kickstarter???????.

Maybe this is still pie in the sky as there is still possibility that the system will not work correctly?

Well I think there maybe a distribution available, I uploaded it last night, then downloaded it and tested, but unfortunately it does not seem to work

I will try and find out what went wrong, maybe an SD card fault or maybe I did something else wrong, the image was working okay on the original card, but I dd'd zeros to all the free space to reduce the compressed size (270Mb), dunno if this has broken things.

The test I did over the weekend "seemed" to drive steppers really nicely (i.e. smooth motion but I did not make any timing or lost step tests) and no faults with real time.

When I tried the download image it gave realtime missed schedule errors and pagefaults and took ages to load up axis (I waited 10 minutes then powered down the system as axis seemed almost locked up).

I was hopeing to make the release announcement last night, but did not due to the errors.

I may be able to fix it tonight, it should be a quick fix as I think its just a data corruption problem(I really should workout how to use md5 ), if anyone wants to try the image check out the very rough quick web page I have setup:

soundproofingforum.co.uk/rpi_linuxcnc/raspberrypilinuxcnc.htm

Probably better people not waste time downloading it (it will take about 1.5hours to compile), but incase anyone wants to make sure I have not just got a bad SD card then download and test then send me some feedback, otherwise I will check the problems tonight and upload another image when I find out what is going wrong.