Re: [Machinekit] 5-axis simultaneous, G-codes?

['schoone...@btinternet.com' via Machinekit]

Not a subject I know much about, this seems to give the best overview of 
the kinematics.


http://linuxcnc.org/docs/ja/html/motion/5-axis-kinematics.html

I think the XYZAC example at the very end is nearest what you are 
proposing, with A and C rotating in relation to Z


The G codes remain the same, but the plane in which the axis operates 
may limit them.


Regards post processors, usually one for Mach is a good starting point, 
being generally compatible.


Quite a few CAM packages have linuxcnc posts, either in the package or 
as something available either from their forum or the linuxcnc forum. So 
check either before you choose a CAM or before you write your own.




On 17/02/2018 23:51, Damien D wrote:

Hi,

I'm planning on building a 5axis plasma cutter similar to this one 
 but 
with one more axis to tilt the torch head.
I'm thinking of starting from the existing maxkins kinematics (XYZBC) 
and then modify it to my needs.


Sorry if some questions seem 'stupid' but I'm quite new in CAM.. I'm 
googling around and try to understand how the 5axis interface works 
between CAM softwares and CNC controller (Machinekit).


What I'm struggling to understand is what will be the G-codes 
supported by Machinekit if I use the "maxkins" configuration?


Does Machinekit support RTCP (Rotating Tool Center Point) like in this 
video . If yes, what are 
the G-codes commands Machinekit can understand to handle RTCP?


I would need to know that to chose/configure the post-processor.
Or Maybe I should rather ask what post-processor (configuration) 
should I use to produce G-code that can be understood by Machinekit?


Thanks for your help,

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

Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.


--
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] Replicape overlay not setting pru GPIO outputs

[Karl Jacobs]

The fact that cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups among 
others shows

group: pinmux_replicape_spi1_pins
pin 100 (PIN100)
pin 101 (PIN101)
pin 102 (PIN102)
pin 89 (PIN89)

and
group: pinmux_pruicss_stepper_pins
pin 14 (PIN14)
pin 15 (PIN15)
pin 10 (PIN10)
pin 11 (PIN11)
pin 13 (PIN13)
pin 12 (PIN12)
pin 9 (PIN9)
pin 8 (PIN8)
pin 31 (PIN31)
pin 30 (PIN30)

makes me believe that the cape is actually loaded, but I might be wrong. 
The full dmesg does not show anything like "REPLICAP" anywhere else but on 
the lines that are contained in my uploaded file. Actually I haven't found 
a hint anywhere where to look for an actual version of the loaded cape in 
the "slotless" uboot-overlays. The original sam0737 code looks for that in 
the slots file to decide between two different Replicape board versions. I 
hardcoded the board version to 0B3A.

 I also could not find any hint for the overlay in the /proc/device-tree 
although I have to admit that I wouldn't know for what to look exactly. Am 
I mistaken to assume that the overlay file is loaded if all other functions 
like temperature readings, endstops are working, spi init works, setting 
motor current (needs spi) does not give error messages?

Commenting the uboot_overlay_pru line in uEnv.txt + reboot did not change 
anything. 
cat /sys/class/uio/uio0/name still shows pruss_evt0 as expected and the pru 
works as before when I manually set the output pin. It seems that the uio 
pruss is the default.
Setting uboot_overlay_addr0=/lib/firmware/BB-BONE-REPLICAP-0B3A.dtbo in 
uEnv,txt also shows no difference (it does if you misspell the filename: 
BBB does not complete the boot in that case).
Regards,
Karl

Am Samstag, 17. Februar 2018 20:14:06 UTC+1 schrieb Charles Steinkuehler:
>
> On 2/17/2018 3:18 AM, Karl Jacobs wrote: 
> > 
> > The BB-BONE-REPLICAP-0B3A.dtbo is loaded via u-boot load as you can see 
> > from the attached file 
> > giving the details on version.sh, dmesg and uEnv , where you can see 
> that I 
> > disabled HDMI, EMMC and 
> > cape-universal. 
>
> I see that the Replicape was detected, but not that it's overlay was 
> loaded.  I think you need to manually load the overlay with U-Boot, or 
> possibly copy the overlay somewhere U-Boot can access it and it might 
> get loaded automatically (I'm not sure which, I haven't worked much 
> with the U-Boot overlays). 
>
> You can verify if the replicape overlay was actually applied by 
> browsing through the active device-tree (/proc/device-tree/...) 
> regardless of how the overlay was loaded and by examining the *FULL* 
> output of dmesg if the kernel loaded the overlay. 
>
> Your problem could also be that you're trying to load the pruss driver 
> using "uboot_overlay_pru=", but the Replicape overlay is also enabling 
> the PRU and the PRU driven pins are exported in the same overlay 
> stanza that enables the PRU: 
>
>
> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-REPLICAP-0B3A.dts#L137-L142
>  
>
> Try commenting the uboot_overlay_pru line in your uenv.txt file and 
> see if that helps. 
>
> -- 
> Charles Steinkuehler 
> cha...@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] 5-axis simultaneous, G-codes?

[Damien D]

Hi,

I'm planning on building a 5axis plasma cutter similar to this one 
 but 
with one more axis to tilt the torch head.
I'm thinking of starting from the existing maxkins kinematics (XYZBC) and 
then modify it to my needs.

Sorry if some questions seem 'stupid' but I'm quite new in CAM.. I'm 
googling around and try to understand how the 5axis interface works between 
CAM softwares and CNC controller (Machinekit).

What I'm struggling to understand is what will be the G-codes supported by 
Machinekit if I use the "maxkins" configuration?

Does Machinekit support RTCP (Rotating Tool Center Point) like in this video 
. If yes, what are the G-codes 
commands Machinekit can understand to handle RTCP?

I would need to know that to chose/configure the post-processor.
Or Maybe I should rather ask what post-processor (configuration) should I 
use to produce G-code that can be understood by Machinekit?

Thanks for your help,

/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.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Replicape overlay not setting pru GPIO outputs

[Charles Steinkuehler]

On 2/17/2018 3:18 AM, Karl Jacobs wrote:
> 
> The BB-BONE-REPLICAP-0B3A.dtbo is loaded via u-boot load as you can see 
> from the attached file
> giving the details on version.sh, dmesg and uEnv , where you can see that I 
> disabled HDMI, EMMC and 
> cape-universal.

I see that the Replicape was detected, but not that it's overlay was
loaded.  I think you need to manually load the overlay with U-Boot, or
possibly copy the overlay somewhere U-Boot can access it and it might
get loaded automatically (I'm not sure which, I haven't worked much
with the U-Boot overlays).

You can verify if the replicape overlay was actually applied by
browsing through the active device-tree (/proc/device-tree/...)
regardless of how the overlay was loaded and by examining the *FULL*
output of dmesg if the kernel loaded the overlay.

Your problem could also be that you're trying to load the pruss driver
using "uboot_overlay_pru=", but the Replicape overlay is also enabling
the PRU and the PRU driven pins are exported in the same overlay
stanza that enables the PRU:

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-REPLICAP-0B3A.dts#L137-L142

Try commenting the uboot_overlay_pru line in your uenv.txt file and
see if that helps.

-- 
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: Replicape overlay not setting pru GPIO outputs

[Karl Jacobs]

Correction:
root@beaglebone:/sys/kernel/debug/pinctrl/44e10800.pinmux# more pins | grep 
87c
pin 31 (PIN31) 44e1087c 0007 pinctrl-single

Am Samstag, 17. Februar 2018 10:18:06 UTC+1 schrieb Karl Jacobs:
>
> Hello,
>
> I am trying to setup my Kossel mini printer with  Replicape version 0B3A 
> on a BBB with machinekit.
> I used https://github.com/sam0737/machinekit-replicape in its 
> ARM.Replicape.B3 version adapted to the newest
> stretch machinekit package 
> bone-debian-9.3-machinekit-armhf-2018-02-11-4gb.img.xz (the changes being 
> to adapt to the 
> "slotless" cape loading and to correct the .icomp components). 
>
> The BB-BONE-REPLICAP-0B3A.dtbo is loaded via u-boot load as you can see 
> from the attached file
> giving the details on version.sh, dmesg and uEnv , where you can see that 
> I disabled HDMI, EMMC and 
> cape-universal.
>
> Machinekit starts up fine, I can see the extruder and hotbed temperatures, 
> pwm working, endstops working etc.
> so it seems that the cape is loaded allright. I can also read the cape 
> eeprom.
> The only thing not working is that the output pins of the pru (like x-dir 
> on P8.26) do not show any signal
> but stay low. I have to manually set
>
> echo "61" > /sys/class/gpio/export
> echo "out" > /sys/class/gpio/gpio61/direction
>
> to have the pru toggle the x-direction pin on P8.26 (with kernel gpio 
> number 61) as an example.
> pru itself (with uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo) 
> obviously works.
> In the code of sam0737 the hpg.stepgen.00.dirpin is set to 826, and that 
> is confirmed with halshow.
>
> I was expecting that the overlay would set the outputs for the pru, as in 
> BB-BONE-REPLICAP-0B3A.dts
>
> pruicss_stepper_pins: pinmux_pruicss_stepper_pins{
> pinctrl-single,pins = <
> 0x038 0x07 // P8_16 (3)  = DIR_H= GPIO1_14
> 0x03C 0x07 // P8_15 (4)  = DIR_E= GPIO1_15
> 0x028 0x07 // P8_14 (5)  = DIR_Z= GPIO0_26
> 0x02C 0x07 // P8_17 (6)  = STEP_X   = GPIO0_27
> 0x034 0x07 // P8_11 (22) = step_H   = GPIO1_13
> 0x030 0x07 // P8_12 (23) = Step_y   = GPIO1_12
> 0x024 0x07 // P8_13 (24) = Step_z   = GPIO0_23
> 0x020 0x07 // P8_19 (25) = Dir_y= GPIO0_22
> 0x07C 0x07 // P8_26  = Dir_x= GPIO1_29
> 0x078 0x07 // P9_12  = step E   = GPIO1_28
> >;
> };
>
> cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins | grep 7C comes 
> up empty.
> Everything described above also happens when I use the 4.9.81-bone-rt-r9 
> kernel on jessie (which still uses the slots).
> Interestingly, the same BBB/Replicape hardware runs flawlessly with 
> redeem/kamikaze which
> uses the same overlay, on a non-rt 4.1.38-bone24 kernel.
> What am I missing?
> Karl
>

-- 
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: Machinekit and closed loop

['schoone...@btinternet.com' via Machinekit]

Ha, very good!


On 17/02/18 11:41, fritz wrote:
I first read that it had a name on the webcomic XKCD, but it appears 
that this phenomena now has its own website:


http://xyproblem.info/

On 02/16/2018 11:21 AM, 'schoone...@btinternet.com' via Machinekit wrote:

Now we know what you are doing, it is easier to assist.

You really need to ask a question about your problem, not how to 
effect the solution you have thought of.




--
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: Machinekit and closed loop

[fritz]

I first read that it had a name on the webcomic XKCD, but it appears 
that this phenomena now has its own website:


http://xyproblem.info/

On 02/16/2018 11:21 AM, 'schoone...@btinternet.com' via Machinekit wrote:

Now we know what you are doing, it is easier to assist.

You really need to ask a question about your problem, not how to 
effect the solution you have thought of.


--
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] Replicape overlay not setting pru GPIO outputs

[Karl Jacobs]

Hello,

I am trying to setup my Kossel mini printer with  Replicape version 0B3A on 
a BBB with machinekit.
I used https://github.com/sam0737/machinekit-replicape in its 
ARM.Replicape.B3 version adapted to the newest
stretch machinekit package 
bone-debian-9.3-machinekit-armhf-2018-02-11-4gb.img.xz (the changes being 
to adapt to the 
"slotless" cape loading and to correct the .icomp components). 

The BB-BONE-REPLICAP-0B3A.dtbo is loaded via u-boot load as you can see 
from the attached file
giving the details on version.sh, dmesg and uEnv , where you can see that I 
disabled HDMI, EMMC and 
cape-universal.

Machinekit starts up fine, I can see the extruder and hotbed temperatures, 
pwm working, endstops working etc.
so it seems that the cape is loaded allright. I can also read the cape 
eeprom.
The only thing not working is that the output pins of the pru (like x-dir 
on P8.26) do not show any signal
but stay low. I have to manually set

echo "61" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio61/direction

to have the pru toggle the x-direction pin on P8.26 (with kernel gpio 
number 61) as an example.
pru itself (with uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo) 
obviously works.
In the code of sam0737 the hpg.stepgen.00.dirpin is set to 826, and that is 
confirmed with halshow.

I was expecting that the overlay would set the outputs for the pru, as in 
BB-BONE-REPLICAP-0B3A.dts

pruicss_stepper_pins: pinmux_pruicss_stepper_pins{
pinctrl-single,pins = <
0x038 0x07 // P8_16 (3)  = DIR_H= GPIO1_14
0x03C 0x07 // P8_15 (4)  = DIR_E= GPIO1_15
0x028 0x07 // P8_14 (5)  = DIR_Z= GPIO0_26
0x02C 0x07 // P8_17 (6)  = STEP_X   = GPIO0_27
0x034 0x07 // P8_11 (22) = step_H   = GPIO1_13
0x030 0x07 // P8_12 (23) = Step_y   = GPIO1_12
0x024 0x07 // P8_13 (24) = Step_z   = GPIO0_23
0x020 0x07 // P8_19 (25) = Dir_y= GPIO0_22
0x07C 0x07 // P8_26  = Dir_x= GPIO1_29
0x078 0x07 // P9_12  = step E   = GPIO1_28
>;
};

cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins | grep 7C comes 
up empty.
Everything described above also happens when I use the 4.9.81-bone-rt-r9 
kernel on jessie (which still uses the slots).
Interestingly, the same BBB/Replicape hardware runs flawlessly with 
redeem/kamikaze which
uses the same overlay, on a non-rt 4.1.38-bone24 kernel.
What am I missing?
Karl

-- 
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.
sudo ./version.sh
 
git:/opt/scripts/:[aa257709957bdaab058ef4428469b87bb2c2f19e]
eeprom:[A335BNLT00C03214BBBK0719]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[Machinekit Debian Image 2018-02-11]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2018.01-2-g9aa111a004]:[location: dd MBR]
kernel:[4.14.18-ti-rt-r33]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_emmc=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
pkg:[bb-cape-overlays]:[4.4.20180126.0-0rcnee0~stretch+20180126]
pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee2~stretch+20180104]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait 
uboot_detected_capes=BB-BONE-REPLICAP, coherent_pool=1M net.ifnames=0 quiet]
dmesg | grep pinctrl-single
[1.409356] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
dmesg | grep gpio-of-helper
[1.411278] gpio-of-helper ocp:cape-universal: ready
END

dmesg | grep -i cape
[0.00] Kernel command line: console=ttyO0,115200n8 
bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 
rootwait uboot_detected_capes=BB-BONE-REPLICAP, coherent_pool=1M net.ifnames=0 
quiet
[1.411278] gpio-of-helper ocp:cape-universal: ready

uEnv.txt

name_r=4.14.18-ti-rt-r33
#uuid=
#dtb=


###U-Boot Overlays###
###Documentation: 
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overla$
###Master Enable
enable_uboot_overlays=1
###
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/.dtbo
#uboot_overlay_addr1=/lib/firmware/.dtbo