[Machinekit] Re: Encoder signals from servo to Beaglebone Black
By default, the step/dir pins use GPIO access which is valid for either PRU core. The encoder signals, however, need to be direct PRU inputs, so the pins chosen and the pinmux setup will need to be valid for the specific PRU core you choose to run the driver. You setup the pin multiplexing outside of Machinekit/HAL, typically with a device-tree overlay, or the universal pinmux overlay and config-pin utility. Some details on pin selection can be found in the PRU driver man page: https://www.machinekit.io/docs/man/man9/hal_pru_generic/ On Friday, November 17, 2023 at 3:25:37 AM UTC-6 Antti wrote: > Hello > > I have made my DIY CNC milling machine with BBB and DIY cape. I used > ARM.BeagleBone.Xylotex setup as base and modified that to work with my > machine. > I used old Omron servo drivers and motors with DIR and STEP signals. It > kinda works but now I'd like to add feedback signals from servos to BBB > (2048 pls/rev). > > So there is quadrature signals from X, Y and Z. I'm planning to use these > pins P9:25, P9:27, P9:28, P9:29, P9:30, P9:31 > I have understood that these pins are in PRU0 and first I have to config > the those as "pruin" in setup.sh file? > > Then the ini-file now: > [PRUCONF] > DRIVER=hal_pru_generic > CONFIG=pru=1 num_stepgens=3 > PRUBIN=xenomai/pru_generic.bin > > so can I change it to: > CONFIG=pru=0 num_stepgens=3 num_encoders=3 > > And how to I do the HAL wiring? > > Here is the pins that are in use now: > P8.07 out # gpio2.2 Enable System > P8.10 in # gpio2.4 XLIM > P8.11 out # gpio1.13 X_Dir > P8.12 out # gpio1.12 X_Step > P8.13 out # gpio0.23 PWM0/SPINDLE > P8.14 in # gpio0.26 YLIM > P8.15 out # gpio1.15 Y_Dir > P8.16 out # gpio1.14 Y_Step > P8.18 in # gpio2.1 ZLIM > P9.15 out # gpio1.16 Z_Step > P9.23 out # gpio1.17 Z_Dir > P8.09 in # gpio2.5 STOPin > Are these step/dir signals used by PRU 1? Or can I use these with PRU 0? > > -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/4321a4f9-b6dc-4148-9459-4af4c8d6ef37n%40googlegroups.com.
Re: [Machinekit] pru - output pin
.00.dbg_ff_vel 0.10 --l- 106 float OUT -7717.106 hpg.stepgen.00.dbg_pos_minus_prev_cmd 0.10 --l- 106 float OUT 0.1 hpg.stepgen.00.dbg_s_to_match 0.10 --l- 106 s32 OUT 5368709 hpg.stepgen.00.dbg_step_rate --l- 106 float OUT 200 hpg.stepgen.00.dbg_vel_error 0.10 --l- 106 u32 IN 0x00C8 hpg.stepgen.00.dirhold --l- 106 u32 IN 0x032C hpg.stepgen.00.dirpin --l- 106 u32 IN 0x00C8 hpg.stepgen.00.dirsetup --l- 106 bit IN TRUE hpg.stepgen.00.enable --l- 106 float IN 2000 hpg.stepgen.00.maxaccel 0.10 --l- 106 float IN 200 hpg.stepgen.00.maxvel 0.10 --l- 106 float IN 0 hpg.stepgen.00.minvel 0.10 --l- 106 float IN 1 hpg.stepgen.00.position-cmd 0.10 --l- 106 float OUT 2284.294 hpg.stepgen.00.position-fb 0.10 --l- 106 float IN 20 hpg.stepgen.00.position-scale 0.10 --l- 106 bit IN FALSE hpg.stepgen.00.stepinvert --l- 106 u32 IN 0x03E8 hpg.stepgen.00.steplen --l- 106 u32 IN 0x032D hpg.stepgen.00.steppin --l- 106 u32 IN 0x03E8 hpg.stepgen.00.stepspace --l- 106 s32 OUT 385815358 hpg.stepgen.00.test1 --l- 106 s32 OUT 45697 hpg.stepgen.00.test2 --l- 106 s32 OUT -1299849246 hpg.stepgen.00.test3 --l- 106 float IN 0 hpg.stepgen.00.velocity-cmd 0.10 --l- 106 float OUT 200 hpg.stepgen.00.velocity-fb 0.10 --l- 106 s32 OUT 8582 hpg.update.time 106 s32 I/O 54414 hpg.update.tmax 106 bit OUT FALSE hpg.update.tmax-inc *$ uname -a* Linux beaglebone 4.19.120-bone-rt-r50 #1stretch PREEMPT RT Fri May 8 22:45:31 UTC 2020 armv7l GNU/Linux *$ ls /proc/device-tree/chosen/overlays/* AM335X-PRU-UIO-00A0 BB-ADC-00A0 BB-BONE-eMMC1-01-00A0 BB-HDMI-TDA998x-00A0 name -- Charles Steinkuehler cha...@steinkuehler.net -- Charles Steinkuehler cha...@steinkuehler.net -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/14aaa34c-128a-4b4d-3a55-0ee97d5c8fc6%40steinkuehler.net.
Re: [Machinekit] pru - output pin
st2 --l- 106 s32 OUT -1299849246 hpg.stepgen.00.test3 --l- 106 float IN 0 hpg.stepgen.00.velocity-cmd 0.10 --l- 106 float OUT 200 hpg.stepgen.00.velocity-fb 0.10 --l- 106 s32 OUT 8582 hpg.update.time 106 s32 I/O 54414 hpg.update.tmax 106 bit OUT FALSE hpg.update.tmax-inc *$ uname -a* Linux beaglebone 4.19.120-bone-rt-r50 #1stretch PREEMPT RT Fri May 8 22:45:31 UTC 2020 armv7l GNU/Linux *$ ls /proc/device-tree/chosen/overlays/* AM335X-PRU-UIO-00A0 BB-ADC-00A0 BB-BONE-eMMC1-01-00A0 BB-HDMI-TDA998x-00A0 name -- Charles Steinkuehler cha...@steinkuehler.net -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/94b13aea-d964-8e48-aa65-e46711a6b938%40steinkuehler.net.
Re: [Machinekit] pru - output pin
I/O 54414 hpg.update.tmax 106bit OUT FALSE hpg.update.tmax-inc *$ uname -a* Linux beaglebone 4.19.120-bone-rt-r50 #1stretch PREEMPT RT Fri May 8 22:45:31 UTC 2020 armv7l GNU/Linux *$ ls /proc/device-tree/chosen/overlays/* AM335X-PRU-UIO-00A0 BB-ADC-00A0 BB-BONE-eMMC1-01-00A0 BB-HDMI-TDA998x-00A0 name -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/52c15f26-6ccc-54c6-e89e-08ab3a354178%40steinkuehler.net.
Re: [Machinekit] pru_generic.so: cannot open shared object file: No such file or directory
You are missing the name of the HAL driver. The loadrt command expects a driver name, then the arguments. The error in your first command shows the HAL system trying to load the HAL driver named: "prucode=/usr/lib/linuxcnc/rt-preempt/hal_pru_generic" ...you need something like: loadrt hal_pru_generic On 5/12/2023 1:06 PM, klemen dovrtel wrote: Thank you for your reply, I tried both options, but with no luck: 1. loadrt prucode=/usr/lib/linuxcnc/rt-preempt/hal_pru_generic pru=0 halname=hpg returns msgd:0 stopped rtapi:0 stopped rtapi_msgd command: /usr/libexec/linuxcnc/rtapi_msgd --instance=0 --rtmsglevel=1 --usrmsglevel=1 --debug=1 --halsize=524288 rtapi_app command: /usr/libexec/linuxcnc/rtapi_app_rt-preempt --instance=0 --debug=1 stat: No such file or directory prutest.hal:6: insmod failed, returned -1: do_load_cmd: dlopen: prucode=/usr/lib/linuxcnc/rt-preempt/hal_pru_generic.so: cannot open shared object file: No such file or directory rpath=/usr/lib/linuxcnc/rt-preempt 2. loadrt prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic.bin pru=0 halname=hpg returns msgd:0 stopped rtapi:0 stopped rtapi_msgd command: /usr/libexec/linuxcnc/rtapi_msgd --instance=0 --rtmsglevel=1 --usrmsglevel=1 --debug=1 --halsize=524288 rtapi_app command: /usr/libexec/linuxcnc/rtapi_app_rt-preempt --instance=0 --debug=1 stat: No such file or directory prutest.hal:6: insmod failed, returned -1: do_load_cmd: dlopen: prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic.bin.so: cannot open shared object file: No such file or directory Regards Klemen On Fri, 12 May 2023 at 17:25, Charles Steinkuehler wrote: Your output indicates dlopen is looking for "pru_generic.so" but your filesystem only has "hal_pru_generic.so". You need to fix the script(s) trying to load the PRU HAL module or make a symlink or something so the file dlopen is looking for actually exists. On 5/12/2023 9:38 AM, fogl wrote: Hello everybody, I am stuck with machinekit and pru. I am running a single line .hal file: loadrt prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic pru=0 halname=hpg This returns: msgd:0 stopped rtapi:0 stopped rtapi_msgd command: /usr/libexec/linuxcnc/rtapi_msgd --instance=0 --rtmsglevel=1 --usrmsglevel=1 --debug=1 --halsize=524288 rtapi_app command: /usr/libexec/linuxcnc/rtapi_app_rt-preempt --instance=0 --debug=1 stat: No such file or directory prutest.hal:6: insmod failed, returned -1: do_load_cmd: dlopen: prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic.so: cannot open shared object file: No such file or directory rpath=/usr/lib/linuxcnc/rt-preempt Even though the file is actually there: $ ls /usr/lib/linuxcnc/rt-preempt | grep pru hal_pru.so hal_pru_generic.so hal_prudebug.so pru_decamux.bin pru_decamux.dbg pru_generic.bin pru_generic.dbg This is my linuxcnc.log (export DEBUG=5): May 12 14:19:23 beaglebone rtapi:0: do_load_cmd: dlopen: prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic.so: cannot open shared object file:$ May 12 14:19:23 beaglebone rtapi:0: rpath=/usr/lib/linuxcnc/rt-preempt May 12 14:19:23 beaglebone rtapi:0: 1:rtapi_app:4613:user do_load_cmd: dlopen: prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic.so: cannot op$ May 12 14:19:23 beaglebone rtapi:0: 1:rtapi_app:4613:user rpath=/usr/lib/linuxcnc/rt-preempt May 12 14:19:24 beaglebone msgd:0: rtapi_app exit detected - scheduled shutdown May 12 14:19:26 beaglebone msgd:0: msgd shutting down May 12 14:28:07 beaglebone rtapi:0: do_load_cmd: dlopen: prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic.so: cannot open shared object file:$ May 12 14:28:07 beaglebone rtapi:0: rpath=/usr/lib/linuxcnc/rt-preempt May 12 14:28:07 beaglebone rtapi:0: 1:rtapi_app:4766:user do_load_cmd: dlopen: prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic.so: cannot op$ May 12 14:28:07 beaglebone rtapi:0: 1:rtapi_app:4766:user rpath=/usr/lib/linuxcnc/rt-preempt May 12 14:28:08 beaglebone msgd:0: rtapi_app exit detected - scheduled shutdown May 12 14:28:10 beaglebone msgd:0: msgd shutting down $ uname -a Linux beaglebone 4.19.120-bone-rt-r50 #1stretch PREEMPT RT Fri May 8 22:45:31 UTC 2020 armv7l GNU/Linux Every help would be very much appreciated, Regards, Klemen -- Charles Steinkuehler char...@steinkuehler.net -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/c4be3f48-84e6-d3ad-1660-4d5252849489%40steinkuehler.net.
Re: [Machinekit] pru_generic.so: cannot open shared object file: No such file or directory
Your output indicates dlopen is looking for "pru_generic.so" but your filesystem only has "hal_pru_generic.so". You need to fix the script(s) trying to load the PRU HAL module or make a symlink or something so the file dlopen is looking for actually exists. On 5/12/2023 9:38 AM, fogl wrote: Hello everybody, I am stuck with machinekit and pru. I am running a single line .hal file: loadrt prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic pru=0 halname=hpg This returns: msgd:0 stopped rtapi:0 stopped rtapi_msgd command: /usr/libexec/linuxcnc/rtapi_msgd --instance=0 --rtmsglevel=1 --usrmsglevel=1 --debug=1 --halsize=524288 rtapi_app command: /usr/libexec/linuxcnc/rtapi_app_rt-preempt --instance=0 --debug=1 stat: No such file or directory prutest.hal:6: insmod failed, returned -1: do_load_cmd: dlopen: prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic.so: cannot open shared object file: No such file or directory rpath=/usr/lib/linuxcnc/rt-preempt Even though the file is actually there: $ ls /usr/lib/linuxcnc/rt-preempt | grep pru hal_pru.so hal_pru_generic.so hal_prudebug.so pru_decamux.bin pru_decamux.dbg pru_generic.bin pru_generic.dbg This is my linuxcnc.log (export DEBUG=5): May 12 14:19:23 beaglebone rtapi:0: do_load_cmd: dlopen: prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic.so: cannot open shared object file:$ May 12 14:19:23 beaglebone rtapi:0: rpath=/usr/lib/linuxcnc/rt-preempt May 12 14:19:23 beaglebone rtapi:0: 1:rtapi_app:4613:user do_load_cmd: dlopen: prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic.so: cannot op$ May 12 14:19:23 beaglebone rtapi:0: 1:rtapi_app:4613:user rpath=/usr/lib/linuxcnc/rt-preempt May 12 14:19:24 beaglebone msgd:0: rtapi_app exit detected - scheduled shutdown May 12 14:19:26 beaglebone msgd:0: msgd shutting down May 12 14:28:07 beaglebone rtapi:0: do_load_cmd: dlopen: prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic.so: cannot open shared object file:$ May 12 14:28:07 beaglebone rtapi:0: rpath=/usr/lib/linuxcnc/rt-preempt May 12 14:28:07 beaglebone rtapi:0: 1:rtapi_app:4766:user do_load_cmd: dlopen: prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic.so: cannot op$ May 12 14:28:07 beaglebone rtapi:0: 1:rtapi_app:4766:user rpath=/usr/lib/linuxcnc/rt-preempt May 12 14:28:08 beaglebone msgd:0: rtapi_app exit detected - scheduled shutdown May 12 14:28:10 beaglebone msgd:0: msgd shutting down $ uname -a Linux beaglebone 4.19.120-bone-rt-r50 #1stretch PREEMPT RT Fri May 8 22:45:31 UTC 2020 armv7l GNU/Linux Every help would be very much appreciated, Regards, Klemen -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/1c1a1070-2dd8-9571-dbe8-51a7bff1571b%40steinkuehler.net.
Re: [Machinekit] BBB + Xylotex BareBpnesCNC + bone-debian-9.12-machinekit-armhf-2020-06-01-4gb.img
The Debian Stretch image is pretty old, but I don't think anyone is really maintaining newer image builds right now. Your issue is you need the "universal" cape overlay to be loaded, which allows user-space control of GPIO multiplexing without having to craft a custom device-tree overlay file for your specific application. You should be able to manually go through the commands executed by the BareBones_setup.sh script and figure out why things aren't working. It looks like there is something preventing the cape-universal overlay from loading, which is causing the BareBones_setup.sh script to fail. Check your dmesg output which will sometimes have helpful error messages (but a lot of the errors for device-tree overlay stuff are either nonexistent or not generally useful). On 5/8/2023 12:56 AM, Anoop S wrote: Hi, As stated in the subjectline, these are the combination fo hardware and software I have setup: BeagleBone Black Rev C Xylotex BareBonesCNC Machine kit image -> https://rcn-ee.com/rootfs/bb.org/testing/2020-06-01/stretch-machinekit/bone-debian-9.12-machinekit-armhf-2020-06-01-4gb.img.xz I have copied the following files from Xylotex's website and put them in the right folder and changed permission of the *.sh file. BareBones.hal BareBones.ini BareBones_setup.sh However, upon starting machinekit, the configuration selector window popus up, then comes the "machinekit" splash screen but then no progress. Terminal reports the following: *machinekit@beaglebone:~$ machinekitMACHINEKIT - 0.1Machine configuration directory is '/home/machinekit/machinekit/configs/ARM.BeagleBone.Xylotex'Machine configuration file is 'BareBones.ini'Starting Machinekit...rtapi_msgd command: /usr/libexec/linuxcnc/rtapi_msgd --instance=0 --rtmsglevel=1 --usrmsglevel=1 --debug=1 --halsize=524288rtapi_app command: /usr/libexec/linuxcnc/rtapi_app_rt-preempt --instance=0 --debug=1io startedemc/iotask/ioControl.cc 859: can't load tool table.halcmd loadusr io startedgrep: /sys/devices/bone_capemgr.*/slots: No such file or directoryLoading cape-universal overlaybash: /sys/devices/bone_capemgr.*/slots: No such file or directoryError loading device tree overlay file: cape-universalBareBones.hal:6: program './BareBones_setup.sh' failed, returned 1Shutting down and cleaning up Machinekit...Cleanup doneMachinekit terminated with an error. For simple cases more informationcan be found in the following files: /home/machinekit/linuxcnc_debug.txt /home/machinekit/linuxcnc_print.txtFor other cases get more meaningfull information by restarting afterexport DEBUG=5and look at the output of:/var/log/linuxcnc.logdmesgWhen looking for errors, specifically look for libraries that fail to loadby looking for lines with 'insmod failed' as per example below.insmod failed, returned -1:do_load_cmd: dlopen: nonexistant-component.so: cannot open shared object file:No such file or directory* Wha have I done wrong ? Is it because I am using a different machinekit image than what is mentioned at Xylotex's web page ? Anoop -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/ae62a25d-6466-fe7d-0809-6604af6394d0%40steinkuehler.net.
Re: [Machinekit] Mesa cards compatibility question: Machinekit + ROS (Pins vs Params)
You should be able to use anything supported by Machinekit to generate step/dir pulses, and last I knew most of the Mesa hardware was supported. The pins/parameters thing relates to Machinekit generally dropping support for parameters in favor of pins. This was for a variety of reasons, but mostly because it allowed for making components instantiable at run-time, eg: eliminating the need to know ahead of time exactly how many instances of some component you might need for your HAL file. Most of the Mesa driver logic (eg: the HM2 driver) should be working in Machinekit, or at least it was when I was playing with Mesa VHDL code in the FPGA+SoC platforms a while back. Each individual card then has a small shim of code to handle the different communications protocols (eg: PCI/PCIe, EPP, SPI, Ethernet, etc). On 9/9/2021 4:39 PM, Jakub Kaminski wrote: Dear Machinekit Community, *tl;dr:* Machinekit uses HAL Pins for ROS bindings which is (or was?) nonstandard for Mesa cards (which uses params). Can I use any Mesa card with ROS and Machinekit for Step-dir control? (Looking at 7i92 + daughter cards). Trying to validate what I read online. *Full message:* Impressed by the possibilities that Machinekit + ROS offer and your great work at: hal_ros_control <https://github.com/zultron/hal_ros_control>package (@Zultron @Luminize @Machinekoder), ros_hal_tests <https://github.com/cdsteinkuehler/ros_hal_tests> (@Cdsteinkuehler) ros_hello_machinekit <https://github.com/luminize/ros_hello_machinekit> (@Luminize ) I would like to ask some compatibilty questions. As @Luminize stated in ros_hello_machinekit repository <https://github.com/luminize/ros_hello_machinekit> : *depending on the hardware you will need to use this machinekit branch (no support !!!) <https://github.com/luminize/machinekit/tree/hostmot-remove-params2> which uses pins instead of params for the mesa hardware stepgen. BEWARE only tested on a mesa 5i20 card. YMMV * I plan to buy 7i92 + daughter step/dir card just in case my parallel port is not good enough. Will it work with Machinekit + ROS without much modifications? Do I need to apply some custom branch or some other hacking? Thank you for your time devoted to this and making these meaningful contributions, which are a real game-changer for robotics researchers. Best regards, Jakub -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/59040026-542a-763e-d7c6-5fdeec05714e%40steinkuehler.net.
Re: [Machinekit] BBB Machinekit setup.sh differences
On 4/20/2021 12:12 PM, John Dammeyer wrote: I was looking at what is in my mill setup.sh and what is in a setup.sh Frederic Ribble sent me for his lathe on the BBB. Notice one uses P8.12 and the other P8_12 P8.12 out # gpio1.12 X_Step P8_12 out # X Step / DB25.2 I suspect either will work but is there a preferred method? Searching with "BBB setup.sh machinekit" doesn't provide any hits that make sense. Like this one was 2018. Is it too old or too new? https://github.com/machinekit/machinekit/issues/1310 Should I care? The issue is whether you're running the shell script version of config-pin, or the newer compiled version. The shell script was written to be pretty forgiving of pin number syntax and will accept a 2 or 3 digit numeric value, optionally prefixed by "p" or "P", and with an optional separator (any non-numeric character) between the first digit and any remaining digits. Two digit values are assumed to have an implicit zero in the pin number (eg: 82 -> P8_02). I believe the compiled version of config-pin is somewhat more picky about naming conventions, but I haven't used it much. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/1797068e-ac3b-5644-57dd-c010f03d0698%40steinkuehler.net.
Re: [Machinekit] BBB and charge pump
On 4/18/2021 6:08 PM, John Dammeyer wrote: One other question. If the 8xx and 9xx numbers work for the loadrt hal_bb_gpio statement is it possible to also use them for the stepper motor pin selection here: setp hpg.stepgen.00.steppin 0x4C setp hpg.stepgen.00.dirpin 0x4D Changing those to the 8-- and 9-- series would make the hal file more readable. Yes, almost all the hal_pru_generic pins can use the new 8xx/9xx pin numbering scheme. The only exception is the encoder input pins, which require a PRU direct input to function properly. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/50d362e1-52e0-be9e-f17d-230a92d11039%40steinkuehler.net.
Re: [Machinekit] BBB and charge pump
It looks like you have the PRU and the hal_bb_gpio both driving P8 pin 13, so they're stepping on each other. Don't have the hal_bb_gpio driver talk to P8 pin 13 and things should work much better. Also, unless you're using a _really_ old version of hal_bb_gpio, it will probably make more sense to use the newer 8xx/9xx pin numbering scheme like you are for the PRU pins. Warning: lines below will probably wrap...the loadrt command needs to be all one line. So turn this: loadrt hal_bb_gpio output_pins=107,113,119,126,214 input_pins=109,110,114,118,241 ...into this: loadrt hal_bb_gpio output_pins=807,819,826,914 input_pins=809,810,814,818,941 On 4/17/2021 6:14 PM, John Dammeyer wrote: Things are not going well so I've attached the HAL file. I've spent several days on this trying all sorts of different things and finally just reducing the HAL file to as simple as possible. I don't know if the photos would make it through so here are links to them. Didn't have a USB stick handy to save them so I just photographed the entire scope. This one shows 50% PWM to the spindle as the yellow trace. http://www.autoartisans.com/beagle/PWM50_ChgPmp-1.jpg This one should be the same as the one above but isn't 50%. http://www.autoartisans.com/beagle/PWM50_ChgPmp-2.jpg In fact the PWM appears to oscillate at about 2 hz with the falling edge synchronized to either edge of the blue trace which is the charge pump output. I've simplified the HAL file as much as possible. It appears the PWM to the spindle is not being done in hardware and something is preventing it from staying at the requested 50%. It doesn't matter if it's set from AXIS or if I do this. setp hpg.pwmgen.00.out.00.value 25.0 I'm also not sure about this part: # load low-level drivers # Hex values of pins. $6B,$71,$77,$7E,$D6 $6D,$6E,$72,$76,$F1 loadrt hal_bb_gpio output_pins=107,113,119,126,214 input_pins=109,110,114,118,241 loadrt [PRUCONF](DRIVER) prucode=$(HAL_RTMOD_DIR)/[PRUCONF](PRUBIN) [PRUCONF](CONFIG) halname=hpg Depending on which machinekit and BBB web page I read the values for the output_pins have different numbers with the latest supposedly 813 for P8 Pin 13. Setting up the spindle pin I do use 813 which appears to work. However, again according to one of the web pages if I want the PRU to control this I'd use 1813 rather than 813 or 0813. However, no output appears when I use 1813. So I'm still missing something with a hardware generated (or PRU generated PWM that has a period of 1mS.) No matter what I do the PWM oscilates between 0 and 50% synchronized to the edges of the charge_pump. Any suggestions on what to do next? Thanks John From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On Behalf Of John Dammeyer Sent: April-13-21 8:26 PM To: 'Charles Steinkuehler'; machinekit@googlegroups.com Subject: RE: [Machinekit] BBB and charge pump Making progress. Scope shows PWM and DIR on correct pin. Buttons work. + button however increases speed reported value above 3000 RPM when examined with HAL meter even though PWM reached 100% at 3000 RPM. (50 RPS) Still missing something. #(JCD) Add PWM Spindle control # # Spindle # # This output is on DB25-14 setp hpg.pwmgen.00.pwm_period 10 setp hpg.pwmgen.00.out.00.pin 813 setp hpg.pwmgen.00.out.00.enable1 setp hpg.pwmgen.00.out.00.scale 50.0 setp hpg.pwmgen.00.out.00.value 0 net spindle-enable <= motion.spindle-on net spindle-vel-cmd-rps <= motion.spindle-speed-out-rps net spindle-vel-cmd-rpm <= motion.spindle-speed-out net spindle-vel-cmd-rpm-abs <= motion.spindle-speed-out-abs net spindle-cw <= motion.spindle-forward net spindle-ccw <= motion.spindle-reverse net spindle-brake <= motion.spindle-brake net spindle-revs=> motion.spindle-revs net spindle-enable => hpg.pwmgen.00.out.00.enable net spindle-vel-cmd-rps => hpg.pwmgen.00.out.00.value # This output is on DB25-16 and is Spindle Direction. net spindle-ccw => bb_gpio.p8.out-19 # This output is on DB25-17 net charge-pump => bb_gpio.p9.out-14 -Original Message- From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On Behalf Of John Dammeyer Sent: April-13-21 7:46 PM To: 'Charles Steinkuehler'; machinekit@googlegroups.com Subject: RE: [Machinekit] BBB and charge pump That's what I'm trying to get going now. Actually first the PWM for spindle speed and then I'll create the second PWM for charge pump. Having a lot of trouble with the PWM for the spindle. I've added what I think are the correct motion.spindle- ... but all I can get on the AXIS screen are the +/- and STOP button along with the BRAKE checkbox. And the +/- buttons do flip the DB25-16 port pin so that's all working. But the set speed button is missing
Re: [Machinekit] BBB and charge pump
If you just need a charge pump signal, use the PWM function on the PRU (alternately, you could use a stepgen instance, but that's more code overhead). On 4/13/2021 11:56 AM, John Dammeyer wrote: Just an update. I have a 501.9 Hz square wave now coming out DB25-17. The simple answer was that I needed to change to addf charge_pump.0 servo-thread The .0 was the issue. The next issue, and I'm not sure how to get around this is the servo thread is too slow and doing something like this: loadrt threads name1= fast-thread period1=10 is not allowed. Probably because loadrt [EMCMOT]EMCMOT servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[TRAJ]AXES tp=tp kins=trivkins loads 'motmod' which does what 'threads' does. I can try the standard parallel port generated version like: loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[TRAJ]AXES But I'll have to dig deeper to see why that may or may not work. Unless someone has a better suggestion like doing it the way the MESA does with an extra step/dir interface. Next part is I also want 1kHz PWM. The MESA does this with hardware again. Can the BBB can do it with the PRU? If not it will have to also be done with a base thread of about 10KHz. John -Original Message- From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On Behalf Of John Dammeyer Sent: April-12-21 8:52 PM To: 'Machinekit' Subject: [Machinekit] BBB and charge pump I'm using the Xylotex DB25 cape for the BBB. I've been trying to add the charge pump component without much luck. In the HAL file I can do a loadrt charge_pump but an addf charge_pump fails with function 'charge_pump' not found. If I leave that out and run MachineKit on the Beagle I do see charge-pump.0.enable charge-pump.0.out charge-pump.0.out-2 charge-pump.0.out-4 charge-pump.0.func.time charge-pump.0.func.tmax charge-pump.0.func.tmax-inc But since the this HAL file only has a servo thread and no base thread is there a way to get this to work? Ultimately I want the ChargePump output on DB25-17 working in the same way I have the PC with MESA 7i92H # DB25-10 actvive low ESTOP signal mapped to 7i92 pin 13 # Pin# I/O Pri. funcSec. func Chan Pin funcPin Dir # 10 13 IOPort QCount 0Quad-A (In) estop-external-in (input) # MESA 7i92H P2 connections mapped to estop-external-in net estop-external-in <= hm2_7i92.0.gpio.013.in_not # Stepper #4 is the charge pump on the MESA card and is enabled with the estop-external -in net estop-external-in => hm2_7i92.0.stepgen.04.enable which is output on DB25-17 from the MESA pin 7. # 17 7 IOPort StepGen 4Step/Table1 (Out) Charge Pump frequency (output) -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/0a0a01d73018%245f04d6e0%241d0e84a0%24%40autoartisans.com. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/ed9b13ab-776c-8edf-0e25-6393ff289bd3%40steinkuehler.net.
Re: [Machinekit] Re: any info on the spiPRU mentioned
On 2/21/2021 11:58 AM, Doug LaRue wrote: I don't want to start up a Machinekit vs LinuxCNC argument but the developer of Remora has been using LinuxCNC with the 2.8-rtpreempt kernel which seem way out of date. I know this group has been doing Machinekit on the BBB SBC for far longer and for a while were using the Xenomai kernel but switched to the rtPreempt and is using Preempt_rt v4.9 and provides pre-built images. Do any of the developers here see a reason why this SPI implementation can't work with Machinekit and why it might even be better doing it? I don't see why an SPI interface shouldn't work with Machinekit. I also like the fact that, IIRC, devs here created QtQuickVCP which is a better UI system for these SBC implementations. I don't see an current docs for Machinekit on rPi4, only and old one for rPi2/3. It's been quite a while since I built Machinekit from source for the BBB so I've not looked at the current state for doing that on the latest rPiOS. I haven't been building Machinekit much, but I have been doing a lot of work recently on the RPi4. I may be able to help if you get stuck on something. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/b2f9ea5e-bf70-1e0e-3f3b-bf968b737630%40steinkuehler.net.
Re: [Machinekit] BBB + CRAMPS extruder control
an control, if I hack the hpg.pwmgen.00.out.xx.value I can enable them, but not with any pid / feedback control. ( I can confirm the FETs work and the extruder heats and the fan runs via hacking the vaule ) I have checked the thermistor, and it works as expected. What I can't figure out is how to get the commanded temp to go to anything other than 0. I have pre-heat settings, I've tried to use the remaped M codes for 104 and 109 (and 106 for the fan) but I get nothing. My configs are attached, if anyone has a BBB and CRAMPS working for 3D printing, or FET controls I'd love to get your advice. Thanks Pete -- Charles Steinkuehler cha...@steinkuehler.net -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/828a6a61-37e1-a597-f1e1-451091f2c207%40steinkuehler.net.
Re: [Machinekit] BBB + CRAMPS extruder control
There's not really enough detail to determine exactly what's wrong. Since you indicate you can set the hpg.pwmgen.00.out.xx.value signals and get expected results, it sounds like the PRU is properly generating PWM signals. Note that by default the value signal is normalized, so 0.0 is "always off", 1.0 is "always on" and 0.5 is "on half of the time". I do like to explicitly set the PRU period, but I doubt that's causing your problems: https://github.com/cdsteinkuehler/machine-configs/blob/master/configs/CoreXZ/CoreXZ.ini#L3 So if the PWM is working correctly the problem is likely with the PID or temperature code. Use halmeter, halsscope, or just "halcmd show pin" to see what the signals are doing. If you can't tell what's wrong, post some additional debugging from these utilities and maybe we can spot what's going wrong. Finally, one thing that trips up a lot of CRAMPS users is you have a bunch of different power supply connections. There are three different supplies for the CRAMPS FET outputs: P402: EXTPWR (E0, E1, E2) P403: BEDPWR (BEDHTR output) P404: AUXPWR V+ (FET5, FET6) Make sure you have all the necessary supply rails connected. The LED next to the FET output connector should light when the FET is on and power is properly applied. For testing, you can use halcmd to set any signals that are not being actively driven (eg: halcmd setp hpg.pwmgen.00.out.02.value 1.0) without having to edit your HAL file and relaunch. On 1/25/2021 9:58 PM, Pete McKenna wrote: My first attempts at posting haven't worked. I'll post the files if this post works. I have an Ordbot I'm adding BBB+ CRAMPs control too. I have the motion control working reasonably well, but I can't get control of the FETs for the extruder and fan control, if I hack the hpg.pwmgen.00.out.xx.value I can enable them, but not with any pid / feedback control. ( I can confirm the FETs work and the extruder heats and the fan runs via hacking the vaule ) I have checked the thermistor, and it works as expected. What I can't figure out is how to get the commanded temp to go to anything other than 0. I have pre-heat settings, I've tried to use the remaped M codes for 104 and 109 (and 106 for the fan) but I get nothing. My configs are attached, if anyone has a BBB and CRAMPS working for 3D printing, or FET controls I'd love to get your advice. Thanks Pete -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/fc2fabd9-9af7-ce70-a59a-6cad97e44c64%40steinkuehler.net.
Re: [Machinekit] loading hal_arm335xQEP fails with Bus Error
I haven't seen anything like that personally, but I haven't worked much with the eqep modules and anything I have done would be on much older kernels. I recommend asking for help on the Beagleboard group. RCN hangs out here somewhat, but there's a much larger pool of Beagle specific knowledge on their group. I think if you can get the kernel properly loading the eqep driver, things should begin working. On 9/14/2020 2:53 AM, Jacek Radzikowski wrote: Charles, Thank you very much for the suggestion. Checking /sys/kernel/debug/pinctrl/44e10800.pinmux-pinctrl-single/pins showed that indeed, the pinmuxes were not set up correctly (but they were removed from the set of pins universal cape can control). After RTFSing the universal cape overlay I figured out the names of the pins to change (two of the BBB pins used by QEP0 have two processor pins attached), and now I set the muxes using config-pin. Querying the pins using config-pin shows correct configuration, but the muxes in /sys/kernel/debug/pinctrl/44e10800.pinmux-pinctrl-single/pins still don't look right. The pins used by QEP0 are P9_25 (117), P9_27 (115), P9_91 (116) and P9_92 (114). The numbers in parentheses are GPIO numbers. Here are the pin modes reported by config-pin after setting them up: $ for p in P9_25 P9_27 P9_91 P9_92; do config-pin -q $p;done P9_25 Mode: qep P9_27 Mode: qep P9_91 Mode: qep P9_92 Mode: qep Here are the muxes read from the kernel debug interface: pin 114 (PIN114) 44e109c8 0028 pinctrl-single pin 115 (PIN115) 44e109cc 0028 pinctrl-single pin 116 (PIN116) 44e109d0 0030 pinctrl-single pin 117 (PIN117) 44e109d4 0030 pinctrl-single All modes (the last 3 bits) are set to 0, while they shouldn't be. I noticed that early in the boot process kernel throws an exception, which seems to come from the initialization code, probably processing the device tree. Full boot log is in the attachment: [0.281700] [ cut here ] [0.281731] WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:828 clk_core_disable_lock+0x15/0x1c [0.281774] l4_per_cm:clk:00d4:0 already disabled [0.281781] Modules linked in: [0.281798] CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.106-bone-rt-r49 #1stretch [0.281805] Hardware name: Generic AM33XX (Flattened Device Tree) [0.281844] [] (unwind_backtrace) from [] (show_stack+0x11/0x14) [0.281861] [] (show_stack) from [] (__warn+0xb3/0xc4) [0.281874] [] (__warn) from [] (warn_slowpath_fmt+0x33/0x48) [0.281888] [] (warn_slowpath_fmt) from [] (clk_core_disable_lock+0x15/0x1c) [0.281908] [] (clk_core_disable_lock) from [] (_disable_clocks+0x23/0x7c) [0.281925] [] (_disable_clocks) from [] (omap_hwmod_deassert_hardreset+0x81/0xf0) [0.281940] [] (omap_hwmod_deassert_hardreset) from [] (_omap_device_notifier_call+0x1ff/0x340) [0.281956] [] (_omap_device_notifier_call) from [] (notifier_call_chain+0x4b/0x60) [0.281970] [] (notifier_call_chain) from [] (__blocking_notifier_call_chain+0x2d/0x3c) [0.281983] [] (__blocking_notifier_call_chain) from [] (blocking_notifier_call_chain+0x17/0x1c) [0.281998] [] (blocking_notifier_call_chain) from [] (device_add+0x2a3/0x498) [0.282021] [] (device_add) from [] (of_platform_device_create_pdata+0x73/0xa0) [0.282038] [] (of_platform_device_create_pdata) from [] (of_platform_bus_create+0x12d/0x27c) [0.282051] [] (of_platform_bus_create) from [] (of_platform_bus_create+0x177/0x27c) [0.282064] [] (of_platform_bus_create) from [] (of_platform_populate+0x67/0xe4) [0.282087] [] (of_platform_populate) from [] (pdata_quirks_init+0x5d/0x6c) [0.282102] [] (pdata_quirks_init) from [] (omap_generic_init+0x15/0x1e) [0.282126] [] (omap_generic_init) from [] (customize_machine+0x19/0x1c) [0.282145] [] (customize_machine) from [] (do_one_initcall+0x45/0x17c) [0.282160] [] (do_one_initcall) from [] (kernel_init_freeable+0x1a7/0x242) [0.282182] [] (kernel_init_freeable) from [] (kernel_init+0xd/0xdc) [0.282197] [] (kernel_init) from [] (ret_from_fork+0x11/0x30) [0.282205] Exception stack(0xdc115fb0 to 0xdc115ff8) [0.282215] 5fa0: [0.282228] 5fc0: [0.282238] 5fe0: 0013 [0.282246] ---[ end trace 0001 ]--- All of this with the board running the stock kernel from the image: Linux machinekit 4.19.106-bone-rt-r49 #1stretch PREEMPT RT Wed Mar 11 10:50:28 UTC 2020 armv7l GNU/Linux And I still get bus errors when loading the module. Does it look like something you've encountered in the past? Thank you, Jacek. On Sun, Sep 13, 2020 at 9:26 AM Charles Steinkuehler < char...@steinkuehler.net> wrote: Double-check your device tree setup. The error "external abort on non-linefetch" almost always means the underlying hardware i
Re: [Machinekit] loading hal_arm335xQEP fails with Bus Error
Double-check your device tree setup. The error "external abort on non-linefetch" almost always means the underlying hardware is not responding, typically because it's not been setup (taken out of reset, clock enabled, etc) by the kernel. On 9/13/2020 2:33 AM, Jacek Radzikowski wrote: Hello, Loading hal_arm335xQEP with loadrt causes rtapi_app to crash with bus error: Sep 13 07:22:29 machinekit rtapi:0: 1:rtapi_app:5330:user signal 7 - 'Bus error' received, dumping core (current dir=/home/machinekit) Sep 13 07:22:29 machinekit kernel: [ 440.186026] Unhandled fault: external abort on non-linefetch (0x1818) at 0xb6f041a8 Sep 13 07:22:29 machinekit kernel: [ 440.186041] pgd = bf066d95 Sep 13 07:22:29 machinekit kernel: [ 440.186045] [b6f041a8] *pgd=9c782831, *pte=48300343, *ppte=48300833 Sep 13 07:22:29 machinekit rtapi:0: 1:rtapi_app:5330:user --- rtapi_app backtrace: --- Sep 13 07:22:29 machinekit rtapi:0: 1:rtapi_app:5330:user ERROR decoding backtrace: no debug info in ELF executable (-1) Sep 13 07:22:29 machinekit rtapi:0: 1:rtapi_app:5330:user ERROR decoding backtrace: no debug info in ELF executable (-1) Sep 13 07:22:29 machinekit rtapi:0: 1:rtapi_app:5330:user ERROR decoding backtrace: no debug info in ELF executable (-1) Sep 13 07:22:29 machinekit rtapi:0: 1:rtapi_app:5330:user ERROR decoding backtrace: no debug info in ELF executable (-1) Sep 13 07:22:29 machinekit rtapi:0: 1:rtapi_app:5330:user Sep 13 07:22:30 machinekit msgd:0: rtapi_app exit detected - scheduled shutdown Sep 13 07:22:32 machinekit msgd:0: msgd shutting down I used the following commands to load the module: $ halrun msgd:0 stopped rtapi:0 stopped rtapi_msgd command: /usr/libexec/linuxcnc/rtapi_msgd --instance=0 --rtmsglevel=1 --usrmsglevel=1 --debug=1 --halsize=524288 rtapi_app command: /usr/libexec/linuxcnc/rtapi_app_rt-preempt --instance=0 --debug=1 halcmd: loadrt hal_arm335xQEP encoders=eQEP0 :1: insmod failed, returned -1: rtapi_rpc(): reply timeout halcmd: Pin modes are set up by loading bone_eqep0-00A0.dtbo by uboot, audio overlay (with conflicting pins) is disabled. System has been installed from bone-debian-9.12-machinekit-armhf-2020-05-02-4gb.img, and kernel updated to 4.19.135-bone-rt-r55 I tried to google the problem, but couldn't find any information. I will appreciate any ideas on how to make the module work. Thank you, Jacek. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/8ae2751e-9c8f-df95-5ffc-b49a4ba6ba7c%40steinkuehler.net.
Re: [Machinekit] Bamboo cnc/limit switch errors
ention what type of limit switches you're using or how your spindle works. The Y axis itself shouldn't be under any special stress while cutting but the spindle generally takes a hard hit as soon as a tool enters the cut. Is the spindle motor powered by the same power supply your switches are on? Supply could be dropping low. Is the machine not ridgid and vibration tripping the switches? On Tue, Jul 21, 2020, 8:54 AM Mason Millner wrote: Hi All, We are developing a 4-axis CNC to mill bamboo poles and are currently running tests in just three axis (x, y, z). We can dry-run g-code files successfully, however we receive limit switch errors (primarily on joint 1) when we begin cutting material. We suspect that the error is occuring in the y-axis and that possibly our drivers are causing a problem (either they are too small or not tuned adequately).. It is difficult to tell what is going on and how the machine is configured from the information given. We have the z-axis running on the long x-axis, running on two shorter dual y-axes. The axis shaft is a ½” (12.7mm) , also the motor shaft is ¼” (6.35mm). we are using polyurethane insert couplers (these have regularly been coming loose though). The motors are NEMA 23s with 3A rating/phase controlled by Pololu TB67S249FTG drivers on a Cramps 2.2 cape on the Beaglebone Black. The drivers have a current limit of 1.6A and are further limited to %90 for safety. The Current limit for the board and drivers are defiantly a bottle neck, but the motors have enough power to operate. [Could this be the problem?] Any help or recommendations would be greatly appreciated. If more information is needed please let me know. I'm fairly new to the machine development side of this project. Thanks. -- 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 machinekit+...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/790379d8-160b-4fed-9fa2-d03cbe160926n%40googlegroups.com <https://groups.google.com/d/msgid/machinekit/790379d8-160b-4fed-9fa2-d03cbe160926n%40googlegroups.com?utm_medium=email_source=footer> . -- 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 machi...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/8c6cb16c-03d6-4c1c-8cc5-0d8ad5012849n%40googlegroups.com <https://groups.google.com/d/msgid/machinekit/8c6cb16c-03d6-4c1c-8cc5-0d8ad5012849n%40googlegroups.com?utm_medium=email_source=footer> . -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/27800497-4c6e-b0e3-857f-248433e8784d%40steinkuehler.net.
Re: [Machinekit] Re: HM2 Clocking
I believe the determination as to which clock frequency to use for a specific hardware module would be made based on the requirements for that specific module and the available clock frequencies. This is less of an issue in today's world than it used to be...with all the PLLs available on modern FPGAs designs aren't really limited to the one or two clock frequencies being generated by on-board oscillators. As for the specific frequencies and such used in the mksocfpga configurations, this mostly came about as a more-or-less direct clone of the 5i25 configuration (but with twice as many available I/O connectors). If you need something different, it should be pretty straight-forward to migrate one of the other Mesa board configurations but you might need to update the PLL configuration (which is at the top level and outside the HM2 stuff). On 7/19/2020 1:14 PM, pcwcol wrote: On Saturday, July 18, 2020 at 4:06:45 PM UTC-7, Cameron McQuinn wrote: Hi all, I am looking to gain a better understanding of how the clocking for the Hostmot2 firmware works in mksocfpga. In the Vivado block diagram, the hostmot2_ip_wrap module has 3 clock ports: clklow, clkmed, and clkhigh. The TCL scripts to generate the Vivado projects all connect clklow and clkmed together. Clkmed and clklow connect to a 100MHz clock, and clkhigh connects to a 200MHz clock. Where did these numbers come from? Also, in the PIN_X file for each configuration, each module has an associated clock tag. For instance, in PIN_ULTR_36.vhd, the PWM module has the ClockHighTag ( https://github.com/machinekit/mksocfpga/blob/master/HW/VivadoProjects/avnet/ultra96/const/PIN_ULTR_36.vhd#L83). Is there some place in the HM2 code that defines what clock tag each module should have? Thanks, Cameron Not sure about mksocfpga but in general the clocking setup is pretty simple, the top level (card specific) file generates the various clocks from the clock source ( via DCM, PLL etc depending on hardware) These are simple fixed hardwired frequencies for a given card. Card specific constants (on IDROMConst.vhd) are used to simply pass the fixed hardware clock frequencies to the hm2 driver for its frequency based calculations The clock tags that specify which clock a module uses (for determining I/O frequencies) is in the module ID section of the pinout file:PIN. vhd -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/f9035d6d-e39c-44da-2b78-541f11727486%40steinkuehler.net.
Re: [Machinekit] Machinekit + Ros for Scorbot Er-3
Well, I'd say if the controller is running an 8031, it's already been lobotomized! :) More seriously, unless there's a serious desire to work with the low efficiency bipolar drive transistors and spend a bunch of time reverse engineering the internal hardware, you'll be much better off just scrapping the controller and hooking the 50-pin robot cable to something much newer. The Mesa 7i54 would be pretty much ideal and could connect directly to the robot. Lots of other options are available depending on what you want to use for motor drivers and where you want to close the servo loop. On 5/3/2020 1:18 PM, Tom M wrote: Hi Guys, Members of our hackerspace Workshop 88 <http://www.workshop88.com/> have acquired 3 Scorbot Er-3 with controllers.We've tested them out and the bot's who we've named Huey, Dewey and Louie all seem to be working well. We'd like to use Ros on those bots, but the issue is how to get there. I was reading Alex Rössler post about machinekit and Ros at https://machinekoder.com/machinekit-ros-open-source-robots/ and it seems like this might be an approach worth trying. Seb Kuzminsky used linuxcnc on a scorbot Er-3 with the existing control https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/user_comps/scorbot-er-3.py https://github.com/LinuxCNC/linuxcnc/tree/master/configs/by_machine/scorbot-er-3 I've been corresponding with him on this and he said that this approach resulted in jerky motion since linuxcnc was communicating of a 9600 baud serial line. He wound up replacing the control and creating a new controller with Mesa 7i43 (EPP Hostmot2 card), a Mesa 7i54 (Six channel 3A 40V Servo interface), We've been toying with a couple approaches: One approach would be to replace the controller and build a servo interphase using arduino nano's and a L298 motor drivers: https://www.youtube.com/watch?v=vHufLMh4xEI and either use a pc or bbb to handle the motion planning. We've been studying the Scorbot controller and it is well made and fully socketed. We were thinking that we could lobotimizing the control by yanking the 8031 control. 15 pins basically access everything on the board. It would be sort of cool, if we could create a cape and socket adapter and just plug in a bbb to the control and get it to run. We're still in the process of figuring out the motor drivers and the encoders. Have people done this sort of thing is a dumb idea? Is machinekit via a BBB able to handle this type of multiplexing out of the box or with minor modification or would this be a major modification and a cludge not worth doing? If there is a project that's done this already, could someone point me to a project that I could template from? Any thoughts on this would be appreciated, Thanks, Tom -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/945ed1b4-19f3-f8a2-ba78-26dc57033fb4%40steinkuehler.net.
Re: [Machinekit] C instantiable components and hal_pru_generic
Hal_pru_generic was meant to be generic, not fast, which is why I put "generic" in the name. :) I had generally intended to make a "fast" version, but never needed to (the existing PRU logic can drive my 3D printer step/dir drivers faster than they can accept pulses already!). Probably the first step for improved performance would be getting the HAL driver to support multiple PRUs, either using one driver, or perhaps by making the driver an icomp so you could run multiple instances. This would let you divide up the work across the PRUs so you could run a faster cycle rate on each one since it's not doing all the work. Next would be crafting some new PRU "tasklets" that are less generic than what's currently implemented. Options would be to only support PRU direct IO, only support one or two GPIO banks instead of 4+, possibly unroll some loops to avoid branch/jump (eg: make a 5 stepgen tasklet instead of using the stepgen tasklet 5 times). This might also be the easiest solution if you think you can get the performance you need out of a single PRU. The final step would be dropping most or all of the existing PRU tasklet framework and writing something that specifically does *JUST* what you need, and spread that across several PRUs, eg: Run a 2 stepgen task across 3 PRUs and get 6 step/dir outputs. On 4/30/2020 6:14 PM, John Allwine wrote: I'm not convinced of that. Since the register table is fully allocated it would likely require swapping registers out to scratch pads and assigning pin numbers that are larger than a byte (this would significantly affect the SET_CLR_BIT and PINTABLE implementation) and at the very least adding twice as many memory writes. I don't fully understand the ramifications of making some of those changes, but it would certainly have a performance penalty by writing to more registers, even if it is easy to implement. I'm concerned with performance, so any modifications that slow down hal_pru_generic I'd like to avoid. I'm trying to reach high step frequencies with 5 different axes. I'm hoping to achieve them with hal_pru_generic, so I'm thinking of even adding build macros so hal_pru_generic could have access to PRU code that doesn't perform any memory writes (but rather uses only direct outputs). I'm still testing what's feasible, but being able to divide up that work between different PRUs could also be key, so I like the idea of hal_pru_generic being instantiable. On Thursday, April 30, 2020 at 3:28:51 PM UTC-6, Charles Steinkuehler wrote: I think it would be easier to extend the existing logic to simply write to more registers, but an icomp version of hal_pru_generic could still be helpful. With four PRU cores in the BBAI, I can definitely see the benefit to having more than one PRU running either to divide the work or to allow the PRUs to run with different cycle times. On 4/29/2020 10:13 PM, John Allwine wrote: Is there documentation on how to write an instantiable HAL component in C? I’ve been making modifications to hal_pru_generic to work on the BeagleBone AI. hal_pru_generic is implemented in such a way that only 4 GPIO ports can be used. The BBB only has 4 GPIO ports, so any pin on the P8 and P9 headers can be used on a single instance of hal_pru_generic. The BeagleBone AI has 8 GPIO ports, so without significant changes to hal_pru_generic, not all pins on the P8 and P9 headers can be accessed from a single instance. The BeagleBone AI does expose many more pins as direct outputs, but I’m unable to instantiate more than one instance of hal_pru_generic in order to take advantage of certain pin configurations. Is it possible to make hal_pru_generic instantiable? -- Charles Steinkuehler cha...@steinkuehler.net -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/49ad94d8-1d0d-2477-5980-ce50eeb80378%40steinkuehler.net.
Re: [Machinekit] C instantiable components and hal_pru_generic
I think it would be easier to extend the existing logic to simply write to more registers, but an icomp version of hal_pru_generic could still be helpful. With four PRU cores in the BBAI, I can definitely see the benefit to having more than one PRU running either to divide the work or to allow the PRUs to run with different cycle times. On 4/29/2020 10:13 PM, John Allwine wrote: Is there documentation on how to write an instantiable HAL component in C? I’ve been making modifications to hal_pru_generic to work on the BeagleBone AI. hal_pru_generic is implemented in such a way that only 4 GPIO ports can be used. The BBB only has 4 GPIO ports, so any pin on the P8 and P9 headers can be used on a single instance of hal_pru_generic. The BeagleBone AI has 8 GPIO ports, so without significant changes to hal_pru_generic, not all pins on the P8 and P9 headers can be accessed from a single instance. The BeagleBone AI does expose many more pins as direct outputs, but I’m unable to instantiate more than one instance of hal_pru_generic in order to take advantage of certain pin configurations. Is it possible to make hal_pru_generic instantiable? -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/06fff1e3-924b-73a7-9d12-676f3f023330%40steinkuehler.net.
Re: [Machinekit] Start / Continue button
If you're not using all the limit switch connectors, the easiest thing would be to just connect one of those to your button. You would turn it into a start/continue button via HAL wiring. Also, I'm not familiar with the Protoneer boards you're using, got a link? If they are just straight wiring, like these: https://www.ebay.com/itm/Pololu-connector-socket-converter-jumper-board-for-External-Driver/202696098969 ...be very careful. There is no buffering on the CRAMPS board for the step/dir signals, so these will be low drive 3.3V logic directly connected to the BeagleBone. It is *VERY* easy to fry the BBB if you ever go above 3.3V or below Gnd on these I/O signals. On 4/11/2020 11:01 PM, Hong Mai Ha Osterstrom wrote: I am using a Beaglebone / CRAMPS 2.2 cape fitted with Protoneer ‘Pololu Socket To External Driver conversion boards’ to provide signals to the large drivers and steppers on my (bigger-than-a-Bridgeport) retro-fitted Induma mill. The X and Y axis's are working as they should so I can use the mill in 2 axis mode to build the mounting hardware for a CNC quill feed to give me a Z axis. Every thing is going fine but I really, really miss having a working ‘Start / Continue’ button right next to the big red E-Stop button on the head of the mill. I have a fun little 3D printer so I quite understand why the CRAMPS cape doesn’t need to implement such a button but I am dealing with several hundred pounds of Iron moving at 4+ inches a second. Mousing about on a simulation of what I hope is happening is not the same as facing what is really happening with my thumb hovering over the E-Stop button. I ran LinuxCNC on a friends mill in the late 1990s and it had a real ‘Start / Continue’ button. Did that capability get carried over into Machinekit and if so, where does it emerge on the Beaglebone? I already have a pair of 2 X 23 stacking headers between the Beaglebone and the CRAMPS cape to improve cooling so it would be no big deal to add a breakout board. Any information would be welcome. By the way, I am using my wife's account. My name is Gordon Osterstrom -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/fd2f9282-c80e-b901-a73f-a777e8c9dee4%40steinkuehler.net.
Re: [Machinekit] Seeed to design and build Machinekit focused Cape for BeagleBone Black/AI
This depends a lot on what sort of machine you're trying to drive. A "standard" CNC machine with step/dir typically needs a DB25 (aka: parallel port) with buffered signals you can connect to external stepper drivers. A 3D printer would more typically have low-powered "Pololu" style drivers either on-board or via sockets along with some high power outputs for the extruder and bed heaters. A more advanced system might provide a control signal (+/- 10V, or perhaps PWM) to drive a motor driver and provide for encoder feedback to close the servo loop. ...so it really depends on what sort of system(s) you want to support, and how much you want to try to be a "one size fits all" solution. On 3/12/2020 8:38 AM, Jason Kridner wrote: Seeed is looking to not only build a Machinekit-focused Cape for BeagleBone Black and BeagleBone AI, but to: * Take in features and feedback from the community * Contribute the design to open source and certify it as such * Manufacture the design under the BeagleBoard.org name to support the BeagleBoard.org Foundation and community * Help assemble and provide software images configured for an open source 3D printer and CNC machine (with BeagleBoard.org and community guidance and support) * Offer a collection of additional accessories which might commonly be needed I am very excited about this because I know Seeed cares about open hardware and also knows how to deliver solutions reliably and cost effectively. So, what are your ideas about where to start on such a cape? -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/0db7068a-dba9-fe07-8961-d1adc079aed4%40steinkuehler.net.
Re: [Machinekit] BeagleBone with Cramps X stepper vibrates but does not move
On 3/12/2020 7:17 AM, John Hammond wrote: The Y and Z steppers rotate but the X one does not. I have switched the Polulu driver from the X to Z and it works fine. Where is the pulse rate determined in Linux? Does Machinekit have linuxcnc files that I haven’t seen? Typically the pulse rates will be determined by settings in your HAL file. Using the BBB, it is quite easy to generate rates so high you overwhelm the stepper driver and get no actual movement from the steppers. Often, this is an issue with the scale values, but there can be other causes as well. Provide your HAL and INI config files, and we can review. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/00ac397a-ed83-435e-4a72-bd31aeda409f%40steinkuehler.net.
Re: [Machinekit] Re: 4-axis CNC running Machinekit won't fully home.
1) Setup homing so each axis homes sequentially. Then if you have errors, you'll know exactly which axis you need to fix. 2) You're using a gantry component, but it's unclear exactly how it's setup. You appear to be using the Y-min and Y-max switches as the two homing switches for the gantry axis? Some sort of machine or wiring diagram would help to diagnose any potential problems with your config. 3) Provide a dump of the HAL state when the system has homed one of the axis and stopped (eg: the output of "halcmd show"). On 2/29/2020 8:15 PM, Nathaniel wrote: Thanks Justin, I took your advice and played with the home and home offsets. It now fully disengages from the switch while homing, but this hasn't solved the problem. It will home whichever axis is crossest to its switch and then stop. Any suggestions? Thanks, Nathaniel -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/2f859f0d-b7f6-aef0-7da8-a79eb27e395b%40steinkuehler.net.
Re: [Machinekit] PICnc with Machine Kit.
I am allergic to PIC chips and 8051 derivatives. ;-) On 2/27/2020 12:42 AM, John Dammeyer wrote: This project seems to have lapsed 5 years ago. https://github.com/kinsamanka/PICnc-V2/wiki Any interest in resurrecting it? John Dammeyer "ELS! Nothing else works as well for your Lathe" Automation Artisans Inc. www dot autoartisans dot com -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/ee24f2ef-890f-82eb-c667-8f6290448ec3%40steinkuehler.net.
Re: [Machinekit] Re: DE10 Nano suggested development environment?
I don't currently have a DE10-Nano running, but I reviewed the code and
it looks like you should be able to set the resolution the same as you
would for any other embedded display (by passing some kernel
parameters). Refer to:
* The modedb documentation:
https://www.kernel.org/doc/Documentation/fb/modedb.txt
* My posts on setting resolutions on the BBB:
http://blog.machinekit.io/2013/06/force-beaglebone-black-hdmi-resolution.html
http://blog.machinekit.io/2013/07/custom-hdmi-resolution.html
I think you just need an entry similar to the following in your kernel
command line:
video=800x480M@60
Are you using an available uSD card image? If so, I can pop it into my
DE10 and try to get it working with one of my small HDMI based LCD
screens if the above doesn't work for you.
On 2/16/2020 7:46 PM, justin White wrote:
Been away from this project for a short bit but I had a pretty good use
come up for it recently. Main thing I'm having a problem with is the FB
resolution that was configured, 1024x768 is a dead resolution. Only old
monitors natively support it and nothing with HDMI does. Larger HDMI
monitors can handle it but nothing in the 7-9" range can display it through
HDMI. That's unfortunate because the main reason for FB use with this thing
is for an HMI all in one type device. Is there any chance more monitor
resolutions can be supported?
I asked this before and MB responded, but unfortunately this is over my head
OK back to being able to be online with my workstation:
I have allways had a fight setting up proper display resolutions on the
altera soc's however I can give you some key notes:
In qsys there are 3 cores to consider:
For display timing settings:
alt_vip_vfr_hdmi (framereader)
alt_vip_itc_0 (Clocked video output)
The display core clock itself:
pll_lcd --> lcd_clk
1600x900 would allow me to test it out on my mill and I might have a use
for 800x480. I didn't realize the resolution was fixed, my 1080P monitors
don't have a problem displaying 1024x768, all my other monitors do. I
suppose in a real usage scenario I'd have to look further into your
previous reply and try to figure out how to set a resolution for whatever
monitor I intended to use.
Sadly there are currently no presets for these 2 resolutions for the
framebuffer related cores (presets are found in qsys view menu), as I
havent had use of these resolutions myself (in newer time).
And I also have no (qsys) formula other than intuitive guess work.
Last there is the Devicetree entry this is the current one:
https://github.com/the-snowwhite/soc-image-buildscripts/blob/master/SD-Image-Gen/patches/4.9.76-ltsi-rt/current/0012-Added-DE-10-Nano-with-uio-with-without-framebuffer-1.patch#L291
This entry:
vip@0x100031000 {
compatible = "altr,vip-frame-reader-1.0", "ALTR,vip-frame-reader-9.1";
reg = <0x0001 0x00031000 0x0080>;
max-width = <1024>;
max-height = <768>;
bits-per-color = <0x8>;
colors-per-beat = <0x4>;
beats-per-pixel = <0x1>;
mem-word-width = <0x80>;
};
--
Charles Steinkuehler
char...@steinkuehler.net
--
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 machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/machinekit/44b54b20-97af-8ed7-5a7c-56321da87915%40steinkuehler.net.
Re: [Machinekit] Re: OSHW release DE10-Nano Daughtercard
Congratulations, indeed, that's a very nice looking board!!! I would suggest adding some PDF files to your github repo, at least for the schematic. I wanted to review the design, but not enough to clone the repo and install the newer version of Kicad I'd need. :) Also a lot of potential users are unlikely to have Kicad installed, but can probably read a schematic. On 9/24/2019 3:49 PM, Michael Brown wrote: > So Mksocfpga is having babies, @Justin congrats with the (first ?) > mksocfpga oshw daughtercard release :-) > Michael > > On Monday, 23 September 2019 17:02:56 UTC+2, justin White wrote: >> >> [image: DE10nano interface.jpg] >> >> [image: Photo Sep 23, 10 50 34 AM.jpg] -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/f57204c4-cd19-2b19-9bbc-962d2464db6d%40steinkuehler.net.
Re: [Machinekit] Re: Broken CRAMPS.bbio
On 9/2/2019 2:11 PM, Robert Nelson wrote: > On Sat, Aug 31, 2019 at 9:52 PM c.glas...@cox.net > wrote: >> >> It's very clear that at some fairly recent time a decision was made to muck >> with P9_25. Why? > > P9.25 is hdmi audio.. Disable HDMI audio per the BBB U-Boot overlay instructions: https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Disable_on-board_devices -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/f57a7ea3-d73b-3600-2254-417d9c516955%40steinkuehler.net.
Re: [Machinekit] Re: Broken CRAMPS.bbio
On 8/28/2019 12:40 AM, c.glas...@cox.net wrote: > > since CRAMPS.bbio has in the first few lines > > overlay cape-universal > overlay cape-bone-iio > > However there is no cape-bone-io in /lib/firmware, further removing the > reference to it in CRAMPS.hal will again produce > > halcmd loadusr io started > Waiting for /sys/class/uio/uio0 These are all legacy tests from when there were actual device tree overlays that could be dynamically loaded at run-time and it could take a few seconds for the device nodes to show up. If the system is waiting for /sys/class/uio/uio0 it means you don't have the PRUs properly enabled. Make sure you have the PRU UIO device (*NOT* remoteproc) enabled via u-boot. It's the last entry here: https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_PRU_Options -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/20e23f82-a7b4-abdf-1a71-cdafc8dea96f%40steinkuehler.net.
Re: [Machinekit] Re: Rpi3, Beagleboard X15, And Avnet Ultra96
On 8/27/2019 12:16 PM, Michael Brown wrote: > @Charles: > > NOTE: I have a uSD image that's "Plain ole Debian" if you want >> something more generic to work with than the Xilinx AI SDK. It's for >> the ZCU104 but you should be able to use it as-is with the Ultra96 if >> you swap out the boot files (kernel, device-tree, & U-Boot). Let me >> know if you're interested. > > Swapping out the BOOT.BIN and adding image.ub from the U96 petalinux bsp to > the AI image > gives about 1 min of gui access before rebooting, re-placing the rootfs > with the petalinux one fixes the reboots, however ...too minimal Make sure the device tree is copied over as well. Depending on the setup the device tree can be in the BOOT.BIN file, in image.ub, a separate file, stored in raw sectors on the boot media, etc. > I think its time to make that call, for your "Plain ole Debian" rootfs. > Is it Stretch ? Yes, it's stretch but it probably wouldn't take much to migrate to Buster. I'll PM you a link to the uSD images. If you (or anyone else) is interested in the source (I've got scripts for building full working uSD images for the Zybo-Z7-20 and ZCU104 from scratch), follow along below: Hit the following link, scroll to the bottom, and click the download link for the Embedded SDK: https://www.newtek.com/ndi/sdk/ After installing the SDK, the uSD README file has the links to the images. The scripts for building the uSD Image are in the fpga_reference_design/os_uSD/ directory. The root filesystem is virtually identical for both images, one's just armhf and the other is aarch64. They are almost bone-stock Debian installs, with a few minor tweaks here and there (mostly customizing the login prompt & such) as well as a couple "magic" bits you'll likely want to keep (like generating ssh keys and resizing the uSD partition on first boot). Depending on how the 96 boards image is setup, it may be easier to copy the boot loader & such onto my uSD images, or it may work better to copy (rsync) the contents of the rootfs onto their image. My Debian rootfs system is agnostic with regards to where it lives, as long as you pass an appropriate root= command to the kernel. :) -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/fcba8541-f261-138e-2896-9eb1efe1b162%40steinkuehler.net.
Re: [Machinekit] Re: Broken CRAMPS.bbio
On 8/26/2019 11:07 PM, c.glas...@cox.net wrote: > AXIS comes up fine but NOBODY is home, nothing moves it's as though the > CRAMPS board is not even there. > > Is the uEnv.txt file correct? Any other suggestions as to resolving the > absence of functionality? Usually the "totally dead" symptom results from not having one of the CRAMPS power rails connected. In addition to the 5V coming from the BeagleBone, you need to have some/all of the following power rails connected: P201: Motor power (for the Pololu stepper drivers) P401: Bed power (for the heated bed output: P403) P402: Ext power (for the extruder outputs: E0-E2) P404: Aux power V+ (for low-power outputs: FET5-FET6) Also check your ESTOP chain and the status of the LEDs: BB ON : Should always be on STATUS: Application dependent (driven by GPIO pin) ACTIVE: Should be on when machine power is active (F2) ESTOP : Should be on until the machine is out of ESTOP (F1) -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/eb30eb12-2576-30a7-54da-95879da791e4%40steinkuehler.net.
Re: [Machinekit] Re: Rpi3, Beagleboard X15, And Avnet Ultra96
On 8/24/2019 5:19 AM, Michael Brown wrote: > Now having some experience with Vivado and the Ultra96 I'm thinking of > following up on this.. > Xilinx has a Ultra96 Debian buster image online here as a starting point: > https://www.xilinx.com/products/design-tools/ai-inference/ai-developer-hub.html#edge Looks like an interesting board. The Ultrascale+ parts are really nice to work with. I support a ZCU104 design for my Day Job that runs video compression/streaming between the HDMI ports and Ethernet. NOTE: I have a uSD image that's "Plain ole Debian" if you want something more generic to work with than the Xilinx AI SDK. It's for the ZCU104 but you should be able to use it as-is with the Ultra96 if you swap out the boot files (kernel, device-tree, & U-Boot). Let me know if you're interested. > Next to find out how to install (aarch64) ARM64 Machinekit. > Are there yet arm64 Machinekit packages online ? > Or > What are the commands for building mk-hal/cnc from source (been a while > since I last built debs...) It's been ages since I've compiled from source. I always just look at the CI files and do it manually: https://github.com/machinekit/machinekit/blob/master/.travis.yml#L92 https://github.com/machinekit/machinekit/blob/master/scripts/build_docker -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/1d4ea6a5-2369-e928-5332-0376f4e88151%40steinkuehler.net.
Re: [Machinekit] Couple questions about the PRU(s)
On 8/20/2019 11:37 AM, mlampert wrote: > It seems that hal_pru_generic can use any IO pin as an input or an output. > Is there still any advantage to use one of the PRU specific io pins? There is little to no value in using PRU direct output pins vs. GPIO pins for output signals (eg: step/dir/pwm). There is still a strong preference to use the PRU direct input pins, which can be read "instantly" (1 PRU clock) vs. reading from the GPIO registers which stalls the PRU core for a few hundred nS while the read makes it's way through the on-chip interconnect fabric. Note the PRU encoder component requires the use of PRU direct inputs for this reason. > Also, I read somewhere that MK can only use one pru. Assuming that is > correct, does anybody know where the restriction comes from? It isn't really a restriction so much as there has not been anyone who needed/wanted to use both PRUs. I had planned a "non-generic" version of PRU code to do _really_ high-speed step generation or encoder monitoring, but it was never really necessary...the hal_pru_generic code runs fast enough for most of what I need (and often faster than the stepper drivers will support!). I do have a personal setup with the hal_pru_generic code running on one PRU and custom PRU code running on the other PRU (making use of the PWM & UART present in the PRU module to generate some custom pulse sequences), so it's definitely possible. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/77f79ad3-0c9a-f9f6-4bf6-76524647f1e7%40steinkuehler.net.
Re: [Machinekit] Re: DE10 Nano suggested development environment?
Dig through the synthesis log (*.map.rpt) a bit and look for warnings that indicate undriven nets. Sadly, most tool chains consider undriven signals a warning vs. an error, so they'll happily optimize away huge chunks of your design. A typical warning would look something like: Warning (10541): VHDL Signal Declaration warning at HD_Core_CycloneV_pipen1b.vhd(45): used implicit default value for signal "clk250_out" because signal was never assigned a value or an explicit default value. Use of implicit default value may introduce unintended design optimizations. In vim, I use the regex: ^Warning.*$ which highlights the whole line (if you're in GUI mode). Note you will see lots of other warnings, most of which are probably OK. In particular, the ever present: Warning (10036): Verilog HDL or VHDL warning at HD_Core_CycloneV.vhd(471): object "HDMI_clk" assigned a value but never read ...is (usually) perfectly OK, it's similar to an unused variable in "C". This _might_ be an actual error (if the signal was supposed to go somewhere) but is typically OK. On 8/20/2019 9:09 AM, justin White wrote: > Thanks for the advice Charles. Actually I use this project: > https://github.com/machinekit/mksocfpga/tree/master/HW/QuartusProjects/DE10_Nano_FB_Cramps > > Michael explained it has more functionallity than the DB25 project, so I've > never tried the DB25. > > Not really up on my git stuff, I forked master and slapped my config files > in, like I said these are modifications of the "3x24_cap_enc" config. > https://github.com/blazini36/mksocfpga > > The pin assignments are so different from anything else I can't imagine > it's looking at another pinfile, it's likely I just didn't modify something > I probably should have. I'll try to look into your suggestions a bit later. > > > On Tuesday, August 20, 2019 at 9:41:57 AM UTC-4, Charles Steinkuehler wrote: >> >> It sounds like the synthesis tools are optimizing away the stepgen >> logic, almost certainly because of an issue with signal connectivity >> to the top level I/O pins. The actual step accumulator is still >> generated because it's value gets read back via the register >> interface, but the steptables are only needed to generate the output >> signals so they're getting optimized away. >> >> Is your project checked into github somewhere I can grab it? I can >> try building in the desktop Quartus tools and see what's wrong. >> >> Otherwise, double-check the pin assignments the top-level I/O port >> definitions, and make sure the physical I/O pins are properly >> connected to the hm2 instance. >> >> I took a quick look at the project I think you're using: >> >> >> https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/ >> >> >> ...and the top-level stuff looks OK at first glance. The important >> part is the use of the correct PIN_ library, which gets called >> out here: >> >> >> https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/hostmot2_cfg.vhd.in#L74 >> >> >> Make sure in your working copy the hostmot2_cfg.vhd file is getting >> generated with the correct name in the "use" line, and make sure the >> pin file you're including in the project has proper values for IOWidth >> and IOPorts. >> >> You can dig through the first part of the compile log messages to >> verify the correct PIN file is _really_ getting analyzed and not some >> other file. >> >> I'm also not sure how mixing the system verilog config files with VHDL >> packages works (I know just enough Verilog to generally be able to >> transcode it to VHDL). If there's any problems with that, Michael B. >> will have to comment. >> >> On 8/20/2019 8:04 AM, justin White wrote: >>> I deleted my mksocfpga directory and re-pulled it and I get the same >>> results after building the .rbf. >>> >>> Still not quite sure what's going on, though I did catch something in >>> Quartus. Using "0A" for stepgens in the pinfile creates 10 stepgens, >> but >>> only the first 4 seem to be complete. #4 (the 5th stepgen) when expanded >>> shows blank resources for "SRL16E:\steptable:0:asr16e", but does show >>> resources for "SRL16E:\steptable:1:asr16e". On every stepgen after they >> are >>> both blank which looks like it mimics exactly the problem I'm having. If >> "steptable:1" >>> relates to the dir pin and "steptable:0" relates to the step pin, it >>> explains why I
Re: [Machinekit] Re: DE10 Nano suggested development environment?
It sounds like the synthesis tools are optimizing away the stepgen logic, almost certainly because of an issue with signal connectivity to the top level I/O pins. The actual step accumulator is still generated because it's value gets read back via the register interface, but the steptables are only needed to generate the output signals so they're getting optimized away. Is your project checked into github somewhere I can grab it? I can try building in the desktop Quartus tools and see what's wrong. Otherwise, double-check the pin assignments the top-level I/O port definitions, and make sure the physical I/O pins are properly connected to the hm2 instance. I took a quick look at the project I think you're using: https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/ ...and the top-level stuff looks OK at first glance. The important part is the use of the correct PIN_ library, which gets called out here: https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/hostmot2_cfg.vhd.in#L74 Make sure in your working copy the hostmot2_cfg.vhd file is getting generated with the correct name in the "use" line, and make sure the pin file you're including in the project has proper values for IOWidth and IOPorts. You can dig through the first part of the compile log messages to verify the correct PIN file is _really_ getting analyzed and not some other file. I'm also not sure how mixing the system verilog config files with VHDL packages works (I know just enough Verilog to generally be able to transcode it to VHDL). If there's any problems with that, Michael B. will have to comment. On 8/20/2019 8:04 AM, justin White wrote: > I deleted my mksocfpga directory and re-pulled it and I get the same > results after building the .rbf. > > Still not quite sure what's going on, though I did catch something in > Quartus. Using "0A" for stepgens in the pinfile creates 10 stepgens, but > only the first 4 seem to be complete. #4 (the 5th stepgen) when expanded > shows blank resources for "SRL16E:\steptable:0:asr16e", but does show > resources for "SRL16E:\steptable:1:asr16e". On every stepgen after they are > both blank which looks like it mimics exactly the problem I'm having. If > "steptable:1" > relates to the dir pin and "steptable:0" relates to the step pin, it > explains why I have a working direction pin on #4 but no step pin, and #5 > doesn't work at all. In this case I'd assume no later stepgens would work. > > I'm not really sure how Quartus works with the configs. I'm just dropping > the pinfile I made into the > '../mksocfpga/HW/hm2/config/DExx_Nano_xxx_Cramps' directory and renaming > the "atlas_3x24_cap_enc.sv" to match my pinfile, which is what I do with > the mksocfpga docker build. I don't specify a pinfile or anything when > running the analysis in Quartus, yet it does seem to catch the changes I've > made to that specific pinfile even though I don't specify anything in > Quartus, I just load the "DE10_Nano_FB_Cramps.qpf" file. > > Pics, QP1 shows all 10 stepgens, QP2 shows the difference between the > working #3 stepgen (0-3 all look the same) and #4 and #5 where the problem > starts. "combinational ALUTS" and every feild after is blank. > > [image: QP1.png] > > [image: QP2.png] > > > > > > On Monday, August 19, 2019 at 5:00:11 PM UTC-4, Michael Brown wrote: >> >> Thanx for the clairifying Charles, I doublechecked tha line and it reads: >> (StepGenTag,x"02", ClockLowTag,x"06", >> StepGenRateAddr, StepGenNumRegs, x"00", StepGenMPBitMask), >> >> So that should be ok... >> >> On Monday, 19 August 2019 22:37:42 UTC+2, Charles Steinkuehler wrote: >>> >>> Actually, the NumInstances field of the ModuleRecord is defined as an >>> 8 bit std_logic_vector: >>> >>> >>> https://github.com/machinekit/mksocfpga/blob/master/HW/hm2/config/IDROMConst.vhd#L839 >>> >>> >>> In VHDL, it should throw an error if you use 06 for this value (VHDL >>> won't convert an integer value into a std_logic_vector without some >>> sort of type conversion). >>> >>> If you meant that you are using x"06" (an 8-bit hexadecimal value), >>> that should work fine, but you will only get 6 stepgens instead of the >>> 10 you'd get with x"0A". >>> >>> On 8/19/2019 3:19 PM, Michael Brown wrote: >>>> No changing numinst should work just fine >>>> >>>> On Monday, 19 August 2019 18:05:28 UTC+2, justin White wrote: >>>
Re: [Machinekit] Re: DE10 Nano suggested development environment?
er handy.
>>>>>>
>>>>>> I've been tracking down an issue with the stepgens and depending on
>>>>>> what the issue is it may be part of the smart serial issue. I have 4 out
>>>>>> of
>>>>>> 6 stepgens that work, on my 5th stepgen only the direction pin works,
>>>>>> not
>>>>>> the step pin. Neither work on the 6th stepgen. I disabled SS for the
>>>>>> time
>>>>>> being but it was using consecutive pins with the 5th and 6th stepgens.
>>>>>> It
>>>>>> was difficult to see what was going on until I got my GUI setup. Now I
>>>>>> can
>>>>>> see that in hal it is actually working and I'm getting feedback to the
>>>>>> PID
>>>>>> loop but the pins of the Nano itself do not electrically do anything, I
>>>>>> can
>>>>>> verify that with my scope. Thinking maybe I damaged the GPIO pins from
>>>>>> all
>>>>>> the hardware swapping I've been doing, I picked up another DE10 Nano and
>>>>>> the same thing happens. I tried swapping stepgen instance 0,1 for 4,5 in
>>>>>> the .vhd and rebuilt the firmware without changing any hal configuration
>>>>>> and stepgens 4 and 5 work fine if they are controlling different GPIO
>>>>>> pins
>>>>>> without making any hal changes. I jumped the GPIO pins for a working
>>>>>> stepgen to the PCB pins I use for 4 and 5 and the interface hardware
>>>>>> works
>>>>>> fine that way.
>>>>>>
>>>>>> So the conclusion I'm drawing is that there's an issue with the
>>>>>> firmware that's getting built. hm2 thinks all 6 stepgens are there but
>>>>>> there is only 4 1/2 stepgens actually working. I seem to recall there is
>>>>>> a
>>>>>> parameter that has to change to add a certain amount of certain pin
>>>>>> types,
>>>>>> but I didn't think it applied in this case and I'm not sure what it is.
>>>>>>
>>>>>> My current VHD with SS disabled attached
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Saturday, August 17, 2019 at 6:40:07 AM UTC-4, Michael Brown wrote:
>>>>>>>
>>>>>>> OK back to being able to be online with my workstation:
>>>>>>> I have allways had a fight setting up proper display resolutions on
>>>>>>> the altera soc's however I can give you some key notes:
>>>>>>> In qsys there are 3 cores to consider:
>>>>>>> For display timing settings:
>>>>>>> alt_vip_vfr_hdmi (framereader)
>>>>>>>
>>>>>>> alt_vip_itc_0 (Clocked video output)
>>>>>>>
>>>>>>> The display core clock itself:
>>>>>>> pll_lcd--> lcd_clk
>>>>>>>
>>>>>>>
>>>>>>>> 1600x900 would allow me to test it out on my mill and I might have a
>>>>>>>> use for 800x480. I didn't realize the resolution was fixed, my 1080P
>>>>>>>> monitors don't have a problem displaying 1024x768, all my other
>>>>>>>> monitors
>>>>>>>> do. I suppose in a real usage scenario I'd have to look further into
>>>>>>>> your
>>>>>>>> previous reply and try to figure out how to set a resolution for
>>>>>>>> whatever
>>>>>>>> monitor I intended to use.
>>>>>>>
>>>>>>>
>>>>>>> Sadly there are currently no presets for these 2 resolutions for the
>>>>>>> framebuffer related cores (presets are found in qsys view menu), as I
>>>>>>> havent had use of these resolutions myself (in newer time).
>>>>>>> And I also have no (qsys) formula other than intuitive guess work.
>>>>>>>
>>>>>>> Last there is the Devicetree entry this is the current one:
>>>>>>>
>>>>>>> https://github.com/the-snowwhite/soc-image-buildscripts/blob/master/SD-Image-Gen/patches/4.9.76-ltsi-rt/current/0012-Added-DE-10-Nano-with-uio-with-without-framebuffer-1.patch#L291
>>>>>>>
>>>>>>> This entry:
>>>>>>>
>>>>>>> vip@0x100031000 {
>>>>>>> compatible = "altr,vip-frame-reader-1.0", "ALTR,vip-frame-reader-9.1";
>>>>>>> reg = <0x0001 0x00031000 0x0080>;
>>>>>>> max-width = <1024>;
>>>>>>> max-height = <768>;
>>>>>>> bits-per-color = <0x8>;
>>>>>>> colors-per-beat = <0x4>;
>>>>>>> beats-per-pixel = <0x1>;
>>>>>>> mem-word-width = <0x80>;
>>>>>>> };
>>>>>>>
>>>>>>>
>>>>>>> On Friday, 9 August 2019 03:55:13 UTC+2, justin White wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tuesday, August 6, 2019 at 1:07:38 PM UTC-4, Michael Brown wrote:
>>>>>>>>>
>>>>>>>>> Not very easy from my cell phone here however:
>>>>>>>>> In qsys there are 2 instances where you set up the timings for the
>>>>>>>>> screen monitor. There should be some saved setups HD etc. Lastly you
>>>>>>>>> need
>>>>>>>>> to place the correct screen settings in the device tree there is a HD
>>>>>>>>> example there too. 1920 x1080. Sorry for not being online atm...
>>>>>>>>>
>>>>>>>>
>>>>>>>> Gonna Give this a try soon as I get a chance. Waiting for my friend
>>>>>>>> to correct a minor issue with the time based filter in the RT hal
>>>>>>>> component
>>>>>>>> he whipped up for me for the ADC then I'll post it up here. Maybe you
>>>>>>>> can
>>>>>>>> include it in your project if you think it's useful. It certainly is
>>>>>>>> for
>>>>>>>> someone like me who only works with hal.
>>>>>>>>
>>>>>>>
>>>>>>> Well It would be nice with a hal rt component for calculating
>>>>>>> temperature readings based on ntc probes instead of the python user
>>>>>>> component hal_temp_atlas I derived from the hal_temp_bbb :-)
>>>>>>>
>>>>>>>
>>>>>>
>
--
Charles Steinkuehler
char...@steinkuehler.net
--
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 machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/machinekit/c32a696d-a585-98aa-4ffd-831c821a6375%40steinkuehler.net.
Re: [Machinekit] Re: DE10 Nano suggested development environment?
On 7/26/2019 5:08 PM, justin White wrote: > >> >> Ok well I cannot cope with the stress of starting up my workstation this >> week and I didn't catch any quartus log in your former post? >> MiB >> > > Lol, rough week eh? > > Post directly after has the quartus snippet with the error, re-ran it,full > terminal print attached. Again, only happens if in pinfile: > > (SSerialTag,x"00", ClockMedTag,x"01", SSerialCommandAddr, > SSerialNumRegs, x"10", SSerialMPBitMask), > > if: > > (SSerialTag,x"00", ClockLowTag,x"01", SSerialCommandAddr, > SSerialNumRegs, x"10", SSerialMPBitMask), > > it will build fine, but SS does not work. The problem is it doesn't look like ClockMedTag is declared in the IDROMConst.vhd file, just ClockLowTag and ClockHighTag: https://github.com/machinekit/mksocfpga/blob/master/HW/hm2/config/IDROMConst.vhd#L402-L404 ...causing the Quartus error: Error (10482): VHDL error at PIN_st_fpga_soc_dc1f.vhd(80): object "ClockMedTag" is used but not declared File: /work/HW/hm2/config/DExx_Nano_xxx_Cramps/PIN_st_fpga_soc_dc1f.vhd Line: 80 The configs I have that use SSerial are using ClockLowTag and IIRC they worked OK. You might check and see if Peter has updated the IDROMConst.vhd file, the one in the Machinekit repo might be fairly dated. But I think it ought to work when using ClockLowTag, so there may be some other weirdness going on. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/160aeed4-bc30-0351-57c0-a033f55d2d5a%40steinkuehler.net.
Re: [Machinekit] Re: DE10 Nano suggested development environment?
On 7/23/2019 11:28 PM, justin White wrote: > Charles, > > Does the Clock rate specified in the pinfile for the module instance relate > to the clock rate as it's set in the "card" file? Like I said the example I > came across in MKSOCFPGA specified "ClockLowTag" for SS so that is what I > used. I later tried building it with ClockMedTag for giggles but it failed, > I forget the error, something not found. The DE10 projects seem to be built > with a different structure, I don't see a VHD that looks like the card file > you linked to. There are SystemVerilog files that look like they pertain to > the same things you are describing: > > The "card" file? > https://github.com/machinekit/mksocfpga/blob/fdc9ddc3a42cc2b6f4a1302ef8e6ca8fc23a4bc0/HW/hm2/config/DExx_Nano_xxx_Cramps/atlas_3x24_cap_enc.sv#L7 Seems likely, but I don't deal with system verilog much at all, and I *REALLY* don't deal with instantiating VHDL entities with generics (ie: the hostmot2 instance) via system verilog. > Similar to the "HPS PLL"? > https://github.com/machinekit/mksocfpga/blob/fdc9ddc3a42cc2b6f4a1302ef8e6ca8fc23a4bc0/HW/QuartusProjects/DE10_Nano_FB_Cramps/DE10_Nano_FB_Cramps.sv#L297 Yes, that matches up. Note you have to go into the qsys file defining the hps (hard processor system) to determine what the PLL frequencies are set to, which is why it's probably best to just try and measure the baud rate. > The sure way to check is capture a few bytes being sent over the >> serial port when the driver starts up. That will tell you the *REAL* >> baud rate. > > That's what I was trying to do. I breadboarded a differential reciever IC > and connected the input to a Tx driver on my board and the output to an > RS232-USB adapter Rx pin. I used Moserial to try to capture a transmission > when MK was starting up. I only got a hex value of all 0's at some random > baud rate but the max baud rate in moserial is 2mbps. So I scoped the Tx+ > line of the board and only found a single short pull down when starting MK What do you get from the debug log when the hm2 driver loads? Do you have a digital 'scope so you can capture the first few words of the sserial communications? IIRC, the sserial stuff works OK on the DE0-Nano, but it's been a couple years since I messed with this and I'm not 100% sure if I had my 7i76 (and it's sserial driven field IO pins) working with the DE0 or with a 7i92 (I was doing a lot of switching back and forth at the time but I'm pretty sure the 7i76 was working properly with both). -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/9d431977-01e2-35c6-6ad5-7b545a4ff14a%40steinkuehler.net.
Re: [Machinekit] Re: DE10 Nano suggested development environment?
On 7/22/2019 1:01 AM, justin White wrote: > > For the Sserial thing, I did eventually get MK to dump a logfile that > showed HM2 come up. SSerial is being initiated as far as that goes, it does > print the version. I tried rigging up a Serial cable and sniffing the > transmit line but the 2.5m baud rate that sserial claims is too high for > anything I'm using to catch. With a scope I can catch the transmit line get > pulled low for a very short period. PCW did mention this: > > I still suspect a wiring error as the most like cause of non-detection of >> SSerial remotes, >> but another possibility is an incorrect CLKMED value in the firmware source >> (The baud rate calculations that the SSerial processor does depend on this >> constant >> matching the actual CLKMED clock rate) > > I've checked the wiring, and double checked the PCB traces against the > datasheets and continuity to every solder joint everything looks fine. > Later in the week I'll be able to test a better circuit but I'm not sure > what to do about checking the clock rate. The sure way to check is capture a few bytes being sent over the serial port when the driver starts up. That will tell you the *REAL* baud rate. The "medium" clock rate is typically defined in the "card" VHDL file. I'm not sure if there's one specifically for the DE10 or if it uses the one for the DE0_Nano: https://github.com/machinekit/mksocfpga/blob/master/HW/hm2/config/DE0_Nano_SoC_DB25/DE0_Nano_SoC_DB25_card.vhd#L73 The clock source also needs to match the frequency specified in the above file. For the DE0_Nano, the 100 MHz medium clock is generated by an HPS PLL: https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE0_Nano_SoC_DB25/DE0_Nano_SoC_DB25.vhd#L277 -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/1297e78c-e0b9-c264-e912-9a2cdfff998e%40steinkuehler.net.
Re: [Machinekit] Re: DE10 Nano suggested development environment?
I _think_ the debugging will get output to the log file if you launch with something like DEBUG=5. I don't think you need to pass any parameters to the hm2_soc_ol driver, it's the hm2 module that takes things like the sserial= option. IIRC, with full debugging turned on, you'll get a dump with quite a bit of detail as the hm2 driver launches and starts auto-probing the hardware to see what's configured. On 7/18/2019 8:11 AM, justin White wrote: > Charles, is there any way to see that SSerial is actually running? Typically > when you start LinuxCNC from terminal Hm2 will print the sserial version > running first. I can’t see this by starting a config with Machinekit. I tried > launching a basic source file and manually loadrt from halrun but the > differences are such that I couldn’t figure out how to loadrt hm2_soc_ol with > any config options. I’m not sure if the “atlas_sv” file needs a > modification. For smart serial, like I said I’m just using the same renamed > 3x24.sv I’ve been using. > > By “not work” i mean when starting MK plugged into the 8i20 from my mill I > get no hm2_5i25.0.8i20.. pins as I would with the 8i20 plugged into the > 7i76e/x86 pc installed on the mill. I didn’t have any issues with the cable, > connection I made for that and this is pretty much exactly the same. > > I’ve checked all my connections but I certainly wouldn’t rule out that I > missed something. It’d be great if I could find some evidence that either > sserial is actually running or that the hardware isn’t communicating anything > at all, like some sort of serial terminal where I could at least check for > some sort of handshake process. > -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/98f02822-da76-6107-e4c5-1e3a65ba06a5%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: DE10 Nano suggested development environment?
>From what I know your pin file looks OK, but I'm not an expert on SSerial. Can you need to expand a bit on "still couldn't get it to work". The hm2 driver will automatically look for and create HAL pins for any SSerial devices it finds, but the far end needs to be powered up and responding to SSerial communication when the driver loads for this to happen (eg: the field I/O on the 7i76). So if the FPGA hardware is OK, you should see some communication on the SSerial lines when the hm2 driver loads. On 7/17/2019 10:38 PM, justin White wrote: > > Same as attached on july 13 except I changed SS numinst to 1. > > On Wednesday, July 17, 2019 at 11:24:07 PM UTC-4, Charles Steinkuehler > wrote: >> >> Got a link to your pin file for review? >> >> On 7/17/2019 6:59 PM, justin White wrote: >>> I used 2 instances of SSerial in the pinfile which was incorrect. I'm >> told >>> 1 instance covers 8 SSerial channels. I built a new .rbf with 1 instance >>> and still couldn't get it to work. PCW confirms that the encoder/stepgen >>> thing should work just fine so I'm pretty much out of ideas. >>> >>> On a side note, how might I go about changing the framebuffer resolution >> to >>> the HDMI? Only certain monitors will display anything from the DE10 >> which >>> makes it kind of a PIA to test this as I have to drag another monitor >> down >>> to my mill since my mill's monitor wont display the Nano. The way it's >>> achieving a resolution doesn't seem standard as no standard method of >>> changing it from 1024x768 seems to work. >>> >>> On Sunday, July 14, 2019 at 5:25:31 PM UTC-4, justin White wrote: >>>> >>>> There was something wrong with my build environment, deleted it and I >> was >>>> able to get a good .rbf. >>>> >>>> I wasn't able to get this working with my 8i20 though. I added >>>> "sserial_port_0=00" to the config line as in my other sserial >> configs. >>>> >>>> I'll probably hold off on anymore testing until I get a board fabbed >> with >>>> dedicated serial hardware, but the firmware could probably use some >> looking >>>> into. >>>> >>>> On Sunday, July 14, 2019 at 6:08:13 AM UTC-4, justin White wrote: >>>>> >>>>> Any insight on the issue with the rbf? >>>> >>>> >>> >> >> >> -- >> Charles Steinkuehler >> cha...@steinkuehler.net >> > -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/dadd434b-8b92-930a-d4fd-6b678b9aa5ea%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: DE10 Nano suggested development environment?
Got a link to your pin file for review? On 7/17/2019 6:59 PM, justin White wrote: > I used 2 instances of SSerial in the pinfile which was incorrect. I'm told > 1 instance covers 8 SSerial channels. I built a new .rbf with 1 instance > and still couldn't get it to work. PCW confirms that the encoder/stepgen > thing should work just fine so I'm pretty much out of ideas. > > On a side note, how might I go about changing the framebuffer resolution to > the HDMI? Only certain monitors will display anything from the DE10 which > makes it kind of a PIA to test this as I have to drag another monitor down > to my mill since my mill's monitor wont display the Nano. The way it's > achieving a resolution doesn't seem standard as no standard method of > changing it from 1024x768 seems to work. > > On Sunday, July 14, 2019 at 5:25:31 PM UTC-4, justin White wrote: >> >> There was something wrong with my build environment, deleted it and I was >> able to get a good .rbf. >> >> I wasn't able to get this working with my 8i20 though. I added >> "sserial_port_0=00" to the config line as in my other sserial configs. >> >> I'll probably hold off on anymore testing until I get a board fabbed with >> dedicated serial hardware, but the firmware could probably use some looking >> into. >> >> On Sunday, July 14, 2019 at 6:08:13 AM UTC-4, justin White wrote: >>> >>> Any insight on the issue with the rbf? >> >> > -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/c75d0114-9965-6268-9460-a745501ed0ad%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: DE10 Nano suggested development environment?
On 7/7/2019 12:22 PM, justin White wrote: > I asked a similar question over on the LCNC forums and PCW confirmed it's > just straight RS-422. The 7i76 was probably a bad example, the LBP section > of the manual for the (e) version confirms what you said about it > communicating with it's own I/O section over SSerial, I just want to slap > the single SSerial channel on the board. Not sure about the termination > resistor, I usually see it suggested on the Rx line but the datasheet for > the transceiver I'm looking at suggests termination on the driver as well. > Any thoughts on the attached drawing? There's good info in the data sheet for that part: http://www.ti.com/lit/gpn/thvd1451 ...which is an RS-485 transceiver (RS-485 is the same electrically as RS-422, but the driver can be switched off). RS-485 is a "multi-drop" protocol, and supports multiple transceivers. Typically, the end nodes will have termination resistors populated and the devices in the middle on the cable will have the termination disabled. See figure 32 (page 22) in the data sheet. PCW said it's straight RS-422, not RS-485. That means you only have two devices making each device an end point, so add termination to both ends. The ESD protection is application dependent, but you might also want a small value series resistor between the THVD1451 and the cable (see Figure 38, page 27 along with the recommend parts list) and see the layout recommendations on page 29. ...but don't sweat the details too much. For a short range (a few meters) point-to-point connection, the ESD and even the termination resistors are not super important. I'd still add them (it's cheap insurance!), but I don't expect you're designing for 1.5 km long cables that need to withstand nearby lightning strikes. :) That said, spindle motors can throw off enough ESD to cause problems even with differential signals, which is why you want _something_. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/167de833-4ebe-6809-97aa-84ccfa4077e6%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: DE10 Nano suggested development environment?
On 7/7/2019 4:29 AM, Michael Brown wrote: > Looking at a 7i76e manual it's differential RS422 while the > example configs suggest at the FPGA level it's a 2 pin RX/TX deal, > is that right? One example shows a TX enable pin, but I don't > think this is implemented on a board like the 7i76e which is all > I'm trying to duplicate. Any insight on this? > > I have no experience with rs422 or rs485, but i guess yes RS-422 is always differential. It may be full duplex (which only requires TX and RX) or half duplex (which adds a TX-Enable signal). The 7i76 daughtercard requires two SSERIAL channels, one for the 7i76 itself (for the Field I/O signals), and one which gets exported via the TB3 connector. Both buses are full duplex and do not require a TX-Enable signal. The SSERIAL communication between the FPGA and the 7i76 is via standard digital logic levels. The 7i76 provides an RS-422 transceiver for the SSERIAL bus on TB3. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/c967f07a-584e-eedc-1940-4959cdb40f63%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] can CRAMPS X_STEP/X_DIR,... drive 4N26 optoIsolator
On 6/30/2019 4:34 PM, Doug LaRue wrote: > On Sunday, June 30, 2019 at 12:46:29 PM UTC-7, Charles Steinkuehler wrote: >> >> You should be able to hook to the DB25 directly vs. digging into the >> control box, but you'll likely need some buffering. The BBB I/O pins >> are only rated for 3.3V with 3-6 mA drive (depending on the pin), >> which isn't really enough to directly drive an opto. >> > > So very much like the ESP32/Grbl-esp32 which got me started down this > path. 3.3V GPIO little drive capability > > >> >> The CRAMPS board doesn't really help a lot, since it doesn't buffer >> the step/dir lines (the small Pololu stepper drivers don't present >> much load on the step/dir pins). >> >> I'd recommend one of two options: >> >> * Create your own DB25 cape for the BBB using a prototype cape and a >> generic buffer like a 74HCT245 or something. There aren't a lot of >> wires so it shouldn't be much harder than the "flying wire" adapter >> you made for the Nano. :) >> > > That might not be a bad idea and I think I have a BBB prototyping Cape > somewhere. But the 4n26 opto isolators are rated at 60mA and selecting > the level shifter or line driver is where I'm stuck right now. > > I have some TXS108E bi-directional level shifters with 50ma drive > capabilities > but was told the pull-up instead of drive-up could be problematic. > https://www.ti.com/lit/ds/symlink/txs0108e.pdf > > I might have some 74HCT245's here so can test the ~20mA drive capability > with respect to the opto-isolators. The 60 mA is an *Absolute Maximum Rating*, not what you should be driving them with consistently! A typical drive current for the LED when "on" would be 10 mA, and most 4N26 data sheets specify transfer curves with 5, 10, and 20 mA forward current through the LED. > And I might build a more generic board onto an DB25P so I can swap in/out > the Nano, ESP32 and BBB. It might take those imported CNC machines through > 3 levels of capabilities with BBB/Machinekit the ultimate. Sounds like a great idea! >> * Create a small Pololu sized buffer board that drives the step/dir >> signals onto the 4-pin stepper motor header. This would let you use >> the CRAMPS board (or any other board that used the Pololu style >> drivers). I've thought this would be a good open-source project, and >> would be useful for *anything* that uses the Pololu style drives (not >> just BBB based capes) and would allow safely driving larger stepper >> motor drivers. >> > > I wish there were 5V on that driver pinout.. I suppose there could be a > jump on the Vcc pin to bring in something other than 3.3V. With only 3 > lines a small quad channel shifter would do the trick. Still need to find > what the 4N26 requires to turn on though. Interesting. I'd just set the motor power to 5V. Or you could put a small 5V regulator on the board...a 78L05 is pretty inexpensive. :) ...but yeah, it would be nice if there was an available 5V supply in the Pololu pinout, but oh-well. :-/ -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/0b28ee1c-2f5b-4f6c-457f-97e87e29561a%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] can CRAMPS X_STEP/X_DIR,... drive 4N26 optoIsolator
You should be able to hook to the DB25 directly vs. digging into the control box, but you'll likely need some buffering. The BBB I/O pins are only rated for 3.3V with 3-6 mA drive (depending on the pin), which isn't really enough to directly drive an opto. The CRAMPS board doesn't really help a lot, since it doesn't buffer the step/dir lines (the small Pololu stepper drivers don't present much load on the step/dir pins). I'd recommend one of two options: * Create your own DB25 cape for the BBB using a prototype cape and a generic buffer like a 74HCT245 or something. There aren't a lot of wires so it shouldn't be much harder than the "flying wire" adapter you made for the Nano. :) * Create a small Pololu sized buffer board that drives the step/dir signals onto the 4-pin stepper motor header. This would let you use the CRAMPS board (or any other board that used the Pololu style drivers). I've thought this would be a good open-source project, and would be useful for *anything* that uses the Pololu style drives (not just BBB based capes) and would allow safely driving larger stepper motor drivers. Good luck! On 6/30/2019 12:38 PM, Doug LaRue wrote: > I have a 3040T 4 axis CNC and currently have grbl on an Arduino Nano > connected to the DB25. > > I was wondering if anyone has tried Machinekit on a CRAMPS board driving > the DB25 directly instead of going inside the control box and replacing > things. The DB25 has opto isolators on the DB25 inputs. > Probably more of a question for Charles unless someone else is familiar > with the drive capabilities of the BBB and input bufffering of CRAMPS. > > They are 4N26 - http://www.vishay.com/docs/83725/4n25.pdf > > DB25P wirings: > From Vide CNC LPT Pinout > db25 Pin Description > 1 A Enable > 2 X Step > 3 X Direction > 4 Y Step > 5 Y Direction > 6 Z Step > 7 Z Direction > 8 A Step ** > 9 A Direction ** > 10 Reset / Abort / E-Stop > 11 Z limit( Mach 3 video =X) > 12 Y limit( Mach 3 video =Y) > 13 X limit( Mach 3 video =Z) > 14 X Enable > 15 Probe > 16 Y Enable( Mach 3 vidoe =Output1) > 17 Z Enable > 18 - 25 Ground > > > > [image: GRBL_Arduino_Nano_DB25_CNC_1.jpg] > -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/6ad77c5c-c2af-c9e8-e9f9-75b5333ff5bb%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: DE10 Nano suggested development environment?
;>> point to the new firmware. Then all it seems I had to do was modify the >>>> no-load.ini to point to my firmware and instantiate the proper number of >>>> stepgens and encoders. Looks like a good start until I get a chance to >>>> write a proper hal file >>>> >>>> >>>> On Sunday, June 16, 2019 at 12:53:10 PM UTC-4, Michael Brown wrote: >>>>> >>>>> Looking at your errorlog this is what sticks out for me: >>>>> >>>>> Warning (12019): Can't analyze file -- file >>>>> ../../hm2/config/DExx_Nano_xxx_Cramps/atlas_st_fpga_soc_dc1.sv is >>>>> missing >>>>> >>>>> So you can create a copy of a suitable atlas_3x24 .sv named >>>>> atlas_st_fpga_soc_dc1.sv >>>>> <http://www.google.com/url?q=http%3A%2F%2Fatlas_st_fpga_soc_dc1.sv=D=1=AFQjCNFaXzIhSaX4akk6lI9iwZh_k2ltVA> >>>>> >>>>> (With your naming convention), >>>>> and customize it if you fell so inclined. then it should build. >>>>> Best Wishes >>>>> Michael Brown >>>>> >>>>> >>>>> >>>>> On Sunday, 16 June 2019 18:36:03 UTC+2, Michael Brown wrote: >>>>>> >>>>>> Please notice that only the header and extension is different in the >>>>>> two added files: >>>>>> >>>>>> HW/hm2/config/DExx_Nano_xxx_Cramps/PIN_3x24_cap_enc_dbspi.vhd >>>>>> HW/hm2/config/DExx_Nano_xxx_Cramps/atlas_3x24_cap_enc_dbspi.sv >>>>>> >>>>>> >>>>>> On Sunday, 16 June 2019 18:31:31 UTC+2, Michael Brown wrote: >>>>>>> >>>>>>> To add a new config you have to add 2 new files like in this pending >>>>>>> commit Charles yet has not had time to look at: >>>>>>> >>>>>>> https://github.com/machinekit/mksocfpga/pull/106/commits/cf035069c539dda57131a2190499f204f9f5412f >>>>>>> >>>>>>> Note that I have tried to build a cosistant (by function) file naming >>>>>>> convention as the names of the 2 files reflect in the bitfiles you get >>>>>>> out >>>>>>> at the other end. >>>>>>> >>>>>>> >>>>>>> On Sunday, 16 June 2019 14:25:23 UTC+2, Charles Steinkuehler wrote: >>>>>>>> >>>>>>>> It looks like the pertinent error is: >>>>>>>> >>>>>>>> Error (10161): Verilog HDL error at DE10_Nano_FB_Cramps.sv(132): >>>>>>>> object "boardtype" is not declared. Verify the object name is >>>>>>>> correct. >>>>>>>> If the name is correct, declare the object. File: >>>>>>>> /work/HW/QuartusProjects/DE10_Nano_FB_Cramps/DE10_Nano_FB_Cramps.sv >>>>>>>> Line: 132 >>>>>>>> >>>>>>>> I'm not quite sure what's going wrong, I haven't really worked with >>>>>>>> Michael's new System Verilog top-level design. >>>>>>>> >>>>>>>> On 6/15/2019 8:31 PM, justin White wrote: >>>>>>>>> Trying to build the bitfile, I'm sure I'm doing something wrong. >>>>>>>>> >>>>>>>>> I modified the "PIN_3x24_cap_enc.vhd" pinfile posted earlier to >>>>>>>> suit my >>>>>>>>> board and tried to build it via the readme based on the >>>>>>>>> "DE10_Nano_FB_Cramps" project. I'm sure I'm missing a step here. >>>>>>>> Print and >>>>>>>>> .vhd attached. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Saturday, June 15, 2019 at 2:55:03 PM UTC-4, justin White >>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> No smoke yet. >>>>>>>>>> >>>>>>>>>> [image: Photo Jun 15, 2 47 40 PM.jpg] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tuesday, June 11, 2019 at 10:41:16 PM UTC-4, justin White >>>>>>>> wrote: >>>>>>>>>>> >>
Re: [Machinekit] Re: DE10 Nano suggested development environment?
On 6/16/2019 11:31 AM, Michael Brown wrote: > To add a new config you have to add 2 new files like in this pending commit > Charles yet has not had time to look at: > https://github.com/machinekit/mksocfpga/pull/106/commits/cf035069c539dda57131a2190499f204f9f5412f Sorry...I was on vacation and very much off-line the last two weeks. Merged. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/6c2daaa4-a3fd-8b9f-5832-51e90abb09b7%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: DE10 Nano suggested development environment?
On 6/16/2019 3:24 PM, justin White wrote: > I renamed the files you mentioned and got an output, not sure if the below > error means anything: > builder@300dd4c4fceb:/work/HW/QuartusProjects/DE10_Nano_FB_Cramps$ > Inconsistency detected by ld.so: dl-close.c: 762: _dl_close: Assertion > `map->l_init_called' failed! This warning is benign and may be safely ignored. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/8579851c-231d-157d-c5c3-33977ec82016%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: DE10 Nano suggested development environment?
It looks like the pertinent error is: Error (10161): Verilog HDL error at DE10_Nano_FB_Cramps.sv(132): object "boardtype" is not declared. Verify the object name is correct. If the name is correct, declare the object. File: /work/HW/QuartusProjects/DE10_Nano_FB_Cramps/DE10_Nano_FB_Cramps.sv Line: 132 I'm not quite sure what's going wrong, I haven't really worked with Michael's new System Verilog top-level design. On 6/15/2019 8:31 PM, justin White wrote: > Trying to build the bitfile, I'm sure I'm doing something wrong. > > I modified the "PIN_3x24_cap_enc.vhd" pinfile posted earlier to suit my > board and tried to build it via the readme based on the > "DE10_Nano_FB_Cramps" project. I'm sure I'm missing a step here. Print and > .vhd attached. > > > > On Saturday, June 15, 2019 at 2:55:03 PM UTC-4, justin White wrote: >> >> No smoke yet. >> >> [image: Photo Jun 15, 2 47 40 PM.jpg] >> >> >> On Tuesday, June 11, 2019 at 10:41:16 PM UTC-4, justin White wrote: >>> >>> Well once I get a PCB all assembled I'll have to go back through this >>> thread and figure out how to get the FPGA all set up lol. The Arduino >>> connector on the DE10 kind of irk me, they are extended height an 4 or 5mm >>> taller than the 2x20 headers so either tall pin sockets have to be sourced >>> or I've thought about just desoldering the Arduino connectors from the DE10. >>> >>> On Tuesday, June 11, 2019 at 1:56:27 AM UTC-4, Bas de Bruijn wrote: >>>> >>>> >>>> >>>>> On 11 Jun 2019, at 01:25, justin White wrote: >>>>> >>>>> Possibly, >>>>> >>>>> Need to do some testing once I get the first rev assembled. This >>>> Particular board is probably a bit too expensive to make for the open >>>> source world to want, and the I/O arrangement is somewhat specific to my >>>> needs. That many Phoenix Contact blocks gets pretty expensive. >>>> >>>> I would be interested, keep me updated! >>>> I think machinekit can do with some additional hardware between >>>> controllers and wires. >>>> >>>> but imo cheap is a nice to have, function and quality come first. Think >>>> about how something industrial gets wired. Then you need some contact >>>> blocks to easily connect wires. In the total a more expensive part here >>>> will give you an edge somewhere else (manual labor). And indeed when >>>> you’re >>>> a diy-er labor does not come into the equation. >>>> >>>>> I'll probably drop some OS version into the wild once I get it sorted, >>>> with a more general I/O layout. This board is setup with 6 differential >>>> (or >>>> single ended) encoder inputs, 6 differential stepgen outputs, 16 5v-30v >>>> inputs, 24 field voltage outputs up to 500ma, 2 opto-mosfet outputs @2A >>>> snubbed. Has a 5A 5v DC-DC regulator that will accept up to 42VDC, power >>>> the DE10-nano through GPIO and output the spare 5v up to 3A. My method of >>>> stepgen outputs and GP inputs needs some testing. >>>> >>>> > -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/a4481418-e408-6c32-51d3-78c62b14c1f2%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: Machinekit on PocketBeagle
Hmm...looking at the code it appears the output pins have a conditional for the pin numbering fixup: https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_bb_gpio/hal_bb_gpio.c#L365-L370 ...that's missing for the input pins: https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_bb_gpio/hal_bb_gpio.c#L272-L275 Combined with the legacy use of 1xx and 2xx for the BeagleBone pin numbers (which is why the fixup exists in the first place) it looks like that's breaking you pin numbering scheme. Can you try with just output pins and see if that works? On 5/20/2019 4:06 PM, markus wrote: > That actually is the problem - the driver takes the p1 and p2 pins and > uses them as p8 and p9 pins, this is the excerpt from the hal file that > I used: > > # load low-level drivers > loadrt hal_bb_gpio board=PocketBeagle input_pins=201,202,203,204 > output_pins=217,227,228,229,230,231,232 > loadrt [PRUCONF](DRIVER) prucode=$(HAL_RTMOD_DIR)/[PRUCONF](PRUBIN) > [PRUCONF](CONFIG) > > Same thing happens if I do it manually with halrun - and it complains > about the first pin in the command line, so if I remove 201 it > complains about 902 not being valid. > > > On Mon, 20 May 2019 15:55:37 -0500 > Charles Steinkuehler wrote: > >> On 5/20/2019 3:36 PM, markus wrote: >>> Thanks for the clarification - much appreciated. >>> >>> It seems the driver is ignoring the parameter though. And I get the >>> same result. From linuxcnc.log: >> >> Look closer, it's not the same result. >> >>> May 20 00:07:37 pocketbeagle msgd:0: startup pid=1376 >>> flavor=rt-preempt rtlevel=1 usrlevel=1 halsize=524288 shm=Posix >>> cc=gcc 6.3.0 20170516 version=v0.1~-~355496b May 20 00:07:37 >>> pocketbeagle msgd:0: ØMQ=4.2.1 czmq=4.0.2 protobuf=3.0.0 >>> atomics=gcc intrinsicslibwebsockets=2.0.3 May 20 00:07:37 >>> pocketbeagle msgd:0: configured: sha=355496b May 20 00:07:37 >>> pocketbeagle msgd:0: built: Mar 14 2019 10:47:55 sha=355496b >>> May 20 00:07:37 pocketbeagle msgd:0: register_stuff: actual >>> hostname as announced by avahi='pocketbeagle.local' May 20 00:07:37 >>> pocketbeagle msgd:0: zeroconf: registering: 'Log service on >>> pocketbeagle.local pid 1376' May 20 00:07:38 pocketbeagle msgd:0: >>> zeroconf: registered 'Log service on pocketbeagle.local pid 1376' >>> _machinekit._tcp 49152 TXT >>> "uuid=4e7e123c-1726-4351-bdfc-eba93047fb35" >>> "instance=f2ce6258-7acd-11e9-aea4-606405e00475" "service=log" >>> "dsn=tcp://pocketbeagle.local:49152" May 20 00:07:39 pocketbeagle >>> rtapi:0: 1:rtapi_app:1381:user hal_bb_gpio: ERROR: invalid pin >>> number '901'. Valid pins are 101-136 and 201-236. >> >> The P8/P9 headers do not exist on the PocketBone. Try using legal pin >> numbers: 101-136 and 201-236 >> > -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/dcb35ed3-9316-5e5f-b6b8-2b914fcda8b2%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: Machinekit on PocketBeagle
On 5/20/2019 3:36 PM, markus wrote: > Thanks for the clarification - much appreciated. > > It seems the driver is ignoring the parameter though. And I get the > same result. From linuxcnc.log: Look closer, it's not the same result. > May 20 00:07:37 pocketbeagle msgd:0: startup pid=1376 flavor=rt-preempt > rtlevel=1 usrlevel=1 halsize=524288 shm=Posix cc=gcc 6.3.0 20170516 > version=v0.1~-~355496b > May 20 00:07:37 pocketbeagle msgd:0: ØMQ=4.2.1 czmq=4.0.2 protobuf=3.0.0 > atomics=gcc intrinsicslibwebsockets=2.0.3 > May 20 00:07:37 pocketbeagle msgd:0: configured: sha=355496b > May 20 00:07:37 pocketbeagle msgd:0: built: Mar 14 2019 10:47:55 > sha=355496b > May 20 00:07:37 pocketbeagle msgd:0: register_stuff: actual hostname as > announced by avahi='pocketbeagle.local' > May 20 00:07:37 pocketbeagle msgd:0: zeroconf: registering: 'Log service on > pocketbeagle.local pid 1376' > May 20 00:07:38 pocketbeagle msgd:0: zeroconf: registered 'Log service on > pocketbeagle.local pid 1376' _machinekit._tcp 49152 TXT > "uuid=4e7e123c-1726-4351-bdfc-eba93047fb35" > "instance=f2ce6258-7acd-11e9-aea4-606405e00475" "service=log" > "dsn=tcp://pocketbeagle.local:49152" > May 20 00:07:39 pocketbeagle rtapi:0: 1:rtapi_app:1381:user hal_bb_gpio: > ERROR: invalid pin number '901'. Valid pins are 101-136 and 201-236. The P8/P9 headers do not exist on the PocketBone. Try using legal pin numbers: 101-136 and 201-236 -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/a32e3327-a0e2-e2b9-f3d0-1ad6b8528b89%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: Machinekit on PocketBeagle
On 5/20/2019 1:22 AM, markus wrote: >> On Monday, May 20, 2019 at 11:07:12 AM UTC+8, mlampert wrote: >>> >>> Am I correct that the support for the PB is a 'compile time' >>> decision? >> >> Try`board=PocketBeagle` >> >> https://github.com/machinekit/machinekit/blob/b58f6e83/src/hal/drivers/hal_bb_gpio/hal_bb_gpio.c#L83 >> >> John > > Where? When? In your hal file when you load the hal_bb_gpio module, eg: loadrt hal_bb_gpio board=PocketBeagle output_pins=... -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/6f582de3-f7c3-5dbb-5705-b32a12c2bc01%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Installing/Troubleshooting machinekit
I believe you are having the same overlay problem as in this thread (your eMMC boot loader is too old): https://groups.google.com/d/msg/machinekit/fSgf7NFRNdE/X94DrfYEBwAJ Try the fix proposed by Robert Nelson: sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10 ...and reboot. On 5/16/2019 12:56 PM, Bradley Turner wrote: > When I enter that command I get the following, not sure what it all means. > > machinekit@beaglebone:~$ sudo /opt/scripts/tools/versian.sh > sudo: /opt/scripts/tools/versian.sh: command not found > machinekit@beaglebone:~$ sudo /opt/scripts/tools/version.sh > git:/opt/scripts/:[1c496b4fc22006f7fa78e7cde0f59a2d53b78e39] > eeprom:[A335BNLT00C03818BBBK0A66] > model:[TI_AM335x_BeagleBone_Black] > dogtag:[Machinekit Debian Image 2019-04-28] > bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot > 2019.04-2-gc8b5ad3a1f]:[location: dd MBR] > bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot > 2016.01-1-g4eb802e]:[location: dd MBR] > kernel:[4.19.31-bone-rt-r31] > uboot_overlay_options:[enable_uboot_overlays=1] > uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo] > uboot_overlay_options:[enable_uboot_cape_universal=1] > pkg check: to individually upgrade run: [sudo apt install --only-upgrade > ] > pkg:[bb-cape-overlays]:[4.4.20190404.0-0rcnee0~stretch+20190404] > pkg:[bb-wl18xx-firmware]:[1.20190227.1-0rcnee0~stretch+20190227] > pkg:[kmod]:[23-2rcnee1~stretch+20171005] > WARNING:pkg:[librobotcontrol]:[NOT_INSTALLED] > pkg:[firmware-ti-connectivity]:[20180825+dfsg-1rcnee1~stretch+20181217] > groups:[machinekit : machinekit adm kmem dialout cdrom floppy audio dip > video plugdev users systemd-journal i2c bluetooth netdev gpio pwm eqep > admin spi tisdk weston-launch xenomai cloud9ide] > cmdline:[console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 > rootwait coherent_pool=1M net.ifnames=0 quiet cape_universal=enable] > dmesg | grep remote > [0.885371] remoteproc remoteproc0: wkup_m3 is available > [1.421143] remoteproc remoteproc0: powering up wkup_m3 > [1.421164] remoteproc remoteproc0: Booting fw image > am335x-pm-firmware.elf, size 217168 > [1.423355] remoteproc remoteproc0: remote processor wkup_m3 is now up > dmesg | grep pru > dmesg | grep pinctrl-single > [0.704516] pinctrl-single 44e10800.pinmux: 142 pins, size 568 > dmesg | grep gpio-of-helper > lsusb > Bus 001 Device 003: ID 046d:c534 Logitech, Inc. Unifying Receiver > Bus 001 Device 002: ID 0424:2504 Standard Microsystems Corp. USB 2.0 Hub > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > END > machinekit@beaglebone:~$ > > > Thanks > > > > On Wednesday, May 15, 2019 at 4:14:33 PM UTC-4, Charles Steinkuehler wrote: >> >> That sounds like something to do with the overlays. IIRC, I didn't >> have to do anything with the latest uSD image and the PRU UIO devices >> were there. >> >> Robert Nelson is the expert on the latest U-Boot overlays, but I have >> seen others have problems if their on-board eMMC boot loader was too old. >> >> Send the output of "sudo /opt/scripts/tools/version.sh" and we should >> be able to figure out what's wrong. >> >> On 5/15/2019 12:26 PM, Bradley Turner wrote: >>> Hello, >>> I have had lots of help throughout the setup process of getting >> machinekit >>> to work properly/Charles graciously got our HAL and INI files working >>> beautifully. I have been able to fix/troubleshoot/have the >>> community/Charles fix-answer most of the issues I have been having, >>> however, I am currently having an issue when launching machinekit that I >>> can't figure out. >>> >>> I am running a Beaglebone Black with CRAMPS cape attached. The setup is >> a 4 >>> axis CNC, this is the BCNC Bamboo CNC project that I have posted about >>> earlier in the machinekit group - if you recognize it. >>> >>> I launch the config selector from the command line and select the config >> I >>> have. This all seems to work fine. I then get the machinekit splash >> screen, >>> and then nothing. In the terminal, it seems to be stuck on the line >>> "Waiting for /sys/class/uio/uio0..." but nothing ever loads. I'm >>> not sure what this means, or how to fix the problem. I was looking into >>> what this error means and saw some discussions in this group about the >>> Linux booting process? I wasn't able to completely understand what was >>> wrong or how to fix it, so any help clarifying what I should try next >> would >>> be greatly appreciated.
Re: [Machinekit] DEx(x) Mksocfpga 2019 sd-card images (final ?) Stretch quartus 15.1 release Needs urgent testers
On 5/13/2019 10:21 AM, Michael Brown wrote: > On Sunday, 12 May 2019 15:49:38 UTC+2, Michael Brown wrote: >> On Saturday, 11 May 2019 22:38:47 UTC+2, Charles Steinkuehler wrote: >>> On 5/11/2019 1:17 PM, Michael Brown wrote: >>>> >>>> Next step is hopefully to get some more in depth Developer info into >>> the mk >>>> docs :-) >>>> DE10 Nano suggested development environment? >>>> <https://groups.google.com/forum/#!topic/machinekit/eVhvTnuhblE> >>> >>> I'm not sure what exactly you mean by "development environment", but I >>> typically develop directly on the system (eg: compile Machinekit & HAL >>> modules on the DE0/DE10), and use an x86 VM running Debian to build >>> the uSD images (kernel, boot loader, Debian rootfs). >>> >>> That thread was evolving into explaining how mksocfpga works... >> >> For Machinekit and HAL related stuff on armhf I personally find it easier >> and faster to use the docker based .deb builders and then either use my >> local reprepro or >> just copy the .debs over and do sudo dpkg -i *.deb > > Charles ? > I just tested compiling mk-hal here: > https://github.com/machinekit/mksocfpga/issues/47#issuecomment-491866529 There's nothing wrong with using the Docker VMs to build. I typically self-compile because I don't have an "always-on" Docker host machine added to my personal XenServer based stack yet, but I typically always have at least one ARM board running when I'm developing (the machine I'm testing). Often I've got a fast multi-core ARM system with high-speed storage (eg: Zynq Ultrascale+, BeagleBoard X15) on-line I can use as a build machine. Just pick whatever works best for you. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/1f0acc94-e3e2-1e4b-24f0-cc5545b0f30b%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Installing/Troubleshooting machinekit
That sounds like something to do with the overlays. IIRC, I didn't have to do anything with the latest uSD image and the PRU UIO devices were there. Robert Nelson is the expert on the latest U-Boot overlays, but I have seen others have problems if their on-board eMMC boot loader was too old. Send the output of "sudo /opt/scripts/tools/version.sh" and we should be able to figure out what's wrong. On 5/15/2019 12:26 PM, Bradley Turner wrote: > Hello, > I have had lots of help throughout the setup process of getting machinekit > to work properly/Charles graciously got our HAL and INI files working > beautifully. I have been able to fix/troubleshoot/have the > community/Charles fix-answer most of the issues I have been having, > however, I am currently having an issue when launching machinekit that I > can't figure out. > > I am running a Beaglebone Black with CRAMPS cape attached. The setup is a 4 > axis CNC, this is the BCNC Bamboo CNC project that I have posted about > earlier in the machinekit group - if you recognize it. > > I launch the config selector from the command line and select the config I > have. This all seems to work fine. I then get the machinekit splash screen, > and then nothing. In the terminal, it seems to be stuck on the line > "Waiting for /sys/class/uio/uio0..." but nothing ever loads. I'm > not sure what this means, or how to fix the problem. I was looking into > what this error means and saw some discussions in this group about the > Linux booting process? I wasn't able to completely understand what was > wrong or how to fix it, so any help clarifying what I should try next would > be greatly appreciated. > Many thanks appreciated for any help anyone can provide. > Thank you for your time, > > Bradley > -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/cc9cb0a8-a8ac-5917-ad07-cf5d8d4a9f1a%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: DE10 Nano suggested development environment?
hostmot2 has both in and in_not pins, just use the one appropriate for your wiring. There is also an invert_output parameter if you need to invert the output signal: http://www.machinekit.io/docs/man/man9/hostmot2/#general-purpose-i-o On 5/12/2019 6:21 AM, justin White wrote: > Got another silly question > > Is it possible to invert the default state of the GPIO pins? I've found > that pulling them up will bring them true, Hardware wise the easiest way > I've found to make the inputs capable of handling multiple input voltages > will require them to be pulled down when activated, so I'd have to pull > them up to a "false" state. This would only be something I need to do with > the gpio inputs. > > On Friday, May 10, 2019 at 6:40:30 PM UTC-4, Michael Brown wrote: >> >> Ok >> Great to hear you have progress. >> >> On a side note: >> I managed to find the bug in the ADC system and the fix got out into the >> socfpga-rbf deb yesterday :-=) >> >> On Friday, 10 May 2019 22:26:13 UTC+2, justin White wrote: >>> >>> When you are laying out your own custom DExx interface board, you don't >>>> have to stay restricted to allready made pinouts. >>> >>> Yeah that I know, Like I said, I was mostly trying to determine how many >>> pins each tag type used and it's actual usage. I was a bit hung up on the >>> ADC thing because it didn't directly correspond with the pin tags but now I >>> realize it's an SPI interface. >>> >>> I'll have to come back to all of the above info once I try to create the >>> new FPGA project files, for now I think I get the idea. >>> >>> Purging the installed Machinekit packages and installing the new ones as >>> you suggested got HALshow working right away. >>> >>> I've pretty much got my encoder interface and output hardware sorted, I >>> use 24v I/0 but it should handle multiple voltages. >>> >> > -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/a47992cb-29ef-6b8f-ac3c-d6a56ea73c32%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] DEx(x) Mksocfpga 2019 sd-card images (final ?) Stretch quartus 15.1 release Needs urgent testers
On 5/11/2019 1:17 PM, Michael Brown wrote: > Dear All > I have just uploaded what I hope to be a final 100% bugfree Mksocfpga > Debian stretch sd-card release > containing a one size fits all console and desktop version for the: > Terasic (Alters/Intel) Cyclone V based dev boards. > DE0_Nano_Soc and DE10_Nano > > Features: > An updated version of the release last year. > Kernel update adds LTC spi functionality and framebuffer > rootfs has a fix for dual ethernet address. > > https://github.com/the-snowwhite/soc-image-buildscripts/releases/tag/2.1 > > As a companion I have this fresh getting-started documentation that can be > improved by your review and feedback: > And then submitted as a PR to the Docs > > https://github.com/the-snowwhite/machinekit-docs/blob/DEx_work/docs/getting-started/machinekit-images.asciidoc > https://github.com/the-snowwhite/machinekit-docs/blob/DEx_work/docs/getting-started/u-boot-mksocfpga-altera-initial.asciidoc Great work Michael!!! How are you building U-Boot and the Kernel (or are you using pre-compiled versions from somewhere)? I have found the Altera and Rocket-boards build process to be very "fragile", requiring a lot of manual intervention to get things to build. > Next step is hopefully to get some more in depth Developer info into the mk > docs :-) > DE10 Nano suggested development environment? > <https://groups.google.com/forum/#!topic/machinekit/eVhvTnuhblE> I'm not sure what exactly you mean by "development environment", but I typically develop directly on the system (eg: compile Machinekit & HAL modules on the DE0/DE10), and use an x86 VM running Debian to build the uSD images (kernel, boot loader, Debian rootfs). -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/825462a8-cd4f-a5ec-3307-51f3bb30ce51%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: DE10 Nano suggested development environment?
On 5/6/2019 4:42 PM, mib.holotro...@gmail.com wrote: > On Monday, 6 May 2019 19:32:47 UTC+2, justin White wrote: > > I'm still trying to find some info on some of the "tags" used in the hm2 >> vhd files, I don't suppose this is documeted somewhere? >> > Have you whached the presentation Charles linked to ? In addition to the recorded presentation, you can get the slides I used from github: https://github.com/cdsteinkuehler/Presentations/tree/master/2017.04.29.Machinekit_Meetup -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Looking for a solid model for a cramps board
On 5/4/2019 4:12 PM, Tom M wrote: > I was looking for a solid model for a cramps board to design an enclosure > around. Any chance someone has one? Michael Brown should have one. He sent a PR updating the CRAMPS board files to support KiCad V5 so he could generate a 3D model: https://github.com/cdsteinkuehler/bobc_hardware/pull/5 -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: DE10 Nano suggested development environment?
On 5/4/2019 11:03 AM, justin White wrote: > > Charles, > I haven't really done anything with Quartus yet so bear with me. Searching > for this specific answer I haven't really found anything. > > The hm2 .vhd file (and presumeably other .vhd files) are part of building > the .rbf file in Quartus correct? So if I wanted to apply a different pin > configuration I would re-write this .vhd file and apply it in Quartus to > build the new .rbf, is that correct? > > I'll look into the specifics of doing it when the time comes, I'm just > trying to get the gyst of how that works. Short answer...it's complicated. :) This might help get you started, it's a presentation I gave at one of the Machinekit meetups regarding the SoC+FPGA stuff: https://www.youtube.com/watch?v=veM83KCytuQ Basically, if you want to customize something, you need to create a new config or modify an existing one. The existing configs are found here: https://github.com/machinekit/mksocfpga/tree/master/HW/hm2/config ...and the PIN_*.vhd file is where the "magic" happens. The rest of the design will elaborate and instantiate the logic defined in the PIN file. So you edit/create an appropriate PIN file, then make sure your FPGA project uses *that* PIN file when building. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: DE10 Nano suggested development environment?
On 5/2/2019 10:29 PM, justin White wrote: > I'm not quite sure what to do with the vhd > file either at the moment, does it got loaded from the hal file. Also any > idea why halshow fails to load from the Axis GUI? The VHD files are VHDL code describing the logic inside the FPGA. This code gets compiled by the vendor tool-chain and turned into a configuration file used to program the FPGA. You asked earlier about HM2 to support encoder interfaces. The HM2 driver already supports all the different types of logic currently implemented in the FPGA, including encoder, stepgen, pwm, smart serial, etc. To get an encoder to show up, just program the FPGA with an appropriate configuration file and the HM2 driver will detect the encoder instances. It sounds like Michael is helping you with an appropriate FPGA configuration. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] compile/link PRU program
On 5/1/2019 5:58 PM, Jon Elson wrote: > I have the latest Machinekit build (4.19.31-bone-rt-r31 #1stretch PREEMPT > RT) and am trying to set up to build PRU programs. > I got the compiler includes and pasm running, now when I compile a program > using prussdrv, I don't have the prussdrv library. > > The error I get is : > /usr/bin/ld: cannot find -lprussdrv > collect2: error: ld returned 1 exit status > > Does anybody know what package to install to get these files? AFAIK, there isn't a package. You can build from the Machinekit source tree, or the original source from github (see /pru_sw/app_loader): https://github.com/beagleboard/am335x_pru_package The Submakefile in src/hal/support has the hooks for building prussdrv (and the pasm assembler) in the Machinekit source tree (very similar to the LinuxCNC Makefile & Submakefile setup if you're familiar with that). NOTE: The Machinekit build considers prussdrv.c just another C file, which is the easiest way to build (just add the files to your project and include them in your build process). If you want to actually install prussdrv as a system-wide library, the original Makefile from the beagleboard am335x_pru_package is more appropriate for that. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] compiling c with prussdrv
On 5/1/2019 5:27 PM, Jon Elson wrote: > So, I have some old test programs with compiled ARM and PRU binaries, and > they seem to work. Now, I need to create new programs on the > 4.19.32-bone-rt-r31 kernel. > I didn't know where to find the includes for the prussdrv, so I got them > off my old bone system. That might be a mistake, they seem to conflict > with the current docs and also the code which I did compile on a previous > system. > > Anyway, when compiling with this command : > g++ $1.c -o $1 -lpthread -lprussdrv > > I get these errors : > test.c: In function ‘int main()’: > test.c:74:50: error: too few arguments to function ‘int > prussdrv_exec_program(int, const char*, int)’ > prussdrv_exec_program (PRU_NUM, "./test.bin"); > ^ > In file included from test.c:13:0: > /usr/include/prussdrv.h:172:9: note: declared here > int prussdrv_exec_program(int prunum, const char *filename, int > disabled); You're missing the disabled flag. > ^ > test.c:75:43: error: too few arguments to function ‘int > prussdrv_pru_wait_event(unsigned int, int*)’ > prussdrv_pru_wait_event (PRU_EVTOUT_0); >^ > In file included from test.c:13:0: > /usr/include/prussdrv.h:160:9: note: declared here > int prussdrv_pru_wait_event(unsigned int host_interrupt, int > *event_count); > ^~~ You're missing *event_count > Both of these function calls SEEM to have the right number of arguments! > > How should I install the right include files for the pruss driver? There is no "pruss driver", the UIO driver used to talk to the PRU is part of the kernel source. The prussdrv library used to facilitate controlling the PRU was written by TI, and I think I initially got it from github somewhwere (likely in the old BeagleBone PRU support files repo). The version I use has been pulled into the Machinekit source tree, see the files with "prussdrv" in the name: https://github.com/machinekit/machinekit/tree/master/src/hal/support/pru -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: how to configure PRU pins ?
On 5/1/2019 4:21 PM, Robert Nelson wrote: > On Wed, May 1, 2019 at 4:12 PM Jon Elson wrote: >> >> OK, now I seem to have (maybe) got it! So, I put in : >> ###Custom Cape >> dtb_overlay=/lib/firmware/cape-universalh-00A0.dtbo >> >> And I seem to have both the uio_pruss module loaded, AND all the P8 pins >> available! > > So, you shouldn't have to force that overlay, as out of the box, we > have cape-universal auto-loading.. Does U-Boot automatically change the universal overlay loaded when you disable on-board "capes" like the eMMC and HDMI? -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: how to configure PRU pins ?
On 5/1/2019 2:03 PM, Jon Elson wrote: > > > On Tuesday, April 30, 2019 at 6:00:51 PM UTC-5, Charles Steinkuehler wrote: >> >> Is there a reason you like beating your head against the wall? >> >> Just let U-Boot load the universal and PRU-UIO overlays, and use >> config-pin to setup the PRU direct inputs/outputs. >> >> YES, config-pin is clearly what I needed, but never found anywhere in the > docs/discussion! OK, so now, I'm trying to get it to work, but run into: > $ sudo config-pin P8_45 pruout > [sudo] password for elson: > P8_45 pinmux file not found! > bash: /sys/devices/platform/ocp/ocp*P8_45_pinmux/state: No such file or > directory > Cannot write pinmux file: /sys/devices/platform/ocp/ocp*P8_45_pinmux/state You'll need to disable HDMI to use those PRU pins on P8: https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Disable_on-board_devices ...I think you then need to either load a different universal overlay or a second chunk of the overlay that will add support for those pins. *checks source URL provided on eLinux page* https://github.com/beagleboard/bb.org-overlays/ Yep, if I'm reading things right, it looks like you want to load "cape-universalh-00A0.dts": https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/cape-universalh-00A0.dts ...which will create pinmux entries for the HDMI pins. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: how to configure PRU pins ?
Is there a reason you like beating your head against the wall? Just let U-Boot load the universal and PRU-UIO overlays, and use config-pin to setup the PRU direct inputs/outputs. ...or do you really want to create a custom overlay? On 4/30/2019 5:38 PM, Jon Elson wrote: > Well, this is just a big mess! I wonder if somebody could take the latest > machinekit build from 4/5 (4.19.31-bone-rt-r31 #1stretch PREEMPT RT) > and create a .dts file that selects one PRU input and one PRU output pin, > and then give me all the steps to compile it into a .dtbo and get that > installed through /boot/uEnv.tst ? > > I tried to do this hack to use include files in the .dts file by using the > c preprocessor, but the resulting file did NOT have the includes in them, > just a line > that references the name of the include file. Looking at the binary of the > .dtbo, I see the addresses of the pinmux offsets, but the setting for them > was all wrong. > > I'd really appreciate some help here, because I'm just LOST! > > Thanks, > > Jon > -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: how to configure PRU pins ?
On 4/29/2019 3:32 PM, Jon Elson wrote: > OK, so now I think I'm back to you, Charles. So, if I have the original > overlay > uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo > > loaded, the system boots up just fine. So, now I want to add my PRU pin > assignments, but adding that file locks up the Bone. What do you mean "locks up the Bone"? What's printed out on the serial console when booting? > Here's what I have in my .dts file : > Does any of this conflict with what is in the PRU-UIO file? Or, is some of > it out of date and needs to be updated? Well, you're enabling the PRU, which is almost certainly also happening in the PRU-UIO overlay as well, so that's at least one conflict. Honestly, I haven't worked at all with U-Boot overlays (other than letting U-Boot load the universal and pru overlays I need), so I'm not really familiar with what happens if you have errors. I also suspect some names have changed with the newer kernels, so it's reasonably likely something like your fragment@2 doesn't have a valid reference for in the newer 4.x kernels. You may find this blog post helpful: https://beagleboard.org/blog/2018-01-17-building-a-device-tree-overlay-for-your-new-pocketcape-design And you can always dig through the live device-tree via: /proc/device-tree/ ...to see if your overlays got loaded the way you expect. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: how to configure PRU pins ?
On 4/29/2019 2:07 PM, Jon Elson wrote: > On Friday, April 26, 2019 at 9:48:47 PM UTC-5, Robert Nelson wrote: >> >> Let's see the output of this script: >> >> sudo /opt/scripts/tools/version.sh >> >> Thanks! So, that command shows : > kernel:[4.19.31-bone-rt-r31] > uboot_overlay_options:[enable_uboot_overlays=1] > uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo] > uboot_overlay_options:[enable_uboot_cape_universal=1] > ... > > So, it looks like it is trying to do the AM335X-PRU-UIO-00A0.dtbo overlay, > but I'm guessing it is now failing for some reason? It looks like you are loading both your overlay and the universal overlay, which will conflict with each other. Just pick one or the other, not both. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] We are really stuck over this and any help anyone could provide would be greatly appreciated!
On 4/27/2019 9:36 PM, Bradley Turner wrote: > Thank you so much for the help, I am sorry for the late reply, I wasn't > able to get back to the lab until now. I'm sure those things seems super > obvious, I just don't know what to look for! I did what you said to try and > it fixed the issue on the Y (Axis 1) and the A (Axis 3), however I still > get the same issue on the Z axis (Axis 2). I tried adjusting the values up > and down, but it did not seem to affect the issue on the Z axis. Your problem with the Z axis is you do not have a feedback path. Your HAL code: # position command and feedback net emcmot.02.pos-cmd <= axis.2.motor-pos-cmd #net emcmot.02.pos-cmd => hpg.stepgen.02.position-cmd #net motor.02.pos-fb <= hpg.stepgen.02.position-fb net motor.02.pos-fb => axis.2.motor-pos-fb Creates a position command net (emcmot.02.pos-cmd) that goes nowhere and a feedback net (motor.02.pos-fb) that is not driven. > I had removed the homing earlier to try and narrow down what was causing > the issue. Once I get the joint following error and other movement errors > all cleared up I am intending to try and tackle the auto-homing-deracking > as well. Should I add this back in now, or continue with one problem at a > time? Your HAL file is pretty much a mess. I would recommend cleaning it up substantially and enabling the homing you want to use. You can debug fundamental issues (like your Z problem, above) using manual jogs with the axis unhomed. The next step would be to get homing working as desired, so you'll need the homing logic in the HAL file. > Separately I am having an issue where software - wise the axes (other than > the Z) all work correctly, however none of the motors spin. I have a > feeling that this issue is more related to the CRAMPS board, however I > figured I would mention it, as I am not sure what could be causing this. Make sure you are supplying power to the proper header on the CRAMPS board (P201, labeled MOTORS). There are several different power supply rails on the CRAMPS board and the most common cause of "nothing happens" has been the power wasn't connected properly. Another thing that can cause nothing to happen is a problem with the ESTOP chain. When the machine is taken out of ESTOP and powered on, the red ESTOP LED should be off, and the green ACTIVE LED should be on. If the ACTIVE LED (Machine Power) is not lit, the stepper drivers will be disabled by hardware. > I really appreciate all the help, I have tried to self educate, however I > haven't been able to find alot of information on configuring stuff like > this, or errors like this on machinekit, so if there is a repository where > I could learn more about it please let me know, I would love to look into > all of that. Thank you again, I have posted the (slightly) edited .hal and > .ini files. You seem to be having the most trouble with the HAL file. This is basically a plain text netlist file which creates a "wiring diagram" or schematic of the machine control logic. As with a real world schematic, things like unconnected pins or undriven nets will typically cause problems. There is a fair amount of documentation available for HAL, I would recommend you read through at least the introduction: http://www.machinekit.io/docs/hal/intro/ You don't need all the details (eg: creating new components with C or python), but you should be familiar with the concept of components, pins, signals, and functions. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: how to configure PRU pins ?
On 4/26/2019 5:40 PM, Jon Elson wrote: Any suggestions to seeing why uio_pruss is not starting? Should be a message somewhere. I have found the overlay logic and PRU support have a fairly appalling lack of helpful error messages. :-/ I recommend you start with an unmodified recent release and verify the UIO PRU driver is loaded, then add one piece at a time to try and get the configuration you want (again, it's probably easiest to just use the universal overlay unless there's a strong reason not to). -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: how to configure PRU pins ?
You need to make sure you have the UIO PRU driver enabled (vs. the remoteproc one). Both are generally available in most recent kernels, although the UIO only recently began working again for recent 4.x kernels (see this list a few months back). To enable the UIO PRU driver: https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_PRU_Options uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo On 4/26/2019 5:14 PM, Jon Elson wrote: OK, now I've done it! So, I am working with this build : Linux beaglebone 4.19.31-bone-rt-r31 #1stretch PREEMPT RT Fri Apr 5 22:32:32 UTC 2019 armv7l GNU/Linux I tried to edit my .dtbo file into /boot/uEnv.txt and saw that the uio_pruss module was no longer being loaded. Well, I tinkered around with several versions of things in /boot/uEnv.txt, and then finally put the old file back in place. But, STILL, no uio_pruss! I do see uio and uio_pdrv-genirq loaded. Any idea what caused this? Thanks, Jon -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: how to configure PRU pins ?
Yes, overlay handling has migrated to U-Boot, but the overlay files are
otherwise unchanged. There will be some differences due to kernel
versions, but these differences would exist regardless of whether you
are loading the overlay via U-Boot or the cape manager (eg: the naming
of some devices and U-Boot nodes will change depending on the kernel
version you run).
You can craft a custom overlay for your specific pin configuration, or
just enable the universal overlay and use the config-pin utility to
specify your pin configuration at run-time:
https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Cape_Universal
On 4/26/2019 4:52 PM, fun...@gmail.com wrote:
Hello,
I found this bunch of info:
https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Where_did_the_slots_file_go.3F
.
Seth
On Friday, April 26, 2019 at 3:07:18 PM UTC-5, Jon Elson wrote:
I did a Beagle Bone PRU project in 2014, based on the Machinekit build,
but otherwise not related to Machinekit. Now, I've got another similar
project.
I am working with the April 14 2019 Machinekit download.
I need 11 PRU direct outputs and 2 direct inputs. I created a .dts file
for the earlier project that is pretty close :
/dts-v1/;
/plugin/;
/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";
part-number = "BB-BONE-PRU";
version = "00A0";
exclusive-use =
"P8.45",
"P8.46",
"P8.43",
"P8.44",
"P8.41",
"P8.42",
"P8.39",
"P8.40",
"P8.27",
"P8.29",
"P8.28",
"P8.30",
"P9.26",
"P8.20",
"P8.21";
fragment@0 {
target = <_pinmux>;
__overlay__ {
mygpio: pinmux_mygpio{
pinctrl-single,pins = <
0xa0 0x05 // P8.45 PRU1_out0
0xa4 0x05 // P8.46 PRU1_out1
0xa8 0x05 // P8.43 PRU1_out2
0xac 0x05 // P8.44 PRU1_out3
0xb0 0x05 // P8.41 PRU1_out4
0xb4 0x05 // P8.42 PRU1_out5
0xb8 0x05 // P8.39 PRU1_out6
0xbc 0x05 // P8.40 PRU1_out7
0xe0 0x05 // P8.27 PRU1_out8
0xe4 0x05 // P8.29 PRU1_out9
0xe8 0x05 // P8.28 PRU1_out10
0xec 0x05 // P8.30 PRU1_out11
0x180 0x36 // P9.26 PRU1_in16 mode 6, pull-up, RX active
0x84 0x36 // P8.20 PRU1_in13 mode 6, pull-up, RX active
0x80 0x36 // P8.21 PRU1_in12 mode 6, pull-up, RX active
>;
};
};
};
fragment@1 {
target = <>;
__overlay__ {
test_helper: helper {
compatible = "bone-pinmux-helper";
pinctrl-names = "default";
pinctrl-0 = <>;
status = "okay";
};
};
};
fragment@2{
target = <>;
__overlay__ {
status = "okay";
};
};
};
end of file -
Is this syntax still correct?
And, then, how do you install the devicetree overlay?
This is how I did it before :
modprobe uio_pruss
cp BB-BONE-PRU-00A0.dtbo /lib/firmware/
echo BB-BONE-PRU:00A0 > /sys/devices/bone_capemgr.9/slots
more /sys/devices/bone_capemgr.9/slots
_end of file
But, this now gives an error,
./dtc_load: 5: ./dtc_load: cannot create
/sys/devices/bone_capemgr.9/slots: Directory nonexistent
Is there a document that explains how to do this?
Thanks much for any help!
Jon
--
Charles Steinkuehler
char...@steinkuehler.net
--
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] We are really stuck over this and any help anyone could provide would be greatly appreciated!
-cmd > > #net motor.04.pos-fb <= hpg.stepgen.04.position-fb > #net motor.04.pos-fb => axis.4.motor-pos-fb > > > # timing parameters > #setp hpg.stepgen.04.dirsetup[AXIS_4]DIRSETUP > #setp hpg.stepgen.04.dirhold [AXIS_4]DIRHOLD > > #setp hpg.stepgen.04.steplen [AXIS_4]STEPLEN > #setp hpg.stepgen.04.stepspace [AXIS_4]STEPSPACE > > #setp hpg.stepgen.04.position-scale [AXIS_4]SCALE > > #setp hpg.stepgen.04.maxvel [AXIS_4]STEPGEN_MAX_VEL > #setp hpg.stepgen.04.maxaccel[AXIS_4]STEPGEN_MAX_ACC > > #setp hpg.stepgen.04.steppin917 > #setp hpg.stepgen.04.dirpin 918 > > > > > > > > > > > > # ## > # Standard I/O - EStop, Enables, Limit Switches, Etc > # ## > > # Create estop signal chain > # Drive software estop to hardware > net estop-out iocontrol.0.user-enable-out => bb_gpio.p8.out-26 > setp bb_gpio.p8.out-26.invert 1 > > # Monitor estop input from hardware > net estop-loop bb_gpio.p8.in-17 => iocontrol.0.emc-enable-in > setp bb_gpio.p8.in-17.invert 1 > > # create signals for tool loading loopback > net tool-prep-loop iocontrol.0.tool-prepare => iocontrol.0.tool-prepared > net tool-change-loop iocontrol.0.tool-change => iocontrol.0.tool-changed > > # Axis enable signal (active low) > net emcmot.00.enable => bb_gpio.p9.out-14 > setp bb_gpio.p9.out-14.invert 1 > > # Machine power > # Use halui.machine.is-on instead? > #net emcmot.00.enable => bb_gpio.p9.out-23 > #net xenable => bb_gpio.p9.out-14 > > > # Tie machine power signal to the CRAMPS LED > # Feel free to tie any other signal you like to the LED > net emcmot.00.enable => bb_gpio.p9.out-25 > > # > # Limit Switches > # > #newsig limit-x-min bit > #newsig limit-x-max bit > #newsig limit-y-min bit > #newsig limit-y-max bit > #newsig limit-z-min bit > #newsig limit-z-max bit > > #net limit-x-min <= bb_gpio.p8.in-08 > #net limit-x-max <= bb_gpio.p8.in-07 > #net limit-y-min <= bb_gpio.p8.in-10 > #net limit-y-max <= bb_gpio.p8.in-09 > #net limit-z-min <= bb_gpio.p9.in-13 > #net limit-z-max <= bb_gpio.p9.in-11 > > # Adjust as needed for your switch polarity > #setp bb_gpio.p8.in-08.invert 1 > #setp bb_gpio.p8.in-07.invert 1 > #setp bb_gpio.p8.in-10.invert 1 > setp bb_gpio.p8.in-09.invert 1 > #setp bb_gpio.p9.in-11.invert 1 > #setp bb_gpio.p9.in-13.invert 1 > > # Uncomment if you actually have limit switches setup > # You probably want to setup homing in the INI file, as well > #net limit-x-min => axis.0.home-sw-in > #net limit-x-min => axis.0.neg-lim-sw-in > #net limit-x-max => axis.0.pos-lim-sw-in > #net limit-y-min => axis.1.home-sw-in > #net limit-y-min => axis.1.neg-lim-sw-in > #net limit-y-max => axis.1.pos-lim-sw-in > #net limit-z-min => axis.2.home-sw-in > #net limit-z-min => axis.2.neg-lim-sw-in > #net limit-z-max => axis.2.pos-lim-sw-in > > # > # Servo signals > # > > # There is currently no driver to generate pulses for actual > # radio-control style servos, but the buffered 5V output > # signals can be used as GPIO > > # !!! WARNING !!! > # BBB on-board eMMC *MUST* be disabled in order to use these! > # Drive eMMC-disabled signal high to enable signals that overlap > # with the eMMC pins on P8, otherwise they are tri-stated > # > # You also need to edit the setup.sh file to enable the GPIO pins > > # Signal the hardware that eMMC has been disabled and it is safe > # to drive the signals connected to eMMC lines (active low) > newsig eMMC-disabled bit > sets eMMC-disabled 0 > net eMMC-disabled bb_gpio.p8.out-16 > setp bb_gpio.p8.out-16.invert 1 > > # Servo signals, output only, driven by an 'ACT125 > > #newsig servo.1 bit > #newsig servo.2 bit > #newsig servo.3 bit > #newsig servo.4 bit > > #sets servo.1 0 > #sets servo.2 0 > #sets servo.3 0 > #sets servo.4 0 > > #net servo.1 bb_gpio.p8.out-25 > #net servo.2 bb_gpio.p8.out-24 > #net servo.3 bb_gpio.p8.out-23 > #net servo.4 bb_gpio.p8.out-22 > > > # ## > # PWM and Temperature Signals > # ## > > # Define signals to use elsewhere (ie: M1xx codes) > # If you change any names here, lots of things will break! > newsig e0.temp.set float > newsig e0.temp.meas float > newsig bed.temp.set float > newsig bed.temp.meas float > > > setp hpg.pwmgen
Re: [Machinekit] Re: config-pin setting for Mode 0 (gpmc) question
OK, so for that I would definitely recommend crafting your own overlay that enables the GPMC pins you need. Again, most "casual" users will not be able to do anything with GPMC, which is why it isn't part of the "universal" cape to begin with. It shouldn't be too hard to migrate your existing device tree (or overlay) to work on modern kernels. Do you have a link to the source for what you're currently running? On 4/19/2019 7:40 PM, Jeff Pollard wrote: > > Hi, > > Not taken the wrong way. > I've already used the gpmc to communicate with my fpga board. > I have a servo system based on hostmot2 and a custom driver to go between > hm2-servo and the gpmc which then 'talks' to the fpga. > This all works fine > This way way back in 2015 though. > The method of accessing the gpmc connectivity has changed a lot since I > last tried using the BBB with the old version of machinekit I was using. > Now I'm trying to update what I have to newer machinekit software (with > all the new overlays, etc.) and can no longer program the pins to allow me > to access the gpmc. > > Jeff > > > On Friday, April 19, 2019 at 4:51:17 PM UTC-7, Charles Steinkuehler wrote: >> >> On 4/19/2019 6:39 PM, Jeff Pollard wrote: >>> >>> Hi, >>> >>> Thanks Robert and Charles. >>> I've taken this: >>> >> https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/cape-universal-00A0.dts#L1551-L1562 >> >>> >>> and added what would be necessary to get the gmpc pins usable >> following >>> the convention of the rest of the file. >>> Hopefully this something I can test here... or is this something that >> has >>> to be in the "kernel" and out of my reach? >>> If I can test here, can you tell me how to compile and deploy the new >> dts >>> file so I can test it out? >> >> Don't take this the wrong way, but if you have to ask about how to >> compile a device tree (or overlay), you probably shouldn't be trying >> to use the GPMC interface. >> >> Let's take a step back...exactly what are you trying to do? >> >> -- >> Charles Steinkuehler >> cha...@steinkuehler.net >> > -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: config-pin setting for Mode 0 (gpmc) question
On 4/19/2019 6:39 PM, Jeff Pollard wrote: > > Hi, > > Thanks Robert and Charles. > I've taken this: > https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/cape-universal-00A0.dts#L1551-L1562 > > and added what would be necessary to get the gmpc pins usable following > the convention of the rest of the file. > Hopefully this something I can test here... or is this something that has > to be in the "kernel" and out of my reach? > If I can test here, can you tell me how to compile and deploy the new dts > file so I can test it out? Don't take this the wrong way, but if you have to ask about how to compile a device tree (or overlay), you probably shouldn't be trying to use the GPMC interface. Let's take a step back...exactly what are you trying to do? -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: config-pin setting for Mode 0 (gpmc) question
You are correct...you error is at a lower level than config-pin. The problem is the mode you want is not implemented by the universal overlay: https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/cape-universal-00A0.dts#L1551-L1562 You can either request an update to the universal overlay, patch it and send a PR, or migrate to using a "real" device-tree overlay. When I created the "Universal" overlay, I didn't expect many people to be trying to use the General Purpose Memory Controller. ;-) On 4/19/2019 3:08 PM, Jeff Pollard wrote: > Hi, > That makes sense, but > > I can use config-pin to set the value to something like: > * pwm* > for example: > * config-pin P8.14 pwm* > will work just fine > as will *gpio* > and > *gpio_pd, etc.* > > But, *gpmc* (mode 0) is not a valid choice i.e. config-pin p8.14 gpmc is > invalid > I tried adding it to the config-pin script for pin 8_14, but that didn't > help as it appears the problem is deeper than than. I can't change the > value of state in: > > /sys/devices/platform/ocp/ocp:P8_14_pinmux/state > > the error I get is: > > *Cannot write pinmux File: /sys/devices/platform/ocp/ocp:P8_14_pinmux/state* > > Jeff > > On Friday, April 19, 2019 at 12:39:21 PM UTC-7, Mala Dies wrote: >> >> Hello, >> >> The config-pin utility can be used in user land or user land w/ a .sh >> script and .service file to boot the board w/ the required config-pin >> utility being present. >> >> Seth >> >> P.S. If you know how to do this instead, this may work for you. So, use: >> config-pin P8.14 <--- this would be your mode, i.e. GPIO, UART, and >> etc. >> >> So, if you wanted to put in gpio in , you could if this is what you >> want. Does this sort of make sense? >> >> On Friday, April 19, 2019 at 1:55:21 PM UTC-5, Jeff Pollard wrote: >>> >>> >>> Hi, >>> >>> I'm using:* Linux beaglebone 4.14.106-bone-rt-r19 #1 PREEMPT RT Tue >>> Mar 26 19:02:06 UTC 2019 armv7l GNU/Linux* >>> >>> I started by disabling the emmc in uEnv.txt >>> >>> I then tried to modify the config-pin script for P8_14 (which would be >>> gpmc_AD14 as a starting example), but I get >>> >>> *Cannot write pinmux File: >>> /sys/devices/platform/ocp/ocp:P8_14_pinmux/state* >>> >>> Can anyone give a pointer on how to go about configuring pins to use >>> gmpc mode with the config-pin script (or any other method)? >>> >>> Thanks, >>> >>> Jeff >>> >> > -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Transition to Machine Kit for fully custom LinuxCNC build?
On 4/17/2019 6:47 PM, justin White wrote: > I'm still a bit sure of how the modes work because it looks like > the "BeBoPr Function" for example is using the analog inputs tor a > thermocouple but analog inputs are only available in mode 0 but GPIO on > header2 is only available in mode 7. I assumed that the modes were set for > the whole header or PRU but now I'm guessing that each pin can be mode set > individually? Yes, each pin has it's own "mode" setting to select among up to 8 independent functions. All of the digital I/O pins can be GPIO pins, and each specific pin has various other possible functions (eg: pwm, uart, i2c, timer, etc). However, the analog pins are generally dedicated for use as ADC inputs, so they cannot be arbitrary GPIO pins. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] We are really stuck over this and any help anyone could provide would be greatly appreciated!
Stepper motors are (typically) open-loop, but the motion control logic in Machinekit and LCNC are closed-loop. That many joint following errors probably means you either have problems with your HAL file (typically a goof in how the position command and position feedback signals are connected) or there's some other basic problem (eg: your scale is far enough out of wack that it's impossible for the stepgen instances to keep up with the commanded positions). Post your INI & HAL file and we can review. It looks like there's a link to your HAL file, but Google is being weird and I can't open it. Also, we'd typically need to see your INI file as well unless you aren't pulling any ini values into your HAL file. On 4/16/2019 10:17 AM, jonas hauptman wrote: > Our team working on the bamboo CNC project is really stuck over this issue, > any help would be greatly appreciated. > > The machine information can all be found below (and I have posted before if > you recognize the posts). I used someones HAL file for gantry deracking for > an MPCNC, and changed the settings to accommodate to my motion setup. When > I go to move the axes in the GUI (AXIS) I get "joint 1 following error", > "joint 2 following error", and "joint 3 following error". Joint 1 (X - > Axis) works just fine. I am not sure what these errors mean, or how to fix > them, so any information y'all could provide would be greatly appreciated. > I will post my .hal file and some accompanying documentation/photos. I have > learned that the following error is related to motors, and the BeagleBone > not communicating with them correctly, but I have not been able to figure > out how to fix the issues. I have the issue whether or not the motors are > connected. I have been trying to figure out why, and have been working > through the errors I get but haven't made much progress. If I am using any > terminology that isn't correct please excuse it, as I am new to this. Any > help anyone can provide would be awesome. Thank you in advance. > > https://docs.google.com/presentation/d/1a7goIQwWIO0uKRLa-KfeOs9Kg6j0zBQBgmQGL14omLM/edit#slide=id.g5047c009fb_0_5 > > Preview attachment Screen_Grab.jpg > <https://mail.google.com/mail/u/0?ui=2=6fb2ca6400=0.2=msg-f:1630982304047515506=16a269c3a3b34772=att=safe=f_jujwfdhy1> > <https://mail.google.com/mail/u/0?ui=2=6fb2ca6400=0.2=msg-f:1630982304047515506=16a269c3a3b34772=att=safe=f_jujwfdhy1> > Screen_Grab.jpg > <https://mail.google.com/mail/u/0?ui=2=6fb2ca6400=0.2=msg-f:1630982304047515506=16a269c3a3b34772=att=safe=f_jujwfdhy1> > 714 KB > <https://mail.google.com/mail/u/0?ui=2=6fb2ca6400=0.2=msg-f:1630982304047515506=16a269c3a3b34772=att=safe=f_jujwfdhy1>Preview > > attachment CRAMPS.hal > <https://mail.google.com/mail/u/0?ui=2=6fb2ca6400=0.1=msg-f:1630982304047515506=16a269c3a3b34772=att=safe=f_jujwfdh30> > CRAMPS.hal > 17 KB > <https://mail.google.com/mail/u/0?ui=2=6fb2ca6400=0.1=msg-f:1630982304047515506=16a269c3a3b34772=att=safe=f_jujwfdh30> > <https://mail.google.com/mail/u/0?ui=2=6fb2ca6400=0.2=msg-f:1630982304047515506=16a269c3a3b34772=att=safe=f_jujwfdhy1> > -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Transition to Machine Kit for fully custom LinuxCNC build?
On 4/15/2019 5:28 PM, justin White wrote: > > I started tossing around the idea of making a shield that is compatible > with both the BBB and the DE0/DE10 nano. Seems completely feasible since > the BBB headers physically sit inside of the DExx nano headers. The concern > becomes 90% about the BBB pinout because there seems to be alot of special > considerations for the BBB based on what you're willing to give up, whereas > the nano can just be configured pretty much however necessary. > > Looking at it I was starting to get a headache trying to figure out exactly > what the constraints are in regards to the "modes" and the PRUs. From all I > could dig up it looks like I wouldn't have enough PRU I/O left over to > really do anything with. I don't so much care about losing HDMI, but I'd > actually like to keep the emmc if possible. I'm pretty verse with LinuxCNC > but the BBB thing and how it all ties into the hal PRU driver is a bit > complicated. You don't really need to use PRU direct I/O for anything but encoder inputs (assuming you want to use PRU based encoders). The performance difference between using a GPIO pin as an output for step/dir or PWM is negligible vs. using the PRU direct outputs. > Is there any info on the machinekit images for the standard pin configs? > Ideally I'd like to get 4 step/direction, 1 ABZ encoder, and at least a > couple of PRU inputs/and outputs the rest I can just use the slower GPIO. > I'd like to get ahold of a pin config that is verified to work so I know > what I'm working with There are lots of choices. :) I have a number of board pinouts listed in spreadsheet form which you may find helpful: https://github.com/cdsteinkuehler/beaglebone-black-pinmux/blob/hal_pru_generic/pinmux.ods -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: testing machine-client & anddemo
This is a fairly common problem with lots of potential causes: https://superuser.com/questions/730288/why-do-some-wifi-routers-block-multicast-packets-going-from-wired-to-wireless On 4/7/2019 11:28 AM, c...@tuta.io wrote: Hi, great to hear it's working. Sorry, I didn't realize the dns-sd program and command is part of the Apple Bonjour package which I installed on my computer in the past, so I presumed it is part of Windows10 like SSH client. It's little odd to hear that connecting directly by Ethernet cable to your router solved the issue, that looks like your router created two subnetworks, for wired and wireless networking. Given how many printers use this technology and nowadays have both wi-fi and RJ-45 connection, I would think that it would cause problems. C. Dne čtvrtek 4. dubna 2019 23:30:53 UTC+2 Jeff Pollard napsal(a): Hi, Thanks for responding. I don't have dns-sd, but googled it, and started reading a bit. While reading, I realized my Windows10 PC was connected to the LAN with wifi. I directly connected the PC to the router with an Ethernet cable and it (anddemo from the BBB to the WIn10 PC) started to work. If I unplug the cable it won't work properly. So that looks like the problem - hopefully :-) Now I can try to proceed with Cetus again. Thanks again, Jeff On Thursday, April 4, 2019 at 12:14:52 PM UTC-7, ce...@tuta.io wrote: Hi, I don't know the exact image, so maybe my advice is not accurate. But on normal minimal Debian ISO, there is no avahi-daemon package installed. Machinekit does not care because it has it's libavahi-dev (or something like this), no error is thrown but services are not broadcasted to local network. On Windows 10 computer try running dns-sd -B _machinekit._tcp in command line and see if it can find anything. C. Dne čtvrtek 4. dubna 2019 0:15:53 UTC+2 Jeff Pollard napsal(a): Hi, I am trying to get machine-client to run with Cetus, but with no luck, so I've backed up to trying with anddemo. Also no luck. I'm using: bone-debian-8.11-machinekit-armhf-2019-04-01-4gb.img.xz on a BBB After downloading that to uSD I follow up with sudo apt-get update sudo apt-get upgrade then sudo nano /etc/linuxcnc/machinekit.ini to set REMOTE=1 Next I downloaded the anddemo files and then run: ./run.py From that I get: starting realtime...rtapi_msgd command: /usr/libexec/linuxcnc/rtapi_msgd --instance=0 --rtmsglevel=1 --usrmsglevel=1 --halsize=524288 rtapi_app command: /usr/libexec/linuxcnc/rtapi_app_rt-preempt --instance=0 done loading anddemo.py... done starting mklauncher... done starting configserver... done - I then try machinekit-client (both 32 and 64 bit windows versions) on my Windows PC on the network. but it can't find the BBB client in either unicast or multicast I can however ssh in to the BBB from Windows running putty, so the BBB is visible to Windows on the network. Any suggestions on how to get the communications link working properly? Thanks, Jeff -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Probotix--bb signal voltage question
On 3/15/2019 3:42 PM, Shane Roebuck wrote: > Hey guys I have machinekit setup on beaglebone with probotix--bb cape, I have > 24 volt pwr supply hooked to cape and stepper driver, the signal coming from > the cape for direction is little over 4 volts, my driver says it needs 5+ do > I need a voltage step up between the cape and driver? The driver is a Chinese > stepper driver. The step/dir pins on the Probotix cape are buffered and should be able to directly drive most any stepper driver. The schematic on the Probotix page shows a 74LS244DW used as the buffer. If this is _really_ a 74LS series (bipolar TTL) it will have asymmetrical drive and will be able to pull down better than it drives a high signal (the more modern HC and HCT series CMOS parts have symmetrical drive). So if you're driving an opto on the stepper driver, it may work better to hook it between +5V and the step/dir signal vs. the step/dir signal and gnd. If you do this, invert the pin in your HAL file to compensate. It should work pretty well either way, but it depends on the specifics of your stepper driver. Typical LS Series output specifications for reference: # Driving high Voh = 2.0V (min) at -15 mA Voh = 2.4V (min) at -3 mA # Driving low Vol = 0.5V (max) at +25 mA Vol = 0.4V (max) at +12 mA If the actual part on the cape is really an HC or HCT part[1], you will have symmetrical drive and don't really need to worry about driving high vs. driving low. [1] I don't have a cape handy to check, and it's common to use old LS part numbers on schematics because they exist in just about every vendor's library, and the newer HC, HCT, ACT, etc. families are pin-compatible with the older LS stuff. So just because the schematic says "74LS..." doesn't mean that's the part that gets used. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Mesa 6i25 & 7i76 - Operation not permitted with new Machinekit Version
On 3/6/2019 5:30 AM, schoone...@gmail.com wrote:
>
> It essentially comes down to 32 bit and 64 bit differences in data type size.
> If you then specify a format size in a printf operation, it will always
> generate
> a warning under one architecture or another.
> Assigning with a (void*) cast, will do so too, hence the making of L1 and L2
> void * probably
I don't have time to test this in Machinekit, but I've solved these
sort of issues using the intptr_t data type (which changes size based
on the architecture), so something like:
unsigned intptr_t L1, L2;
unsigned long L3;
Another option (since intptr_t isn't guaranteed to be available and
I'm not 100% the pointer casts required for fscanf wouldn't throw a
warning) is to make a union and overlap a pointer with an integer
type, eg:
union foo {
unsigned long long foo_long;
void *foo_ptr;
}
...then use the appropriate type where needed.
--
Charles Steinkuehler
char...@steinkuehler.net
--
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: Rotary CNC + Bamboo + BBB + CRAMPS?
Make sure: * Your stepper driver is installed correctly (it's easy to install them backwards or off-by-one on the pin alignment) * You are using the proper axis, there are 6 to choose from and not all get driven in the MendelMax config * You have an appropriate power supply connected to the motor power input on the CRAMPS board. There are several different power rails on the CRAMPS (Motor, Bed, Extruder, and Aux) which provides flexibility, but can make it confusing to wire up. On 3/5/2019 11:28 PM, Bradley Turner wrote: > I am working with Jonas on this project as well. I successfully installed > machine kit on the BeagleBone with a CRAMPS cape attached. I was able to > get into the desktop environment of the beaglebone and launch the > machinekit "Mendel Max CRAMPS" setup. I got into the GUI AXIS, and was able > to turn machine on/off trigger the E-steps on/off etc., but when I went to > do a test move of the machine by using the jogging commands in the GUI of > AXIS the stepper motor would not turn. In the software the preview of the > machine would move exactly like it was supposed to but the stepper would > not move. I swapped out the stepper motor to make sure that wasn't the > issue, and it was not. What could be causing this? I tried to scrub through > the .ini and .hal files for stepper driver configuration but was not able > to find it. Also is there a better machinekit config out there for the > CRAMPS board for us with a CNC? I have no problem using the Mendel Max > setup, it is just geared towards a 3D printer, and I wasn't sure if there > would be a better option already configured. > Thank you for any help you can provide. > , > On Thursday, February 21, 2019 at 10:31:53 PM UTC-5, jonas hauptman wrote: >> >> Hi, >> >> We are new to your group and to machine kit but hoping the community might >> have some feedback for us. We are trying to develop a Rotary 4 axis CNC >> router to machine bamboo poles into precise joints. We believe this >> will require six motors and also a scanning function as bamboo poles are >> highly irregular in size, shape, and straightness. Our project goal is to >> democratize CNC rotary machining with a low-cost high-performance machine >> for bamboo. A material that has a huge environmental and >> mechanical upside for both the developed and developing world. >> Presently it is difficult to use it in a high precision fashion and we hope >> to change that. Initially, we planned to use a 3d printer Arduino boards >> and Marlin to control the machine but eventually realized we would have >> trouble independently controlling six motors and true 4 axis machining. We >> have a little experience with LinuxCNC, I built a CNC Router Parts kit and >> outfitted it with a custom electronics bundle that Len from Probotix was >> kind enough to create for me around there standard control system (Unity). >> I am a huge fan of the Probotix machines and controls but we are trying to >> develop a machine that in total costs around $500 to build >> including computer, scanning camera, touch display, completely mechanical, >> electrical and CNC system. Our earlier prototypes used some open >> source components designs and still share some common strategies with >> the Sienci Mill One Kit V3. Realizing that the cost of a full computer and >> control system even on Linux was too expensive and that Arduino with GRBL >> lack the horsepower and software features we need we are trying to develop >> our strategy and prototypes around the Beaglebone with a Cramps Cape. >> >> I am posting hoping to begin to build a community around our project and >> looking for insights of any kind especially around our need of a control >> system for 4 axis and that can support our scanning needs. I have >> attached a series of schematic and photographic summaries of our progress >> and look forward to input from the community. >> >> Best regards, >> >> Jonas Hauptman >> >> >> >> >> >> >> >> >> >> >> >> > -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: Kinematics configuration for a new machine
On 2/28/2019 6:43 PM, bradley.j.wilkin...@student.uts.edu.au wrote: > > On Friday, 1 March 2019 04:42:41 UTC+11, Schooner wrote: >> >> ~ >> Machinekit has dropped software step generation and its reliance upon rtai >> kernels to get a low a latency as possible to make it work. >> The recommended stepper generation methods are FPGA card or SOC, or the >> BBB PRU >> ~ > > ok, hold the presses. > > I understood that on the BBB, machinekit off loaded the signal generation > to the extra cores set up specifically to run real-time i.o. (steps, > encoder signals & whatever), but are you telling me that machinekit is no > longer capable of running real-time on a general cpu with a real time > kernel like the preempt-RT patched linux kernel? > > If so, would that make it pointless to try and run machinekit on anything > other than a BBB (or another board with a similar set of silicon?). Are > bit-banged GPIO ports an entirely lost cause? > > Or have I misread that sentence? A slight misunderstanding on both sides. There is "real time" and there is "real time step generation". These require vastly different performance from the underlying OS regarding worst-case interrupt latency. The Linux real-time options in terms of latency (best to worst): * RTAI * Xenomai * Preempt-RT ...and the performance of each option varies dramatically depending on the CPU architecture. RTAI requires HAL code to run in kernel space, which Machinekit no longer supports. RTAI is only available for x86 platforms, and is mostly considered dead (although there has been a somewhat recent update after apx. 4 years of silence). LinuxCNC still supports RTAI if you want to go this route. Xenomai provides almost as good latency performance as RTAI but HAL code can run in usermode. Xenomai is supported by Machinekit, however, Xenomai patched kernels are not particularly common and generally have to be custom compiled by the user. The primary use case for Xenomai is the BBB, where the improved latency vs. Preempt-RT matters more than for x86. Preempt-RT provides the worst latency performance but is fine for the control (or "servo") thread and on some systems can provide results decent enough to support software stepgen. Note that newer ARM Preempt-RT kernels perform much better than earlier versions (3.x and early 4.x), so the performance gap between Preempt-RT and Xenoami is narrowing. Summary/conclusions: * RTAI is not supported by Machinekit * Pretty much any Xenomai or Preempt-RT kernel can run Machinekit well if you off-load the step generation to something else (Mesa hardware, BBB PRU, etc). * On some x86 systems, you can get a working machine using software stepgen and a Preempt_RT or Xenomai kernel. * On ARM systems, no real-time kernel works well enough to support software stepgen, so you need something else to generate the step pulses (eg: the PRU, or some of the "tricks" used on the RPi like programmed DMA to the GPIO port). * If you want good performance with "bit-banged GPIO ports", get a decent x86 machine with a parallel port and a motherboard that performs well with Xenomai or the Preempt-RT patch set. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: PRU development helper scripts/tools for Machinekit?
On 2/27/2019 9:35 AM, Damien.D wrote: > > Another question, regarding write to GPIO output register. I could also > measure it but do you happen to know how long does it take to write those > 4*2 (8 total) gpio set/clr register? > https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_wait.p#L204-L207 > > From what I understand from: > https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_generic.p#L144-L147 > each line "SBBO GState.GPIOn_CLR, State.GPIOn_CLR_ADDR, 0, 8" takes no less > than 95-105ns > > but I don't quite understand the thing that is explained about "Posted > Writes": > https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_generic.p#L149-L156 > > Are those 4 SBBO "posted writes" supposedly taking 15ns each? .. or >> 95-105ns? > https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_wait.p#L204-L207 The writes will happen quickly because the fabric interconnect is not saturated. Regarding "posted writes": The interconnect fabric has the ability to accept a small number of write requests immediately. The PRU can then carry on with other work while the write request makes its way through the interconnect to it's ultimate destination. https://en.wikipedia.org/wiki/Posted_write -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: PRU development helper scripts/tools for Machinekit?
On 2/27/2019 7:26 AM, Damien Dando wrote: > >> Sadly, the Decamux code is using state register 6, or you could use >> registers 4-7 for the GPIO values. But you can do an offset when >> performing the XIN/XOUT (set SHIFT_EN in the SPP register), so you can >> use any other chunk of 4 registers in the scratchpad (maybe R0-3?). > do you know how many PRU cycle it takes to set the SHIFT_EN bit in SPP reg.? > There is the list of timing here: > http://www.ti.com/lit/sprace8 but I don't know if SHIFT_EN is considered as a > "PRU CTRL" register, "PRU CFG" or something else.. The SPP register is in the "PRU CTRL" domain. The latency doesn't really matter, the SPP write would be a one-time setup step at the start of the code. Usually, however, writes complete quickly as they do not need a response from the far end. The existing XIN/XOUT instructions will need to make sure r0.b0 is cleared first, but that's only one additional instruction per loop (the XOUT is a one-time setup step) and it allows much more flexible use of the scratchpad. > Also how long does it takes to load data from the PRU DRAM to > r0-31, the previous link say 3PRU cycles (15ns) but does that > depends of how many bytes we load? or it takes the same amount of > time regardless of the number of bytes? I believe it will take one extra clock for each additional DWORD read from the PRU data memory. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Rotary CNC + Bamboo + BBB + CRAMPS?
On 2/26/2019 7:27 PM, jonas hauptman wrote: > Charles, > > Wow sounds awesome. In the meantime until we better understanding the basic > we are trying your cape ( one it shows up) for CNC and we build the > scanning into a second Micro Computer, ideally witg two computers able go > talk to each other. > > Any idea what the new BB will cost? Apx. $100 > Is it likely your CRAMP Cape will work > as is with it as? That's the plan. There may be some feature that don't work, or work differently, but that's likely to be things like reset and system power vs. the signals used for CNC control. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Rotary CNC + Bamboo + BBB + CRAMPS?
Please keep replies on-list. For pick-and-place, there are a few open-source projects working on solving the problem, such as OpenPNP: http://openpnp.org/ Often, the "back-end" performing the motion does use gcode. On 2/26/2019 2:01 PM, Chris Albertson wrote: > I just read the TI's paper on this. They describe the workflow for using > the machine learning and vision subsystem. And the workflow is not > super-horrible as I feared. It fact it seems straight forward if you are > already familiar with machine learning and vision. For others, the > 15-second summary is this: > > You develop your machine learning or vision system on high-end PC hardware >> (at least a nVidida GTX10XX GPU) under Linux. You use familiar tools like >> TensorFlow and openCV.Then there is TI software that takes what you >> have running on the PC and translates it to run on the much smaller device >> on the Beagle Board. The beagle is about 100x slower but speed is really >> only needed for training a network, not needed to run it. > > > For those not in the field. "Machine Learning" is almost a misnomer. The > training and learning happens on the big PC then we "freeze" a snapshot and > move it the tiny chip where it never leans or changes behavior . The > learning happens only in the lab. > > > Nowhere is my question: The most simple use case of this that relates to > Machine Kit is a pick and place machine. This is a 2-axis machine that > picks up a tiny part from a surface and drops it some other place on the > surface. It does not even have a true z-axis. But the catch is finding > the part and finding the *exact* place to drop the part. For that we need > a camera. No-one uses g-code for these machines because we can't know in > advance how the machine is to move. So what we do is tell the machine > where the parts are in general and where relative to the final assembly the > part should go. > > It seems to me this machine would replace the g-code interpreter with > different logic but otherwise could work exactly the same. Or perhaps the > g-code is not read from file but there is a process that generates it in > real time based on the camera. > > What I'd like is to use my Harbor Freight Mili mill as a picking place > machine. This would be REALLY popular., simply place a little vacuum > picker on the spindle and for very little cost you have a slow slow pick > and place machine suitable for hobby level PCB assembly. The HF mill > should be accurate enough. > > In any case, how were you planning to this vision and machine learning > hardware to MK? > > > On Tue, Feb 26, 2019 at 8:15 AM Charles Steinkuehler < > char...@steinkuehler.net> wrote: > >> FYI: >> The BeagleBone-AI may be a good fit for your project: >> >> >> https://www.facebook.com/photo.php?fbid=10218976824519992=a.2907631578284=3 >> >> It should do machine vision _much_ better than the BBB. It's >> basically the SoC from the X15 in a BeagleBone form factor. I'm >> working on getting Machinekit working on this board and verifying >> capes work as expected. >> -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: cannot post anything
Looks like the posts all got tagged as spam by Google, and for some
reason took a while to make it to the moderator inbox.
Lots of backlog should be appearing soon, and future posts should be
allowed without getting flagged.
On 2/26/2019 10:50 AM, Alexander Rössler wrote:
> Hi Damen,
>
> This problem is very common with small company addresses. Check your DKIM and
> SPF records for a start. I had the same problem until I switched from my
> custom mail server to MS Exchange and set up the DKIM records on my
> nameserver.
>
> Alex
>
> Written on my Android phone. Please excuse my brevity.
>
>
> From: machinekit@googlegroups.com on behalf of
> Bas de Bruijn
> Sent: Tuesday, February 26, 2019 5:40:36 PM
> To: Damien.D
> Cc: machinekit+own...@googlegroups.com
> Subject: [Machinekit] Re: cannot post anything
>
>
>
> On 26 Feb 2019, at 17:22, Damien.D
> mailto:damien.d...@gmail.com>> wrote:
>
> It apparently worked when posting from my phone.
> I suspect google prevent me to post on public groups from my company IP
> address. I was trying to post from my office before and my company uses
> google services for email on.. maybe they prevent posting on public groups
> when they see it comes from my company public IP even though I was logged
> with my personal google account and everything is https.
> Seems pretty weird to me but so far I cannot think about other rational
> explaination..
>
> Maybe your company prevents you?
> Anyway, i’ll consider this solved.
> Bas
>
>
> /Damien
>
> On Tue, 26 Feb 2019, 17:05 Bas de Bruijn,
> mailto:b...@basdebruijn.com>> wrote:
> Hi Damien
>
> On 26 Feb 2019, at 14:51, Damien.D
> mailto:damien.d...@gmail.com>> wrote:
>
> Hi Bas,
>
> Yes, I have been posting via the googlegroup webportail so far.
> I didn't have the email notifications enabled so I'm not sure I can answer to
> that particular post. I tried to send an email to
> machinekit@googlegroups.com<mailto:machinekit@googlegroups.com> with the same
> subject ("PRU development helper scripts/tools for Machinekit?") but I don't
> see it anywhere in the googlegroup web portail..
>
> As member of machinekit@googlegroups.com<mailto:machinekit@googlegroups.com>,
> did you got the email bellow (sent today at 13:24 UTC time)?
>
> Nope, sorry,
> I dont understand what’s going on
>
>
> I start to wonder if I got banned by google or something...
>
> /Damien
>
> -- Forwarded message -
> From: Damien.D mailto:damien.d...@gmail.com>>
> Date: mar. 26 févr. 2019 à 14:24
> Subject: PRU development helper scripts/tools for Machinekit?
> To: mailto:char...@steinkuehler.net>>
> Cc: mailto:machinekit@googlegroups.com>>
>
> ...
>
> Le lun. 25 févr. 2019 à 17:25,
> mailto:b...@basdebruijn.com>> a écrit :
> Hi Damien,
>
> I've not seen anything strange on you as a member, no bans or so.
> Are you posting thru the googlegroup portal? Can you try replying from your
> email client?
>
> Bas
>
> -Original Message-
> From: damien.d...@gmail.com<mailto:damien.d...@gmail.com>
> mailto:damien.d...@gmail.com>>
> Sent: Monday, 25 February 2019 16:47
> To:
> machinekit+own...@googlegroups.com<mailto:machinekit%2bown...@googlegroups.com>
> Subject: cannot post anything
>
> Hi,
>
> I tried to answer to my post
> https://groups.google.com/forum/#!topic/machinekit/5TIA7b-7Q1k but the answer
> got deleted as soon as I post it. I tried 7times already. And same thing
> happen when I try with my other google account (Damien D
> mailto:damien2...@gmail.com>>).
> I also tried to create a new post but it doesn't work either.
>
> I did try as well to leave Machinekit googlgroup and join again but it does
> not help, still same issue..
>
> Is it only me or is there some issue with the group settings?
>
> BR,
>
> /Damien
>
>
> --
> 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
> machinekit+unsubscr...@googlegroups.com<mailto:machinekit+unsubscr...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
>
--
Charles Steinkuehler
char...@steinkuehler.net
--
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Rotary CNC + Bamboo + BBB + CRAMPS?
FYI: The BeagleBone-AI may be a good fit for your project: https://www.facebook.com/photo.php?fbid=10218976824519992=a.2907631578284=3 It should do machine vision _much_ better than the BBB. It's basically the SoC from the X15 in a BeagleBone form factor. I'm working on getting Machinekit working on this board and verifying capes work as expected. I couldn't say anything about it earlier, but now they've announced it at Embedded World. :) On 2/24/2019 8:53 AM, Charles Steinkuehler wrote: > I'd call 1-2 minutes for scanning slow, but that depends a bit on how > much processing you're trying to do. Given that sort of time frame, I > think the main problem you might have with the BBB is running out of > memory, but again that depends on what you're trying to do. > > For the control, I'd suggest using a tablet/smart-phone and setup a > remote interface using QtQuickVcp. You might also be able to use a > camera on the tablet for your scanning. I'm not sure if that would be > easier or harder than doing the scanning with the BBB. > > NOTE: You can get a USB-OTG cable and connect most tablets directly to > the USB Client port on the BBB. The table will see the gadget > Ethernet driver on the BBB and automatically setup networking so you > don't have to communicate via WiFi. I do this with a 7" RCA Voyager > tablet I bought for ~$35. It's not a great tablet, but the > touch-screen works fine for a UI! > > On 2/24/2019 7:33 AM, jonas hauptman wrote: >> Thanks! >> >> I am not worried if the vision scanning routine takes 1-2 minutes. Is that >> in the neighborhood of fast or slow in your opinion? Another thought would >> be the run an additional beaglebone or Raspberry PI to handle human >> interface touch display and vision. Still would cost a lot less than full >> size PC and control system. >> >> What do you think? >> >> JH >> >> On Sun, Feb 24, 2019, 7:25 AM Charles Steinkuehler >> wrote: >> >>> That looks like a very interesting project! >>> >>> The BeagleBone should be able to handle the 4-axis machine control, >>> but I'm not sure about handling the vision pipeline. I know some >>> people have been doing machine vision projects with the BeagleBone, >>> but I have no personal experience in this area. I recommend asking >>> about machine vision on the BeagleBoard Google Group: >>> >>> https://groups.google.com/forum/#!forum/beagleboard >>> >>> A PC will give you *MUCH* better performance for the vision pipeline, >>> but then you will need something to move the motors, which means more >>> cost and electronics (Mesa hardware, Arduino, or even the BeagleBone). >>> >>> If you're not real worried about speed, the BeagleBone will probably >>> be able to perform the vision tasks you need, just slowly. >>> >>> On 2/21/2019 9:31 PM, jonas hauptman wrote: >>>> Hi, >>>> >>>> We are new to your group and to machine kit but hoping the community >>> might >>>> have some feedback for us. We are trying to develop a Rotary 4 axis CNC >>>> router to machine bamboo poles into precise joints. We believe this >>>> will require six motors and also a scanning function as bamboo poles are >>>> highly irregular in size, shape, and straightness. Our project goal is >>> to >>>> democratize CNC rotary machining with a low-cost high-performance >>> machine >>>> for bamboo. A material that has a huge environmental and >>>> mechanical upside for both the developed and developing world. >>>> Presently it is difficult to use it in a high precision fashion and we >>> hope >>>> to change that. Initially, we planned to use a 3d printer Arduino >>> boards >>>> and Marlin to control the machine but eventually realized we would have >>>> trouble independently controlling six motors and true 4 axis machining. >>> We >>>> have a little experience with LinuxCNC, I built a CNC Router Parts kit >>> and >>>> outfitted it with a custom electronics bundle that Len from Probotix was >>>> kind enough to create for me around there standard control system >>> (Unity). >>>> I am a huge fan of the Probotix machines and controls but we are trying >>> to >>>> develop a machine that in total costs around $500 to build >>>> including computer, scanning camera, touch display, completely >>> mechanical, >>>> electrical and CNC system. Our earlier prototypes used some open >>>>
Re: [Machinekit] Machinekit extruder problem
On 2/26/2019 7:41 AM, Ömür Ceran wrote: > I will try temperature sensor to understand the problem. Thank you for that. > But ı dont understand 'conventional' means, are you trying to say that > problem is about Ngcwriter program output or cura? İf so, do you have any > suggestion about conversion(gcode to mcode)? By "conventional" I mean the extruder is considered another motion axis which directly controls the extruder motor vs. velocity based extrusion where the extruder is controlled based on the XY velocity and a desired amount of material to extrude. You mentioned velocity based extrusion in your previous mail. If you want to setup velocity based extrusion, my config files are not the place to start. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
[Machinekit] Re: PRU development helper scripts/tools for Machinekit?
On 2/26/2019 7:24 AM, Damien.D wrote: > Le lundi 25 février 2019 17:46:06 UTC+1, Charles Steinkuehler a écrit : >> >> Personally I don't really want to see hal_pru_generic code reading >> from the fabric, it eats up too much time. I'd rather see "slow" code >> like this running on the other PRU, leaving the hal_pru_generic code >> as-is. Actually, implementing this as a "tasklet" would be fine, more below. >> That said, you're free to do what you want. If I was going to write >> something like this, I'd probably create a "GPIO read" tasklet that >> reads the input pins from the gpio bank(s) and stashes the data either >> in the register bank or in one of the scratchpad banks. Then you can >> have other tasklets that process GPIO input pin data as needed. >> > That last suggestion seems like a good idea to me. I will look in that > direction. Was it the intended purpose of the pru_read.p > <https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_read.p#L4-L6> > file? Not really. The read and write functions were intended to be similar to the hm2 functions used when communicating with slow or remote hardware (eg: EPP or Ethernet). I had intended to make a proper communication protocol between the PRU and the ARM to avoid issues when reading multiple values, but wound up being lazy and using the same hack as the software stepgen to do "atomic" reads: https://github.com/cdsteinkuehler/machine-configs/blob/master/configs/CoreXZ/CoreXZ.hal#L168-L173 Ideally, the PRU should copy the required state details at the end of a servo period and then interrupt the ARM. With the PRU driving the servo thread timing the motion calculations are all more accurate and the PRU state read by the ARM will be completely consistent to a single point in time (currently it's possible the PRU executes a few cycles while the ARM is reading/processing the data on the servo thread). But I haven't had the time or inclination to get this coded up and working. Feel free to re-purpose the pru_read.p function shell or create a new one. >> ...but really I think you'd be best off just using a PRU direct input >> pin. IIRC you said you're using a CRAMPS board. If so, several of >> the SPI signals function as direct PRU inputs and are already tied to >> a connector via a FET bus level translator so they are bidirectional >> and 5V tolerant: >> >> P9.28 SPI_CS0 >> P9.29 MISO >> P9.30 MOSI >> P9.31 SCK >> >> P503 on the CRAMPS board. >> > I'm not using a CRAMPS board, this does not fit my need. I made my own > board (with opto-isolated "satellite" boards): > https://youtu.be/bn6DsqG35MU?t=58 > > PRU direct inputs are indeed easy to use from software point of view. > However from a practical point of view, in a real scale project it's > another story.. In my case, with all hardware I have connected to the BBB, > I don't have so much choice regarding the pinout/connections (which I have > already been thinking quite a lot when doing the electronic > design). 35 IOs seems quite a lot at first but in my project they are > already all used, and many have specific need that cannot be exchanged with > others (encoders, UARTs, SPI). I could possibly free up 2IOs at max (by > grouping some enable signals) but that's all. And most of those PRU input > are shared with the hardware encoder which I'm using, and same thing for > the SPI0 pins :/ > > Performance wise, there is no gain of using PRU inputs (in my case) since I > read a few millisecond signal. I use a PRU period of 5000ns of which at the > moment 4000ns are spent in the wait loop so that's only ~1000ns of active > time to run the all PRU period... thanks to your well optimized code :) ! > If I ever had need to go down to ~1000ns PRU period, I would be more > concerned about hardware limitations than the software ones :) I typically use PRU periods around 2-3 uS, so the GPIO read is a bigger chunk of the timing budget. If you make the GPIO reads and timer processing individual "tasklets", I have no issue with merging them into master. Given the way the PRU code works, there isn't much down-side to having the tasklets available: just a bit more PRU program memory consumed (we're no where near the limit at the moment) and they won't slow down the PRU processing if they aren't being used. I would recommend making the read tasklet configurable so that it will optionally read any/all of the GPIO banks. I'd probably use the task state registers for the GPIO values (R4-11) and have the read tasklet stash the GPIO values in the scratchpad, similar to what I did with the GPIO address values: Stash the values in the scratchpad: https://github.com/machinekit/machine
Re: [Machinekit] Machinekit extruder problem
On 2/26/2019 7:06 AM, Ömür Ceran wrote: > Actually ı am using cura with Ngcwriter extension.I sliced a stl file and > save it as a .ngc and upload in machinekit program.Machinekit shows the file > which ı uploaded but when ı run the program, it does not work. I should say > that, ı did not connect any sensor or motor yet. Can it be about temperature > sensor? That is definitely a possibility. > Also ı want to ask you, there is no code which is velocity extrusion enable > or how many extruder is connected(for definition) in your configuration. > Before adding them,machinekit gave a problem for that. Do ı need to add them? > I know that 'A' is used for extruder but ı used remap code(gcode to mcode). I do not currently have any machine configurations setup for velocity based extrusion, all my machines use "conventional" position commands for the extruder axis. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Machinekit extruder problem
On 2/26/2019 12:46 AM, Ömür Ceran wrote: > Hi there, > I try to make a corexy printer but there are a few problem. > When ı upload a sketch and run machine, motor does not work as a 3d printer > but when ı upload normal cnc .ngc file, it is working. Also ı had another > problem about velocity extrusion enable. I use configuration which belongs to > charles stein corexy. Can you help me about that? How can ı configure it for > corexy and solve spindle to extruder? > https://github.com/cdsteinkuehler/machine-configs/tree/master/configs/CoreXZ To switch from CoreXZ to CoreXY, change the axes used by the CoreXY module: https://github.com/cdsteinkuehler/machine-configs/blob/master/configs/CoreXZ/CoreXZ.hal#L65-L76 I'm using axis.0 (X) and axis.2 (Z), you'll want axis.0 (X) and axis.1 (Y). You may also want to swap which control signals are fed to the motor drivers, eg: https://github.com/cdsteinkuehler/machine-configs/blob/master/configs/CoreXZ/CoreXZ.hal#L168-L173 You don't provide enough detail about your extruder issues to know what's going wrong, but Machinekit will expect extruder moves to be on the "A" axis, while typical slicing programs use the "E" axis. You can either get a slicer that outputs Machinekit/LinuxCNC/Mach style gcode, post-process the gcode file, or setup gcode remapping to handle the typical RepRap style gcode. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: Message privé sur le sujet suivant : [Machinekit] PRU development helper scripts/tools for Machinekit?
GPIOn_Set. To avoid conflict with other GPIO outputs, only store >bits/pins where a read was requested. Then the PRU module/task that >requested the reading can read the pin state in GPIOn_Set on the next >pru period. > > or maybe there is some easier solution allocating/using PRU RAM instead of > direct PRU register r0-32 (GPIOn_Clr / GPIOn_Set)... > What are you thought? Do you have any better implementation idea/suggestion? Personally I don't really want to see hal_pru_generic code reading from the fabric, it eats up too much time. I'd rather see "slow" code like this running on the other PRU, leaving the hal_pru_generic code as-is. That said, you're free to do what you want. If I was going to write something like this, I'd probably create a "GPIO read" tasklet that reads the input pins from the gpio bank(s) and stashes the data either in the register bank or in one of the scratchpad banks. Then you can have other tasklets that process GPIO input pin data as needed. ...but really I think you'd be best off just using a PRU direct input pin. IIRC you said you're using a CRAMPS board. If so, several of the SPI signals function as direct PRU inputs and are already tied to a connector via a FET bus level translator so they are bidirectional and 5V tolerant: P9.28 SPI_CS0 P9.29 MISO P9.30 MOSI P9.31 SCK P503 on the CRAMPS board. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] Re: MLX IR Temperature Sensor HAL Component
There's no hard and fast rule about what to do with hal components. I just put the files on github because I don't really expect a lot of people running Machinekit to need to talk to one of these sensors. If for some reason it does catch on and become popular, the comp file can be easily merged into Machinekit. If anyone does have a HAL component they'd like to share, just add it to user_comps and send a PR: https://github.com/machinekit/machinekit/tree/master/src/hal/user_comps On 2/24/2019 1:08 PM, c...@tuta.io wrote: > Hi, > > what's the default for creating new HAL components? Some people merge it to > the Machinekit master, some just have it sit in public repository on > Github. I guess that I understand the reasoning behind both reasonings. > This way does not mess the master with one off components, but merging it > to the master means that it is readily accessible and easy to find. > > Thanks > Cern. > > Dne neděle 24. února 2019 18:05:23 UTC+1 Charles Steinkuehler napsal(a): >> >> In case it's useful to anyone else: >> >> I have written a simple HAL component to interface to an MLX90621 >> temperature sensor. This part measures the ambient temperature of the >> part itself, and provides a 4x16 pixel array of IR temperature >> sensors. The code is mostly from a project for the Rpi, modified >> first to use the standard Linux I2C infrastructure (the Rpi version >> talks directly to the Broadcom hardware) and then to function as a HAL >> component. >> >> Currently the component only outputs two values, the ambient >> temperature and an average of all 64 IR values for the remote >> temperature. I may add ring buffer support to be able get all the >> pixel values at once, but currently all I need is the average. >> >> Source is on github: >> https://github.com/cdsteinkuehler/mlxd/tree/halcomp >> >> >> Tested with the MLX90621 on a BeagleBone, but it should work with the >> MLX90620 (edit the #define in the source) and any system with a >> standard Linux I2C bus available (eg: /dev/i2c0). >> >> -- >> Charles Steinkuehler >> cha...@steinkuehler.net >> > -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
[Machinekit] MLX IR Temperature Sensor HAL Component
In case it's useful to anyone else: I have written a simple HAL component to interface to an MLX90621 temperature sensor. This part measures the ambient temperature of the part itself, and provides a 4x16 pixel array of IR temperature sensors. The code is mostly from a project for the Rpi, modified first to use the standard Linux I2C infrastructure (the Rpi version talks directly to the Broadcom hardware) and then to function as a HAL component. Currently the component only outputs two values, the ambient temperature and an average of all 64 IR values for the remote temperature. I may add ring buffer support to be able get all the pixel values at once, but currently all I need is the average. Source is on github: https://github.com/cdsteinkuehler/mlxd/tree/halcomp Tested with the MLX90621 on a BeagleBone, but it should work with the MLX90620 (edit the #define in the source) and any system with a standard Linux I2C bus available (eg: /dev/i2c0). -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
