35 Replies Latest reply on Aug 18, 2019 6:25 AM by shabaz

    CNC Interface Board discussion

    shabaz

      This is a thread to discuss ideas for controlling low-cost hardware (machines), for the purposes of cutting or engraving for example. It was created due to the interest in ralphjy project to assemble such a device.

      There are several ways to do this, typically the 'brains' are a normal desktop or laptop PC, or a single board computer (SBC), and then there is some interface board, that then ultimately connects via high-power drivers, to the motors. There are some other bits of functionality too, like feedback (e.g. limit switches) for detecting end stops.

       

      In terms of motors, in industry servomotors will be used, but for home use stepper motors are a lot more popular due to lower cost. For controlling the tool, a 'spindle motor' may be a brushless motor, or alternatively a brushed permanent magnet DC motor (i.e. BLDC or PMDC motor respectively).

       

      The PC connection to the interface board can typically be a parallel interface, or USB. When using a SBC then its on-board general-purpose input/output (GPIO) can be used.

       

      The BeagleBone Black (BBB) is worth considering I think, since it has been the first popular Linux product to be integrated into machines, providing functionality for 3D printers and small CNC machines. Commercial manufacturing products have been launched with the BeagleBone inside, such as the PocketCNC. There are also third party add-on boards that act as interface boards (and some that integrate motor drivers too). The BBB is old now, but there is a BeagleBone-AI that could in future be used as an upgrade.

       

      Partly the reason the BBB has been useful is because it contains some programmable real-time units (PRU) internally, and they can override some GPIO pins, for direct control without needing to go through the Linux system. So, the Linux system can push code to execute on the PRU, and the PRU will control the pins. This means high speeds, and no unexpected delays or jitter, since the PRUs are simpler devices that do not run an operating system that could have a task preempted.

       

      To control the interface cards, PCs have a wider choice of software, and popular choices are Mach 3 and LinuxCNC. For the BBB, the software all the boards seem to use is called Machinekit, which is a fork of LinuxCNC.

       

      Using it for BBB is not documented well unfortunately. When I first started looking a while back, it was hard to tell which information works, and which information is old. I wanted to automate a simple XY table I'd bought.

      However, there is a fairly recent blog article with useful pointers.  It too discusses that information is spread out.

       

      It would be nice to develop hardware (or to at least consider it first), and any software or configurations, documented, that would allow low-cost control of machines, and to bound it a little, to only consider home-grade machines using stepper motors, not servomotors. I think there is value in a new open source design, to collect up the wisdom of the various CNC users here, so we can all have low-cost home robots to make things for us!

      After some initial thinking, these sketches were a couple of ideas: They are based around the thought that the BBB could be a plug-on daughter card on a larger interface board, that uses something like RJ45-style connectors (because it would be nice to use off-the-shelf cables where possible, to reduce wiring effort, otherwise there are a lot of wires to connect).

       

      After some further discussions with balearicdynamics, it was suggested that scenario 1 could be more practical since it can handle more motors (low power and high power). I too like that idea, since it is one less board to make.

      Edge connectors or some other connection location could still be left on the board, for those who do want to have a custom board for add-ons (e.g. to control a 3D printer instead, where they may need outputs for say a heater).

       

      More input to any of this, including the practicality of it all, and board design (physical as well as functionality), and connector choices, is welcome. Meanwhile, I've been looking at the existing boards that are supported by Machinekit, to see what pins they use of the BBB, and why. I'll have to install Machinekit to better understand it. So far, I've looked at boards (or Machinekit configs) called CRAMPS, Replicape, and BeBoPr-Bridge and all use different pin mappings. I need to figure out which of these configs are using the PRU, and if so, which pins to allocate for that. I like the CRAMPS pin mapping so far, because it avoids eMMC and HDMI clashes (the BBB has these brought out to its connectors, and some interface boards tend to use these, which rules out using eMMC or HDMI as a result).

       

      The pin mappings are in text files, but not easy to compare, so I've put them in a spreadsheet, I'll attach that as soon as it is complete.

      The pin mapping text files are: CRAMPS.halreplicape.hal, BeBoPr-Bridge.hal  (I'll look at a few more too, and put them in the spreadsheet).

      The mappings are numbers like 817, which means header P8 on the BBB, pin number 17.

       

      EDIT: I'd hoped to daisy-chain the supplies, but looking at the user docs of a random one, it recommends against this practice:

      So, the in/out connectors may not be a good idea, and a single power connector on each motor driver could be preferred.

      I'm still looking for a suitable connector, but thinking it may as well be another RJ45-style, since I cannot think of another high power cheap alternative. Ethernet will carry lots of current safely, if wires are paralleled. There is the risk of accidentally plugging it into the wrong socket, but they could be color coded.

        • Re: CNC Interface Board discussion
          Jan Cumps

          shabaz  wrote:

           

          ... some programmable real-time units (PRU) internally, and they can override some GPIO pins, for direct control without needing to go through the Linux system. So, the Linux system can push code to execute on the PRU, and the PRU will control the pins. This means high speeds, and no unexpected delays or jitter, since the PRUs are simpler devices that do not run an operating system that could have a task preempted.

           

          It works. I just did a proof of concept where one of the PRUs controls the motor and the only burden on Linux is to tell the PRU how many steps the motor should take, in what direction.

          BeagleBone Control Stepper Motors with PRU - Part 5: It Works

          Command buffering is part of the default functionality. You can send a number of commands and the PRU will handle them one by one.

          9 of 9 people found this helpful
          • Re: CNC Interface Board discussion
            genebren

            I would agree that scenario 1 does make the most sense.  Running lower current signal from the interface board, out to the driver, is a good idea.  That could make it possible to locate the drive closer to the motor (including the possibility of mounting it directly to the motor), thus limiting the IR losses between the driver and motor.  I also like the ability to have a common driver interface (signaling), so that different drivers could be used to match the motor being used (stepper, DC, etc).

             

            As far as connectors go, I do like the possibility to use RJ45 style connectors, given the ease of making cables (inexpensive connectors, mass termination, etc.).  For wiring between the motor and driver, I would like a high current option.  I have used, with good results, Phoenix Contact connectors, on some of the products that I have worked on.  They can be a bit pricey, but they are easy and quick when making connections.  Here is one of the styles that I am currently using (listed for 8A):

             

            The power distribution, direct to each motor, does make a lot of sense.  With the motors (and drivers?) potentially being place throughout an assembly (i.e. not necessary grouped together), the daisy chain power might be more difficult and could create excess cable length.  Direct connection also tends to be a little less noisy.

             

            Off to a good start.

            Gene

            4 of 4 people found this helpful
              • Re: CNC Interface Board discussion
                Jan Cumps

                ... another good reason to use a proper stepper driver is that it generates stepper friendly currents. A half bridge design,  controlled by a pulse signal,  will try (and succeed) to run the motor with square waves. But that’s never going to result in an efficient and smooth running design.

                6 of 6 people found this helpful
                  • Re: CNC Interface Board discussion
                    balearicdynamics

                    That's the reason that in many devices a more serious stepper controller should be used?

                      • Re: CNC Interface Board discussion
                        Jan Cumps

                        A stepper controller (IC or board) takes away the complexity of driving the individual coils properly. They often include logic to handle microstepping, stalled motor detection and torque management.

                        Even with these controllers, there is enough complexity left for the firmware programmer to design an algorithm/profile that properly and smoothly controls the motor.

                        For a DIY project, designing that driver/power circuit may be part of the fun.

                        2 of 2 people found this helpful
                          • Re: CNC Interface Board discussion
                            shabaz

                            The scenario 2 board "stepper driver carrier board" was for things along the lines of off-the-shelf stepper controller IC boards, but could be any custom board design. Especially for the reason you say, that it could be fun for some people to develop that if they preferred that over the scenario 1 individual driver modules. It will be nice to have interest and challenge areas for those who want that - and also it is hard to predict all scenarios, so a second board could be used to offload things for the future too. I'll put some ribbon cable socket on the "Interface board", to allow passing the signals to a potential second board, and another ribbon cable (or the same one) to pass the outputs back onto the Interface board, so that the output connectors are only needed on the one board basically.

                            Something like this (the diagram is only showing one motor):

                            In other words, the "Motor 1" connector in the diagram, optionally serves double-duty. In scenario 1, it carries low-level signals to the external individual driver modules. In scenario 2, it is directly connected to the stepper motors. But even that could be optional, i.e. if the Stepper Carrier Board is designed for higher current than 1.5A per pin (i.e. 3A if I can double them up for bipolar motors) then the stepper carrier board could use its own connectors, e.g. screw terminals.

                            2 of 2 people found this helpful
                    • Re: CNC Interface Board discussion
                      shabaz

                      Just an update: Last night I tried to locate a ready-made Machinekit micro SD card image (apparently that exists) but it proved hard to find! The information sources out there are really bad.

                      Then I tried to follow a blog and build my own, but the preparatory steps were not appropriate. They suggested using PREEMPT RT kernel version for real-time linux but I didn't know if it was good or not. So scouring the web there was another website that described a test to run called cyclictest (it can be installed on linux by typing apt-get install rt-tests ) , to see how much latency is being caused by the kernel. I tested that, and worst case latency (I let it run for only a few minutes, so not a thorough test) was about 350usec, which seems really long.

                      Apparently 'Xenomai' is much better, allowing ten-fold improvement on BBB. That entails building the kernel, so I tried that, but I need to work on it some more, to confirm the precise kernel version and to integrate the Xenomai patches in it. If that works, then I'll install Machinekit, and see what PRU code already exists as part of it, and what pinouts are needed for that.

                      3 of 3 people found this helpful
                        • Re: CNC Interface Board discussion
                          Jan Cumps

                          I'm running the latest headless Debian (with fresh latest kernel upgrade), and it's flagging itself as PREEMPT

                           

                           

                          edit: probably not the PREEMPT RT you're looking for ...

                          1 of 1 people found this helpful
                            • Re: CNC Interface Board discussion
                              clem57

                              For anyone wondering:

                              A preemptive kernel allows a process to be preempted while it is running in kernel mode. A nonpreemptive kernel does not allow a process running in kernel mode to be preempted; a kernel-mode process will run until it exits kernel mode, blocks, or voluntarily yields control of the CPU.

                              I wanted to confirm what I thought it may be...

                                • Re: CNC Interface Board discussion
                                  shabaz

                                  Hi Clem,

                                   

                                  One day I'll read up on the specifics in these Linux RT kernel variants : ) I don't know much (anything) about them.

                                  But from general RTOS techniques, it's likely to do with things like how long processes are allowed to run for, and when they can run. In any OS, sometimes you can 'hint' to the kernel, which tasks/processes are important to you, so it can schedule them accordingly. It gets messy because since there are many shared things (like storage), so if a disk unexpectedly takes longer to read a file (maybe it is fragmented), then it's difficult for the OS to know, should it wait for completion, or meanwhile should it let another process do it's thing? Just the act of switching from one task/process to another takes time.

                                  In a similar vein, the OS might not know, that a high priority task is actually waiting on something from a low priority task (e.g. waiting on a file to be written with instructions). If the high priority thing is given all the CPU cycles, the low priority one will never complete : )

                                  so it will try to never totally starve low-priority stuff either.

                                  A 'normal' Linux (excluding some older stuff like uClinux) is preemptive (i.e. it will switch out processes when it feels like it to a degree) but the algorithm that decides on what tasks should run when, becomes critical for controlling machinery.

                                  Also, part of the software fun is to do things like place content in memory, so that it can be read quicker. Oracle (amongst other) has made billions out of specialist databases that do such techniques, for fast data storage/access.

                                  3 of 3 people found this helpful
                                • Re: CNC Interface Board discussion
                                  Jan Cumps

                                  Two links on the build + installation of MachineKit for BB.

                                  https://github.com/rubienr/bbb-linuxcnc-config

                                  https://machinekoder.com/machinekit-debian-stretch-beaglebone-black/ (includes instructions to add PREEMPT RT)

                                   

                                  It includes building part of the code on BB, another part (where the BB doesn't have enough swap space) on another Linux with the BB's file system mounted. I think coffee is needed in huge quantities ...

                                    • Re: CNC Interface Board discussion
                                      shabaz

                                      Hi Jan,

                                       

                                      I too suspected the default kernel is PREEMPT RT based on uname -a as you say, but just to be sure, I installed a more recent kernel patch including PREEMPT RT, but the performance results from the test tool were not noticeably different. Both give values in the ballpark of 400 usec (still, that's better than what I'm getting on a virtual machine on x86, with no PREEMPT RT, where it went to 1700 usec. I don't have a non-VM x86 linux installed anywhere, but I compared with a Pi 3 with a default raspbian, uname -a reporting Linux raspberrypi 4.14.98-v7+ #1200 SMP, which gave a max value of 783 usec).

                                       

                                      The machinekoder website instructions use PREEMPT RT, but as I understand, Xenomai should give far better results, so I wasn't keen to follow those instructions any more : ( the website owner charges for consultancy, I guess that's when the decent real-time patches get applied.

                                       

                                      I checked with the beagleboard mailer, it turns out there is a machinekit specific Linux image, it just wasn't linked anywhere, so I've updated the elinux bbb page with the detail, and downloaded it. About to try to install it.. (I think it does use Xenomai).

                                       

                                      I also tried building a kernel, although the BBB booted up, there was no networks : ( just console access. So, as another thing to follow up on (in case the machinekit specific Linux image doesn't work), I've raised that on the mailer too.

                                      3 of 3 people found this helpful
                                      • Re: CNC Interface Board discussion
                                        shabaz

                                        Good idea with the coffee hehe : ).. done way too much typing in a Linux shell for the weekend!

                                  • Re: CNC Interface Board discussion
                                    Fred27

                                    I'll be following this with interest. CNC control is one of those problems that sounds like it should be easy to solve in this age of cheap and powerful microcontrollers / FPGAs. It just feels it's never been quite done properly.

                                     

                                    I've used mach 3 with both a CNC router and a  a K40 laser - both with what's essentially a parallel port break-out board. In this case Mach3 (running on Windows XP 32-bit) does all the work an outputs accurately timed pulses over the parallel port. The real-time parallel port control is why you can't use later versions of Windows, laptops or USB to parallel adapters. I've also used a Smoothieboard for the laser.

                                    3 of 3 people found this helpful
                                    • Re: CNC Interface Board discussion
                                      clem57

                                      Here is a rather old discussion, but may still be appropriate to this project. What do you think shabaz?

                                      Clem

                                      1 of 1 people found this helpful
                                      • Re: CNC Interface Board discussion
                                        shabaz

                                        Final update for the day; it turns out there is a pre-built Xenomai kernel, so no need to try to build it from scratch. I added it to my BBB, but after it boots, it hangs! (perhaps 20 seconds after it the login prompt - I can log in during that time and use it). I cannot tell what is causing it (I cannot find a pattern to it, from the log files so far). In any case, on a hunch, I tried a normal BBB (well, a BBB-Industrial), rather than the BBB-Wireless. Then it worked : )

                                        To test the kernel, I need to install some user-space Xenomai stuff, and then run a test program. That's for another day!

                                        There is still the option of trying the pre-built Linux Machinekit image too, so it is still a 2-pronged approach, to see what works best.

                                        I worry just one avenue could be shut somewhere further down, so better to have two (or more) for now.

                                        But in conclusion, I think for BBB CNC stuff, it may be better to go for the standard BBB (or BBB-Industrial, since it is the closest to the original) rather than the others, simply because the real-time kernel patches may have been tested more on that.

                                        3 of 3 people found this helpful
                                          • Re: CNC Interface Board discussion
                                            Jan Cumps

                                            What I was wondering about: “Why the need for RT in Linux if the time critical (and jitter sensitive) functions are done in the PRUs?”

                                              • Re: CNC Interface Board discussion
                                                Brian Welsby

                                                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.

                                                  • Re: CNC Interface Board discussion
                                                    Jan Cumps

                                                    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.

                                                    2 of 2 people found this helpful
                                                  • Re: CNC Interface Board discussion
                                                    shabaz

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

                                                    2 of 2 people found this helpful
                                                  • Re: CNC Interface Board discussion
                                                    shabaz

                                                    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.

                                                    2 of 2 people found this helpful
                                                  • Re: CNC Interface Board discussion
                                                    shabaz

                                                    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.

                                                     

                                                    3 of 3 people found this helpful
                                                    • Re: CNC Interface Board discussion
                                                      Jan Cumps

                                                      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?

                                                        • Re: CNC Interface Board discussion
                                                          Fred27

                                                          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.

                                                          2 of 2 people found this helpful
                                                            • Re: CNC Interface Board discussion
                                                              Jan Cumps

                                                              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.

                                                              2 of 2 people found this helpful
                                                                • Re: CNC Interface Board discussion
                                                                  peteroakes

                                                                  Lets not forget also Z changing for CNC work, so that would be 3 steppers / Servos to track and calc for, no simple task im sure, like you the grey matter is lacking in this regard.

                                                                   

                                                                  For 3D printing this is simplified by the fact they print 1 layer at a time so only 2 axis to worry about. also a lot of apps will not handle curves and in fact will break them up in to a set of straight lines approximating a curve (Actually a setting in Fusion 360 CNC output tools), if you were to also include curves as is used in more expensive CAM programs then the math is way more complex yet again.....

                                                                   

                                                                  The hardware is the easy part lol

                                                                  1 of 1 people found this helpful
                                                              • Re: CNC Interface Board discussion
                                                                shabaz

                                                                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
                                                                
                                                                4 of 4 people found this helpful
                                                              • Re: CNC Interface Board discussion
                                                                shabaz

                                                                I made some steps forward today (and always some backward of course : ).

                                                                Looking more deeply at some of stuff on the Internet, it seems most guides for installing Machinekit are for PREEMPT RT on Beaglebone, and not Xenomai. That's disappointing, but I figured I'd get back to that once I have a bit more understanding of how Machinekit works. So, I put aside the Xenomai stuff, and burned a new micro SD card with a ready-made Linux image already containing Machinekit. It is available here: https://elinux.org/Beagleboard:BeagleBoneBlack_Debian  (search for the text machinekit on that page). It gets installed just like a standard BBB Linux image, except the default user isn't debian, but is a user called machinekit (with the password machinekit too).

                                                                 

                                                                So, once that was installed, I searched around, and found almost nowhere that describes what to do next It's incredible how unfriendly the documentation out there is for beginners to CNC, even on the official sites. However, this link has nice simple steps for beginners: https://jetforme.org/2018/04/machinekit-on-bbb/

                                                                 

                                                                Anyway, although I'll write it up properly once there is more progress and a good path chosen, (currently it is still stabbing in the dark) here are the steps I did so far:

                                                                 

                                                                After installing as described above, I used VNC to be able to run graphical applications (another hurdle - nothing is straightforward : ) because the usual tightvnc steps for Linux didn't work, so I had to do this:

                                                                 

                                                                apt-get update
                                                                apt-get remove xrdp vnc4server tightvncserver
                                                                apt-get install xrdp tigervnc-standalone-server
                                                                edit /etc/xrdp/xrdp.ini and move the entire Xvnc section above the Xorg section.
                                                                systemctl restart xrdp
                                                                usermod -a -G xrdp machinekit
                                                                

                                                                 

                                                                Then, using Remote Desktop Connection from Windows 10 and connecting to the BBB, in the black screen that appears, right-click to see a pop-up menu and select Terminal Emulator.

                                                                In that window, type machinekit and a configuration menu launches! It has a list of configs displayed, so I scrolled down to ARM->BeagleBone, and chose one.

                                                                 

                                                                I've decided to explore the CRAMPS config for now, because I think (not sure) it should be using PRU, and also because it doesn't clash with pins on BBB used for HDMI.

                                                                 

                                                                Once selected and saved, a GUI automatically appears to control the (imaginary as yet) CNC machine attached to the BBB (From the GUI it looks like it thinks it is a 3D printer, but other user interfaces are possible - I'm only using this one to experiment).

                                                                The analog pins on the BBB are being used incidentally, because if I put fingers around the end of P9 connector (where the analog inputs reside) the green bar graph readings on the top-right of the screenshot below, move around.

                                                                Anyway, from the GUI, it is possible to power up the imaginary CNC machine, and make it manually move an axis (see red circled areas of the GUI).

                                                                In an earlier comment the file locations was mentioned where the pin numbers are stored. I'm still working on creating a table of them all, it isn't complete, but here's the bit covering the three axes stepper motors for some of them so far:

                                                                According to that, the X-axis stepper motor should be controlled with pulses sent to connector P8 pin 13. This is odd, because if it is using PRU then that pin should not be possible. The PRU is not wired to that pin internally. So, that still needs investigating too (I've seen where in the config the PRU driver code is specified, so I just need to dig a bit deeper). Anyway, for now here's a 'scope trace of what happens to that pin, when the '+' button in the screenshot above is pressed (to try to manually advance the X stepper motor by 1 'unit').

                                                                As can be seen, it is accelerating and decelerating as we would have expected. Longer movement tests will be needed to examine what jitter occurs.

                                                                This is exciting, and gives me more confidence now there is light at the end of the tunnel, and a PCB design can be worked on soon too (after figuring out the PRU stuff, and working on the pin mappings and interfaces).

                                                                2 of 2 people found this helpful
                                                                  • Re: CNC Interface Board discussion
                                                                    Jan Cumps

                                                                    With the latest PRU drivers, this command can reveal what firmware is loaded to the PRU0:

                                                                    cat /sys/class/remoteproc/remoteproc1/firmware
                                                                    

                                                                     

                                                                    That firmware - or a symbolic link, is located in /lib/firmware/

                                                                    ls -l /lib/firmware/ | grep [firmware filename]
                                                                    

                                                                     

                                                                     

                                                                    ... and this one shows the state (started or stopped)

                                                                    cat /sys/class/remoteproc/remoteproc1/state
                                                                    

                                                                     

                                                                     

                                                                    In my case, where I use loaded my own custom firmware to PRU0 and used a symbolic link in /lib/firmware/ instead of copying the binary to that directory:

                                                                     

                                                                    debian@beaglebone:~/bin$ cat /sys/class/remoteproc/remoteproc1/firmware
                                                                    am335x-pru0-fw
                                                                    debian@beaglebone:~/bin$ ls -l /lib/firmware/ | grep am335x-pru0-fw
                                                                    lrwxrwxrwx  1 root root             35 Aug 17 20:38 am335x-pru0-fw -> /home/debian/bin/bb_PRU_STEPPER.out
                                                                    debian@beaglebone:~/bin$ cat /sys/class/remoteproc/remoteproc1/state
                                                                    running
                                                                    

                                                                     

                                                                    By replacing  remoteproc1 with  remoteproc2, you get the status of PRU1.

                                                                    3 of 3 people found this helpful
                                                                      • Re: CNC Interface Board discussion
                                                                        shabaz

                                                                        Hi Jan,

                                                                         

                                                                        Thanks for this! That will be helpful for this troubleshooting. When running I don't see any remoteproc1 or 2, just a remoteproc0 running some power management stuff (am335x-pm-firmware.elf), so it seems neither PRU is being used currently : ( However references to PRU are in the initialization file for the config I'm using (it refers to a PRU bin file) so I'll try to debug that later today, see why it isn't being used, and what the code should have done.

                                                                        2 of 2 people found this helpful