On 26 Dec 2013, at 07:16, Michael Haberler mai...@mah.priv.at wrote:
however: why not have more than one motion component?
Motmod is already an INI entry. How difficult would it be to separately compile
a separate motmod2_experimental ?
On Tue, Dec 24, 2013 at 03:08:18AM -0600, John Morris wrote:
This'll affect pre-UBC trees when 3.8.13 RTAI kernels are available.
https://mail.rtai.org/pipermail/rtai/2013-December/026199.html
Someone who has a good handle on this should contribute to rtai a patch
so that `rtai-config
I've started moving my linear delta printer using LinuxCNC, and despite
using the joints-axis code, I'm still having non-trivial issues with
non-trivial kinematics.
Basically, the problem boils down to the boxy perspective of LinuxCNC,
where most limits (position, velocity, and acceleration) are
On Thu, Dec 26, 2013 at 10:17 AM,
emc-developers-requ...@lists.sourceforge.net wrote:
Breaking Free of the Box (Charles Steinkuehler)
Hey Charles,
This is what caused me alot of grief when using my delta printer with LCNC.
I kept getting following errors all over the place no matter how much
On Thu, Dec 26, 2013 at 09:17:18AM -0600, Charles Steinkuehler wrote:
simple move the joint until the switch closes. IMHO there needs to be
a way to write programmable homing routines that can perform coordinated
motion in joint and/or world space, But one thing at a time...
I don't see how
I like this idea, as it would make it much easier to make changes without
messing up other people's work. It would take a bit of reorganization,
since the motion module code is spread out over a few folders. I'm thinking
it would help to rearrange these files into motion_common,
The way I understand it - the kins are 'on top' of motion at the
moment. (I don't know if ja4 solves this - but I think it is the
start).. So motion calculates the xyzabcuvw limits - then they get run
through the kins module which could depending on the machine layout -
multiply or divide
On Dec 26 2013 10:03 AM, Charles Steinkuehler wrote:
On 12/26/2013 10:17 AM, Chris Radek wrote:
On Thu, Dec 26, 2013 at 09:17:18AM -0600, Charles Steinkuehler
wrote:
simple move the joint until the switch closes. IMHO there needs
to be
a way to write programmable homing routines that can
Hi All,
I noticed an odd quirk with the Naive CAM detector when debugging an issue
with circular arc blending. In particular, I was trying to find the source
of this error:
(Starting from X56.09083 Z0.49686 )
N1 G1 X20.16452
N2 X19.2665 Z0.86884
N3 X18.89452 Z1.76686
Did you get a chance to see if the ini settings are working for you? I
have not tested it since tuesday. could it be something I am doing wrong?
thanks
sam
On 12/26/2013 10:54 AM, Robert Ellenberg wrote:
I like this idea, as it would make it much easier to make changes without
messing up
2013/12/26 Charles Steinkuehler char...@steinkuehler.net
I'm more concerned about being able to set coordinated acceleration and
velocity limits, so I can avoid having to perform X and Y moves at 57 %
of my available max velocity and acceleration just so the occasional XYZ
move doesn't exceed
On Thu, Dec 26, 2013 at 6:03 PM, Charles Steinkuehler
char...@steinkuehler.net wrote:
On 12/26/2013 10:17 AM, Chris Radek wrote:
On Thu, Dec 26, 2013 at 09:17:18AM -0600, Charles Steinkuehler wrote:
simple move the joint until the switch closes. IMHO there needs to be
a way to write
On Thu, Dec 26, 2013 at 11:54:34AM -0500, Robert Ellenberg wrote:
I like this idea, as it would make it much easier to make changes without
messing up other people's work. It would take a bit of reorganization,
since the motion module code is spread out over a few folders. I'm thinking
it
On Thu, Dec 26, 2013 at 10:00:28PM +0200, Andrew wrote:
The solution I can think of: calculating each joint velocity and
acceleration before each move (at several points at least for a long moves)
and then decreasing XYZ velocities to fit joint velocities to their limits.
This is exactly the
On 12/26/2013 2:00 PM, Andrew wrote:
Details:
Given a maximum X, Y, and Z velocity of 1.0, the maximum speed of an XY
move is 1.414 (or SQRT(2)), and the maximum speed of an XYZ move is 1.73
(or SQRT(3)), so I have to set my limits to 1/1.73 (0.577) of the actual
limits or the machine will
2013/12/26 Chris Radek ch...@timeguy.com
On Thu, Dec 26, 2013 at 10:00:28PM +0200, Andrew wrote:
The solution I can think of: calculating each joint velocity and
acceleration before each move (at several points at least for a long
moves)
and then decreasing XYZ velocities to fit joint
2013/12/26 Charles Steinkuehler char...@steinkuehler.net
Yes, the problem can get arbitrarily hard, depending on exactly what you
want to check and if you're doing things like mapping the move into
joint space in order to run the check. That's a big reason I think the
limit check(s) should
2013/12/26 Andrew pkm...@gmail.com
Yes, that is very reasonable. Just calculate the scale and use usual
planning.
The task can also be reversed: increase world velocity to the maximum
allowed by joint constraints. This can be useful for G0 moves.
Umm, sorry for offtopic, am I the only one
On Dec 26 2013 2:47 PM, Viesturs Lācis wrote:
2013/12/26 Andrew pkm...@gmail.com
Yes, that is very reasonable. Just calculate the scale and use
usual
planning.
The task can also be reversed: increase world velocity to the
maximum
allowed by joint constraints. This can be useful for G0
The limits should definitely be pluggable to account at least for angular
limits of ball joints etc.
BTW some standard cone workspace for AB axes would be OK for many parallel
robots.
But usual kinematics module seems enough for velocities and accelerations
check if the planner could
It seems to be working on my end, in that I can enable and disable various
setting from the INI file, and see the correct behavior in simulation.
Can you try running my test config to see if it works on your build?
tests/trajectory-planner/circular-arcs/circular_arcs.ini
If that works then I'd
will do!
thanks
sam
On 12/26/2013 04:07 PM, Robert Ellenberg wrote:
It seems to be working on my end, in that I can enable and disable various
setting from the INI file, and see the correct behavior in simulation.
Can you try running my test config to see if it works on your build?
2013/12/26 Robert Ellenberg rwe...@gmail.com
The limits should definitely be pluggable to account at least for angular
limits of ball joints etc.
BTW some standard cone workspace for AB axes would be OK for many
parallel
robots.
But usual kinematics module seems enough for
2013/12/26 EBo e...@sandien.com
On Dec 26 2013 2:47 PM, Viesturs Lācis wrote:
2013/12/26 Andrew pkm...@gmail.com
Yes, that is very reasonable. Just calculate the scale and use
usual
planning.
The task can also be reversed: increase world velocity to the
maximum
allowed by joint
2013/12/27 Andrew pkm...@gmail.com
2013/12/26 Robert Ellenberg rwe...@gmail.com
For many parallel robots some combinations of cones and cylinders can
describe their actual workspace pretty well.
For a serial robot arm it's can be more complicated but those cones and
cylinders (along with
On 12/26/2013 3:52 PM, EBo wrote:
On Dec 26 2013 2:47 PM, Viesturs Lācis wrote:
2013/12/26 Andrew pkm...@gmail.com
Yes, that is very reasonable. Just calculate the scale and use
usual
planning.
The task can also be reversed: increase world velocity to the
maximum
allowed by joint
2013/12/26 EBo e...@sandien.com
I was going to ask the same thing... If the issue is with the rapid
traverse that is set limited with the max velocity. Are you sure that
the max velocity is set correctly?
OK for a trivial kins this can be a solution. Max velocity can be limited
to joint
2013/12/27 Charles Steinkuehler char...@steinkuehler.net
So is there a maximum feedrate setting for g0 moves?
IMHO that is what max velocity in [TRAJ] section meant for.
Viesturs
--
Rapidly troubleshoot problems
re: work envelopes
heres a simplified overview of several work envelopes
http://thnet.co.uk/thnet/robots/25.htm
regards
TomP tjtr33
--
Rapidly troubleshoot problems before they affect your business. Most IT
Ok - I must have had some odd characters on those lines - I deleted the
last few characters and re-typed them and it seems to be working as
expected.
One odd issue. If I set the ARC_BLEND_ENABLE to 0 the spiral runs as
expected.. (around 100ipm) but the arcspiral still seems to use the
One odd issue. If I set the ARC_BLEND_ENABLE to 0 the spiral runs as
expected.. (around 100ipm) but the arcspiral still seems to use the
read ahead as it runs at top speed (420ipm) and I can make it run as the
original tp by setting the ARC_BLEND_OPTIMIZATION_DEPTH to 1 (runs about
31 matches
Mail list logo
