EMC2 running on Raspberry Pi?

mungkie wrote: 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)

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).

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'.

It is a userspace module, so it gets loaded and just runs through a polling loop when the OS gives it some CPU, just like any other software, and the GUIs.
You can see it listed among the other userspace modules near the bottom of this page:
www.linuxcnc.org/docs/html/

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: 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??.

F-errors are produced if the feedback from the stepgen (where it reports it has got to) doesn't match the commanded position within a tolerance.
The only way that this can happen in a conventional stepgen system is if the base thread is too slow to create the number of pulses required, or if the requested accelleration is higher than the stepgen accelleration. Why does stepgen have accel limits? I have no idea, but I think the idea is that you can use it standalone, unconnected to the motion planner. ie, you could simply setp stepgen.0.position 50 and the stepper would go there, at max programmed accel and velocity.

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?????.

That does seem to be all that it does, yes. update_frequency computes the required step frequency for the next servo thread. update_pos seems pointless, largely.

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

PWMgen does, debounce can. Charge_pump, freqgen. I think serport can, clearly the parallel port driver has to, otherwise there is no point the stepgen being there.
Lots of HAL components _can_ run in the base thread. Typically only a few do.

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 don't know anything at all about RT_PREEMPT, but if it keeps the servo-thread part of your code "realtime enough" that it always gets called in time to fill the buffer, and if the buffer is toggled out by hardware, then I don't see any problems with your approach. The second "If" is the big one, is the buffer transfer to the pins running in something deterministic?
I am assuming here that my guess about how your code works is true. My impression is that you fill a buffer with 0s and 1s, and then some subsystem close to the hardware level toggles those bits out to hardware pins on a fixed clock. This is very similar to the way that Mesa and Pico hardware works, and also pretty close to the Smoothstepper idea in Mach3 land.

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.

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?