Re: [Emc-users] Avoiding probe crash
I agree to have an Abort instead of an E-stop, only in this way we have a defined deceleration rate. Each touch probe or tool setter has several millimetres of safe travel, given the deceleration during the stop, we can calculate the maximum safe feed with max_safe_feed = sqrt(2 * safe_travel * deceleration) (Unit conversion may need to be applied) If motion.motion-type == 5 can be a HAL signal then my problem is solved. I could program the behaviour that suits my need. 2017-12-07 23:26 GMT+08:00 王若溪 <thuwr...@gmail.com>: > Good call. I like this. > > (It's a joke isn't it?) > > 2017-12-05 0:42 GMT+08:00 Nicklas Karlsson <nicklas.karlsso...@gmail.com>: > >> On Tue, 5 Dec 2017 00:37:03 +0800 >> 王若溪 <thuwr...@gmail.com> wrote: >> >> > I'm writing some auto measurement G-code program using my CNC mill and a >> > touch probe. >> > Seems that LinuxCNC doesn't want to stop when the probe is tripped >> during a >> > non-probe move if the machine is running a G-code program. >> > Currently, I'm replacing every non-probe move with G38.3. After it's >> > execution, signal an error if the current position is not commanded >> > position (which indicates that the probe was tripped during this move), >> > continue if current position matches commanded. >> > >> > Any thoughts? >> >> Yes, connect touch to stop signal. >> >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______ >> Emc-users mailing list >> Emc-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-users >> > > > > -- > 王若溪 > 清华大学 > 航天航空学院 > 航硕161班 > -- 王若溪 清华大学 航天航空学院 航硕161班 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Avoiding probe crash
Good call. I like this. (It's a joke isn't it?) 2017-12-05 0:42 GMT+08:00 Nicklas Karlsson <nicklas.karlsso...@gmail.com>: > On Tue, 5 Dec 2017 00:37:03 +0800 > 王若溪 <thuwr...@gmail.com> wrote: > > > I'm writing some auto measurement G-code program using my CNC mill and a > > touch probe. > > Seems that LinuxCNC doesn't want to stop when the probe is tripped > during a > > non-probe move if the machine is running a G-code program. > > Currently, I'm replacing every non-probe move with G38.3. After it's > > execution, signal an error if the current position is not commanded > > position (which indicates that the probe was tripped during this move), > > continue if current position matches commanded. > > > > Any thoughts? > > Yes, connect touch to stop signal. > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- 王若溪 清华大学 航天航空学院 航硕161班 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Avoiding probe crash
I'm writing some auto measurement G-code program using my CNC mill and a touch probe. Seems that LinuxCNC doesn't want to stop when the probe is tripped during a non-probe move if the machine is running a G-code program. Currently, I'm replacing every non-probe move with G38.3. After it's execution, signal an error if the current position is not commanded position (which indicates that the probe was tripped during this move), continue if current position matches commanded. Any thoughts? -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Acceleration Confusion
I have an XHC-HB04 18-button wireless MPG on my mill. It's amazing that it works on LinuxCNC. But I found something confusing about acceleration: 1. The acceleration in [XHC_HB04_CONFIG]mpg_accels seems to have an effect on both jogging and program running. Isn't it supposed to affect MPG jogging only? 2. Probably not related to XHC_HB04. Jog acceleration when using Shift+Arrow keys seems to be higher than G0 acceleration. I thought they should be identical. I'm using Axis GUI, [AXIS_#]MAX_ACCELERATION = 250, [AXIS_#]STEPGEN_MAXACCEL = 937.5 Maybe there is some internal mechanism that I don't know, hope someone could cast some light on it. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] 4-axis tool path back plot in Axis
Thanks a lot, your insight into code really provides some useful info, such as the pivot point of rotation in the back plot is hardcoded to (0,0,0). I'm gonna try adding fake axes V and W in my machine config and set GEOMETRY = VWAXYZ, apply an offset to V and W axes and see what happens. As for the tilt of the tool you mentioned on your website. My explanation about the tilted tool is that it seems it's a standard that everything graphical about multi-axis tool paths, such as in CAM and CNC controller, is relative to the workpiece. To be easy to understand, if one is tiny enough to be able to sit on the workpiece, he will see the tool tilts when A axis rotates. And seems it's a standard that you are always sitting on the workpiece when viewing a tool path. 2017-08-25 21:36 GMT+08:00 Kirk Wallace <kwall...@wallacecompany.com>: > In case it might be handy: > >> http://www.wallacecompany.com/machine_shop/LinuxCNC/fourth_axis/ >> > > My next task was to try to clearly define what the plot should look like. > A working example to copy would be nice. > > > > On 08/25/2017 12:53 AM, 王若溪 wrote: > >> Hi forks, >> >> I'm using LinuxCNC with my 4 axes (A axis rotate along X axis) mill and I >> want to make back plot in Axis GUI reflect the path of tool reference >> point >> (tool tip) relative to the workpiece correctly. >> >> i.e. The tool reference point (tool tip) should rotate about the A axis >> hinge point, which has a fixed G53 Y, Z coordinate when I'm jogging A >> axis. >> >> If I set "GEOMETRY = XYZA", the tool tip always rotate about the current >> point, which is not correct. >> If I set "GEOMETRY = AXYZ", the tool tip rotate about the origin of G53 >> coordinate system. Then I had to offset the min/max/home of YZ axis to >> make >> G53 origin coincident to A axis hinge point, which is kinda dangerous >> because many CAM software defaults to do a "G0 G53 X0 Y0 Z0" in the >> beginning of an operation, which would crash my spindle into the table. >> >> So what's the normal practice when making an NC system for 4,5 axis >> machine? Do I have to add non-trivial kinematics so that the back plot is >> correct when "GEOMETRY = XYZA"? >> Or can I redefine the tool length compensation value to be (Z coordinate >> of >> A axis hinge - Z coordinate of tool tip) when machine is at Z home/max, >> which is normally a negative value, so that I still set Z home/max = G53 >> Z0 >> but get correct back plot when tool length compensation is applied? What >> is >> tool length compensation typically defined, BTW? >> >> Wow, there are a lot of questions. I'm new to mill with rotary axes, any >> hint would be appreciated, thanks. >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> ___ >> Emc-users mailing list >> Emc-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-users >> >> >> > > -- > Kirk Wallace > http://www.wallacecompany.com/machine_shop/ > http://www.wallacecompany.com/E45/ > > -------- > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- 王若溪 清华大学 航天航空学院 航硕161班 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] 4-axis tool path back plot in Axis
Hi forks, I'm using LinuxCNC with my 4 axes (A axis rotate along X axis) mill and I want to make back plot in Axis GUI reflect the path of tool reference point (tool tip) relative to the workpiece correctly. i.e. The tool reference point (tool tip) should rotate about the A axis hinge point, which has a fixed G53 Y, Z coordinate when I'm jogging A axis. If I set "GEOMETRY = XYZA", the tool tip always rotate about the current point, which is not correct. If I set "GEOMETRY = AXYZ", the tool tip rotate about the origin of G53 coordinate system. Then I had to offset the min/max/home of YZ axis to make G53 origin coincident to A axis hinge point, which is kinda dangerous because many CAM software defaults to do a "G0 G53 X0 Y0 Z0" in the beginning of an operation, which would crash my spindle into the table. So what's the normal practice when making an NC system for 4,5 axis machine? Do I have to add non-trivial kinematics so that the back plot is correct when "GEOMETRY = XYZA"? Or can I redefine the tool length compensation value to be (Z coordinate of A axis hinge - Z coordinate of tool tip) when machine is at Z home/max, which is normally a negative value, so that I still set Z home/max = G53 Z0 but get correct back plot when tool length compensation is applied? What is tool length compensation typically defined, BTW? Wow, there are a lot of questions. I'm new to mill with rotary axes, any hint would be appreciated, thanks. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] armhf packages for Debian Stretch?
May be a Raspberry Pi could be used as a build machine for Stretch, armhf, as Raspbian based on Debian Stretch is just released. I've successfully built LinuxCNC on an RPi 3B running on Raspbian Stretch and run it on a BBB running on Debian Stretch. Interestingly, RPi has 64bit ARM CPU while Raspbian is armhf architecture. 2017-08-16 11:09 GMT+08:00 Sebastian Kuzminsky <s...@highlab.com>: > On 08/15/2017 09:05 PM, 王若溪 wrote: > >> Yes, you can build LinuxCNC for Stretch on armhf. The only reason we >>> don't provide these packages is we don't have a dedicated Stretch armhf >>> build machine. >>> >> >> Here are instructions on building the debs yourself. This assumes a >>> native build, not a cross build, so running everything on the BeagleBone >>> Black: >>> >> >> Thanks a lot. >> >> Is BBB's 512MB memory enough to build LinuxCNC? And I'm curious that why >> cross build is not used in dedicated build machine. >> > > I've built LinuxCNC on a BBB, but I might have had swap enabled, I don't > remember. > > We don't cross-build because we want to run the test suite, and that > requires executing the compiled binaries, which doesn't work in a > cross-build environment. > > > Is building on arm64 architecture such as Jetson TX1 considered as cross >> build? I happen to have an idle Jetson TX1 with 4GB memory, don't know if >> useful. >> > > Building for arm64 on arm64 is not a cross build. Building for non-arm64 > on arm64 would be a cross build. > > I don't have any arm64 machines, so i've never tried building/testing > LinuxCNC on one. > > > -- > Sebastian Kuzminsky > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] armhf packages for Debian Stretch?
> Yes, you can build LinuxCNC for Stretch on armhf. The only reason we > don't provide these packages is we don't have a dedicated Stretch armhf > build machine. > Here are instructions on building the debs yourself. This assumes a >native build, not a cross build, so running everything on the BeagleBone > Black: Thanks a lot. Is BBB's 512MB memory enough to build LinuxCNC? And I'm curious that why cross build is not used in dedicated build machine. Is building on arm64 architecture such as Jetson TX1 considered as cross build? I happen to have an idle Jetson TX1 with 4GB memory, don't know if useful. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] armhf packages for Debian Stretch?
Hello everyone, I'm trying to run LinuxCNC on BeagleBone Black which has Debian Stretch installed, but it seems that LinuxCNC repo doesn't have armhf package for Stretch. Is there any chance that I can build one myself? As I can run LinuxCNC smoothly on my x86 laptop which has Debian Stretch with PREEMPT-RT kernel and I do see armhf packages for Debian Jessie. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
