Hi Damien, this is by far more advanced what I have been building.
My spindle encoder is a 50 cpr disc so nothing fancy. A pic is located here: https://forum.zerspanungsbude.net/viewtopic.php?p=453365#p453365 A tool turrent would indeed be a nice addition :-) BR, Malte Am Dienstag, 5. Februar 2019 14:29:03 UTC+1 schrieb Damien Dando: > > 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.
