Hi Malte, Thanks for sharing! I'm also working on a similar setup as yours. However in my case we also build the lathe! :D My father does all the mechanics and me the electronic&control system with Machinekit.
The project is still underway.. maybe about half way now. I made some video to show the current progress: https://youtu.be/bn6DsqG35MU I designed a 35 IO buffer interface cape to protect the Beaglebone Black. Each IO can be configured as input or output by a solder jumper. Then I have also designed opto-isolation modules to fully protect the BBB and have a voltage range of 5-15V on all IO (I use 12V in my setup). The output can deliver up to ~50mA which allows to directly drive small relay. I also want to write some page/blog (and why not on Machinekit blog) to share my work when I will find time for it. What encoder do you have on the spindle? I'm asking because I haven't figured out yet what could suit my need. As we plan to leave an empty diameter of ~40mm for workpieces, we cannot use a small encoder so I was thinking of making some disk myself. However it might be difficult to make since I also would like to have a good accuracy (at least 500-1000cpr) to do turning with spindle control positioning. Regards, /Damien Le lundi 4 février 2019 20:54:33 UTC+1, Malte Schmidt a écrit : > > Dear all, > > first of all I would like to say a big THANK YOU to all the contributors > of machinekit and linuxcnc. I do really value the effort you all put into > this ! > > When setting up my machine I realized that, while all needed information > was available somewhere, the information was somewhat scattered around and > it took some time to figure out what was relevant and what was not. > I therefore collected some notes and thought about posting this somewhere > (blog) to help others. I have some background in Linux and Linuxcnc (PC) as > user and did therefore not note down line for line but rather tried to > capture the overall process of getting machinekit to work on a BBB. > > My notes are below and I wonder if this would be good content for the > machinekit blog. If yes, how can I post this there? > > BR, > Malte > > > > This document was written in December 2018/Januar 2019 > > The challenge: > Automate a lathe with 2 steppers, limit switches > Allow for manual turning using encoder input for x, z > Provide glass scales input for manual turning (this may be considered > gold plating but my initial plan was to use this lathe in CNC or manual > mode) > Obviously have spindle feedback and control the lathe motor > Ideally controlled via touchscreen. > > My leanings: > > I considered the following approaches: > With the amount of inputs required a > - parallel port solution would only be feasible if multiple parallel > ports are used. -> decided against it > - MESA card solution requires two cards -> expensive, decided against > it > - A beagle bone based solution with GPIO and PRUs -> my tentatively > selected approach. Downside of this is the poor graphic performance > > Linux on the Beagle Bone Black: > Three different options exist for Realtime in the Linux Kernel > - RTAI > - RT_PREEMPT > - Xenomai > > All are patches to the vanilla Linux kernel. > - RTAI is old and seems to be superseded by... > - RT_PREEMPT which will be adapted by main Linux kernel > - Xenomai is commercial > > My takeaway is that RT_PREEMPT would be ideal but Xenomai is a > possible option. > > Two different Debian Linux distributions have been considered: > - Strech > - Jessie > > To get a Debian distribution and one of the realtime kernels on the > beagle board three approaches have been explored: > 1) Putting it toggelter by hand ( > https://machinekoder.com/machinekit-debian-stretch-beaglebone-black/) > 2) Getting Strech + RT_PREEMPT from eLinux ( > http://www.machinekit.io/docs/getting-started/machinekit-images/ and > https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BBW.2FBBB_.28All_Revs.29_Machinekit > ) > 3) Getting Jessie + Xenomai from eLinux (see links above) > > Findings > - Current RT_PREEMPT + Strech combinations 1) and 2) above have long > boot times of 2-4 minutes. > - The blog post in 1) is a good read in any case to perform some steps > to get the system up to date and further improve boot times > > Flashing > - I was not able to flash using the procedures described in most > online places. I booted from SD and than used the approach outlined ( > https://stackoverflow.com/questions/33930747/how-to-flash-beaglebone-black-emmc-with-debian-8-2-image > ) > cd /opt/scripts/tools/eMMC/ > sudo ./init-eMMC-flasher-v3.sh > > I'm currently using Jessie and Preempt_RT because I'm lazy. There is > some background here on the boot time issue which will hopefully be > resolved in the future: > https://groups.google.com/forum/#!topic/machinekit/sOWj5I7fVpo > > Cape support > - No commercially available cape was suitable to be used with my > requirements. So I decided to go with a Sparkfun prototype cape and wire up > things from there. > > The name of the board coded in the EEPROM will tell which device tree > overlay file to load. The device tree overlay file declares the pins we can > use with this cape. > (cf https://github.com/jbdatko/eeprom_tutorial/blob/master/eeprom.md) > > With different Linux versions different approaches exist how this is > achieved. > Linux 3.8 / Xenomai + Jessie uses capemanager > Linux 4.4 / Preempt_RT + Strech uses U-boot overlays > > Most resources in the internet are about capemanager. > > We need two things for loading the cape during boot: > -- EEPROM > -- Device Tree overlay file > > - The easiest way to get through this is using existing device tree > overlay files. (https://github.com/cdsteinkuehler/beaglebone-universal-io) > - This means that the eeprom needs to be coded such that those are > loaded. > Use https://github.com/picoflamingo/BBCape_EEPROM to write e.g. > cape-universal in both the board name and revision field (I don't know > which field is actually used) > > - For the Sparkfun Prototype cape it may be good to know that the > sparkfun prototype cape addr is 0x57 > > Checking if cape is recognized > capemanager: > - Check that the cape is recognized (e.g. > http://azkeller.com/blog/?p=62) > U-Boot overlays > - Check that cat /proc/cmdline shows overlay file handed over to > kernel > > - Also worth to note: > https://groups.google.com/forum/#!topic/machinekit/SF9xA8sdpB0 and > http://derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tree-overlays/ > > > My board stopped booting from eMMC at this point when the cape was > connected. It's unclear why > > > Machinekit setups > Get this tool: https://github.com/machinekoder/BBIOConfig/releases > (bbioconfig_v1.1-7_windows_x86.zip) > https://github.com/machinekoder/BBIOConfig > To create a BBIO file that actually contains the pins and settings you > intend to use > > Get and modify run.py from one of the different configurations (e.g. > from > https://github.com/machinekit/machinekit/blob/master/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS/run.py > ) > > I created a "standard" Axis UI configuration (i.e. the selection that > comes up when starting machinekit) and copied the .ini file from there. I > also copied GUI related stuff (postgui.hal and xml files) > I used the cramps hal file as starting point for my specific stuff: > https://github.com/machinekit/machinekit/blob/master/configs/ARM/BeagleBone/CRAMPS/CRAMPS.hal > > My takeaways > - Make sure to understand the constraints: > - Pin usage and dependencies are error prone. The same output may > be routed to different pins > - You can use only one PRU (machinekit driver restriction) > > > Adding hardware inputs and outputs to my custom cape > A fairly straightforward thing. I used HW-399 Optocoupler Modules to > isolate all inputs. They are based on a TLP-281 chip. All powered from the > beagle board. > The outputs are generated by a 4 channel (BiDirectional - although > this is not used) logic level converter module. There are integrated and > discrete solutions for this on the market. > I used a discrete version here to provide the required current (afaik > <15mAh) for the optocouplers in the stepper drivers. The integrted drivers > available in the market are not as capable in this regard. > > Overall 16 inputs and 4 outputs are generated this way. > > The hardware design is not as nice but good enough for me. I mounted > the logic lvel converter and one optocoupler on the proto cape. > The other parts are mounted on 3D printed holder together with the BBB > > The "real" User interface > As stated in the beginning it was clear that the BBB would not deliver > a good graphics performance and I looked into different options how to deal > with this > > a) Axis with remote X server > This was too slow. And also not did not meet the desire to use a > touchscreen. I also did not see a way to work around this. > > b) QtQuickVCP with Cetus or a to be developed UI (for touch) > This seems to be somwhat work in progress. The UI responsiveness was > good but there were two things that I considered as downsides. The main > thing was that > the UI requires a number of user interactions to actually load. The > developement effort for a touch UI was another downside. > > c) Machinetalk with Browser based UI (WebVCP) > This would have been a possible option to work around the different > user interactions with QtQuickVCP. But I did not get this to work within > reasonable time > The development effort was also clearly a downside here > > d) Touchy > Touchy delivered a reasonable graphics performance when using this > with a remote X server. I therefore investigated this further and realized > that this is actually > fast enough with X running on the BBB itself. I assume this is because > touchy will not create a preview. Since I'm running a lathe which is 2D > only this is actually good enough. > > My learnings: > - Touchy is what I will be evaluate / use further. If my > requirements would have included a working preview I would have continued > with QtQuickVCP. > > X Display system + touchsceen. > - I'm using a waveshare 7" touchsceen. My first attempts to get this > to work failed (touch was not working). > It started to work after I installed lxdm but likely this was because > some tools got installed in this process. I did not figure out the details > here. > > Autologin > follow these steps to automaically log to the terminal: > https://unix.stackexchange.com/questions/401759/automatically-login-on-debian-9-2-1-command-line > and add startx [run.py] to your .bashrc > > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
