CNC Interface Board discussion

bwelsby  wrote:

 

This is something I was wondering too, if there is a large enough buffer between "linux" and the pru then there shouldn't be a problem.

There's not that much data that needs to be shared.

Per stepper motor and per movement command:

• Direction (1 bit),
• number of steps,
• requested speed (steps per second)
• start speed (steps per second),
• acceleration.

Other movements in a CNC (spindle motor, ?) don't seem to be that time critical. They could be managed from Linux.

If you work with a predefined acceleration profile and speed, you could either program that fixed in the PRU or set it once before the first step command is given. In that case it would only be dir and steps.

Things like end switches and fault/stall detection are hardware signals and could directly be handled by the PRU.

Hi!

I'm guessing (not sure) that as soon as any curve is cut, the Linux process is sending lots of events to the PRU, to change directions, until the curve is complete. Or maybe it pushes many trajectories into PRU-accessible memory like a list instead, and then the PRU then handles them sequentially, but the implemented code might not be that clever - not sure. I will scrutinize the code, to understand what amounts of work are done with the PRU.

With a manual machine, I only make linear movements, but if I do not control the feed to be smooth, then I see ripples in the edge (since the tool heats the edge unevenly). I've no grasp though of the effect of several msec of jitter where (maybe?) hundreds of modifications may be made to the direction and speed, in order to cut curves (if these really are individual events to the PRU instead of written to PRU-accessible memory area as a list.

And at some point it will be good seeing the real-world difference in cutting/engraving, using these different configurations.

The several msec of jitter is reduced to 0.4msec of jitter with PREEMPT RT from initial observation, but I've yet to try Xenomai (I installed it, but it didn't work, because I have to add a certain flag in one of the commands during install.. the instructions on two BBB websites both appear incorrect).

Finally got Xenomai installed on the BBB, and the difference is impressive.

There is a 'cyclictest' which prints min, avg and max latency, and the output is 8-10 limes lower for the max latency (compared to PREEMPT RT), maybe about 10 times less jitter.

(example output after running cyclictest -n -p 90 -i 1000 for about a minute.. values are in usec).

T: 0 ( 2914) P:90 I:1000 C:  31719 Min:      6 Act:   19 Avg:   18 Max:      51

I still need to learn how to write code that can take advantage of that, to understand Machinekit better.

Just for comparison, an x86 box running a Linux VM (I have no x86 Linux without a hypervisor to compare with) with no real-time kernel mods, outputs this:

T: 0 (30152) P:90 I:1000 C:  71563 Min:      3 Act:    7 Avg:   42 Max:    1923

In other words, compared with the BBB, the average is higher, and the max is much higher.

That 1923 max value was about 580, until I opened another shell using an SSH client. Then it shot to 1923.

With the BBB test above, if I do that, it does not increase the max value.

EDIT: Reading some more, it appears Xenomai has several APIs available to your source code, so you can choose one and realtime-ize your software with it.

For instance one API is POSIX-like, another is basic RTOS-like, and so on.

Not all the APIs seem to be enabled in the pre-built Xenomai kernel I'm using (I will investigate why), but anyway, I was able to find an API that worked, called Alchemy. Using that API, I've created some simple C code to toggle an LED. I'll connect up with a 'scope and see what jitter there is.. I'll write it all up as soon as I've made some progress.

Here's a 'scope trace of an example toggle program written to use Xenomi's Alchemy API (since that was an API supported by the kernel I was using). The exact frequency of toggling is unimportant (pulse width is about 63 usec), but the stats at the bottom of the display show the min and max pulse width over a period of several minutes of capture. The delta (66.34 usec minus 60.76 usec) is less than 6 usec, i.e. really low jitter for a Linux userspace app.

Running stress -c 2 -t 5 increased the pulse width jitter to a total of just under 10 usec overall. It's all just a basic test.

I'm fairly happy with this for now, so I'll go ahead and install Machinekit.

I saw that you got an answer on the mail list from the Linux builds hero ...

I have virtually no experience with running CNC, 3D printers and laser cutters. Looking for info on how they combine axis movements.

Do the stepper motors ever run truly real-time at the same time?

What is the sequence (commands generated) when  a 90° movement is made?

Yes. Steppers are often changing speed independently. Imagine moving in a circle. The X stepper will be receiving pulses at a frequency which plotted would form a sine curve. At the same time the Y stepper pulse frequency would form a cosine.

Things get more complicated when you start considering limiting acceleration. Moving in an L shape would in theory be a fixed stream of pulses on X followed by a similar stream of pulses on Y. In practice this would attempt to turn a very sharp corner at speed. You might get away with this for a 3D printer or a laser, but a heavy spindle would give you a very large clunk, the whole machine would vibrate and you might even miss steps. Should you round the corner slightly? Should you slow but turn sharply? A bit of both? Slowing might work for a mill, but what about a laser which will burn more material if moved more slowly. You get the idea. It starts simple but soon gets complicated.

Hi Jan,

I've only used manual mills, (I've not used a CNC machine, and only used a 3D printer once : (

so I am familiar with the tool motions, but not how a machine would do it - I have to design for easier manual manufacture basically,

so I'll deliberately use (say) large slot mills or a cutter whereas a CNC may rather use a small milling bit and a tool path for a circle. The algorithms are different : )

The easiest way could be to use Fusion 360, to generate some tool pattern, and then it can be examined.

Basically, in Fusion 360, create a 3D object (e.g. a rectangular block since you want to analyse a 90 degree movement), and then click where it says "MODEL" and in the drop-down select "MANUFACTURE" instead. The screenshot below shows the highlighted areas to work in.

Select 2D drop-down, and click on 2D Contour. Click the Tool "Select.." on the right, and pick a tool (e.g. 3mm end mill, it doesn't matter). Then, select a face on the model. Now click on OK at the bottom-right (easy to forget). Click Setup and in the drop-down,  select Create NC Program. The defaults are fine, so make a note of the folder and click OK. Then, right-click on the NCProgram created in the browser on the left, and you can click on Simulate if you want to see the motion (some playback buttons appear bottom-center for playing the motion). Click Close in the Simulate box on the right afterwards.

Once you're happy, right-click on the NCProgram again, and this time select Post Process. After a while, you'll see a notification fade in/out of view in the bottom-right of the display. This means the file is generated in the folder noted earlier.

Below is what the generated file looks like, for the face indicated in the screenshot above. But it won't make much sense without looking at the simulation in Fusion 360. If you click on the Info tab in the Simulate box that appears on the right side when doing the simulation as described above, then you'll see the XYZ co-ordinates displayed. You can then correlate them with the XYZ values in the output file (in G Code described here).

(1001)
(T1  D=3 CR=0 - ZMIN=-1 - flat end mill)
N10 G90
N15 G17
N20 G21
(2D Contour1)
N25 M9
N30 T1 M6
N35 S10000 M3
N40 M8
N45 G0 X-7.8 Y4.9
N50 Z15
N55 Z5
N60 G1 Z1 F30
N65 Z-0.7
N70 Y4.892
N75 Z-0.767
N80 Y4.87
N85 Z-0.83
N90 Y4.835
N95 Z-0.887
N100 Y4.787
N105 Z-0.935
N110 Y4.73
N115 Z-0.97
N120 Y4.667
N125 Z-0.992
N130 Y4.6
N135 Z-1
N140 Y4.3 F900
N145 G17 G3 X-7.5 Y4 I0.3 J0
N150 G1 X7.5
N155 G2 X9 Y2.5 I0 J-1.5
N160 G1 Y-2.5
N165 G2 X7.5 Y-4 I-1.5 J0
N170 G1 X-7.5
N175 G2 X-9 Y-2.5 I0 J1.5
N180 G1 Y2.5
N185 G2 X-7.5 Y4 I1.5 J0
N190 G3 X-7.2 Y4.3 I0 J0.3
N195 G1 Y4.6
N200 Y4.667
N205 Z-0.992
N210 Y4.73
N215 Z-0.97
N220 Y4.787
N225 Z-0.935
N230 Y4.835
N235 Z-0.887
N240 Y4.87
N245 Z-0.83
N250 Y4.892
N255 Z-0.767
N260 Y4.9
N265 Z-0.7
N270 G0 Z15
N275 M9
N280 M2

Fred27  wrote:

 

... It starts simple but soon gets complicated.

Yes, I lost an important part of the skills needed - over time, because not needed in my string of jobs - my math and geometry skill (decent at school time) virtually evaporated.

I can control a stepper motor, acceleration and deceleration, and torque.

I also think that, if I don't have to create a smooth path and just run steppers at a constant speed, I'd be able to calculate a path for X and Y to run simultaneously.

Doing that with taking in account acceleration of both axises (axes?) interfering with each other is beyond the number of active brain cells left .

For some reasons, I've vastly improved my analysis skills since leaving school, but at the cost of math.

I tried to bump it op again  by following MOOC calculus training, but to no avail.

For some odd reasons, other courses go perfectly fine. I can pass some exams with two fingers in my nose and one hand tied behind my back. But not math and calculus.