The 5axis sample config is a really nice example of what kins can do.
But it is not without its quirks.
It tends to complain about any switch to world mode if you move it
between startup and switching to world mode. Halcmd show pin
*is-homed* indicates that the problem is the "missing" A, U and V
Non-trivial configs again.
Is the software (in any branch) meant to limit the trajectory speed to
stay within axis limits during jogs?
Someone on the forum is using a 5-axis setup adapted from the 5axis demo.
He gets a following error on the linear axes when jogging the rotaries
in World mode.
On 3 August 2013 18:44, Sebastian Kuzminsky wrote:
> * Try it out and let us know!
It appears to work. At least so far.
I have tried it on Master, 2.5 and joints_axes3.
I may try UB1 tonight.
--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto
---
I have had the same problem. I "fixed" this behaviour by using a little HAL
logic. I used a MUX to change the jog speed parameter depending on wether you
are jogging a linear o a rotary axis.Now the real fix to the issue. I've
studied the code, and the problem (in the case of jogging) is in comm
that was a good bit of sluthing, and your english is perfectly clear...
Why not just have jog respect each axis limit in tern, and not group
them by linear and rotational? I have worked on machines where even
with linear axes the Z was slower and finer than the X/Y. So any limit
would either
On 16/08/13 11:35, Eric Keller wrote:
> Is it possible to get a patched rtai kernel and build config to tune
> to hardware? Or did you just start from scratch
I used the 3.5.7 patch from magma on the consolidated 3.5.7 kernel
The kernel config started out with the one from here
http://code.goo
On 16 August 2013 12:35, Lisandro Massera wrote:
> I've studied the code, and the problem (in the case of jogging) is in
> command.c around line 1423. When it checks for max speed, it compares all the
> axes speed against a limitvel which is set in the configuration
> ("MAX_VELOCITY" in the TRA
That is easy for trivkin machines, or at least machines that there is a
straight correspondance between axis and joint. In non-trivkin machines what
you are proposing would involve working with the kinematics module, and that is
a completely different issue. It would be really nice to be able to
On 16 August 2013 12:50, EBo wrote:
> Why not just have jog respect each axis limit in tern, and not group
> them by linear and rotational?
Because it is complicated with a non-trivial machine.
I think that there are controllers that don't even try, and simply
require all jogs to be joint-mode.
On Aug 16 2013 6:20 AM, andy pugh wrote:
> On 16 August 2013 12:50, EBo wrote:
>> Why not just have jog respect each axis limit in tern, and not group
>> them by linear and rotational?
>
> Because it is complicated with a non-trivial machine.
>
> I think that there are controllers that don't even
Hi,
I've started a Python module to control heaters for extruders and build
platforms. Right now, it does two things:
1) Bypasses the PID controller during the initial heating period. When the
heater temperature is below the set temperature by some value
(configurable), a constant value (configur
On 8/16/2013 9:15 AM, Troy Jacobson wrote:
> Hi,
> I've started a Python module to control heaters for extruders and build
> platforms. Right now, it does two things:
> 1) Bypasses the PID controller during the initial heating period. When the
> heater temperature is below the set temperature by
On Fri, Aug 16, 2013 at 01:20:35PM +0100, andy pugh wrote:
>
> The specific case I am talking about is where a jog is altering the
> approach angle of the tool to the work (A and B axes) while not
> altering the tool-tip position in XYZ space. To do this requires
> movement of the X, Y and Z Joint
On 16 August 2013 15:15, Troy Jacobson wrote:
> I've started a Python module to control heaters for extruders and build
> platforms.
I am slightly puzzled about what this module does that the existing
PID controller can't do.
> Right now, it does two things:
> 1) Bypasses the PID controller du
On 16 August 2013 15:35, Chris Radek wrote:
> This means: just like you have
> to set AXIS LIMITS to be inside JOINT LIMITS, you must also set up
> your configuration so obeying AXIS CONSTRAINTS keeps you within your
> JOINT CONSTRAINTS. This can be tricky, but you must do it. I think
> your qu
I'm definitely planning on making it realtime. I was just more familiar
with Python, so that's where I started.
The parameters I have for my extruder are to be within 2 degrees of the
target for 10 seconds. I didn't see anything PID wise that would help with
the timing.
There were two reasons I
On 08/13/2013 11:45 AM, Charles Steinkuehler wrote:
> PERFECT!
>
> This time I got no flaws, and I have my first-ever correctly printed
> spiral-mode 1 wall thickness vase!
Wow, nice! Does it hold water?
John
-
On 8/16/2013 10:22 AM, John Morris wrote:
> On 08/13/2013 11:45 AM, Charles Steinkuehler wrote:
>> PERFECT!
>>
>> This time I got no flaws, and I have my first-ever correctly printed
>> spiral-mode 1 wall thickness vase!
>
> Wow, nice! Does it hold water?
Almost. There's one very small pinhole
On Fri, Aug 16, 2013 at 03:52:26PM +0100, andy pugh wrote:
> On 16 August 2013 15:35, Chris Radek wrote:
> > This means: just like you have
> > to set AXIS LIMITS to be inside JOINT LIMITS, you must also set up
> > your configuration so obeying AXIS CONSTRAINTS keeps you within your
> > JOINT CON
On Fri, Aug 16, 2013 at 09:22:09AM -0500, Charles Steinkuehler wrote:
>
> I _think_ this is "spindle hold" in "conventional" LinuxCNC usage,
motion.spindle-at-speed
> where you don't want to start moving until the spindle is up to
> cutting speed.
Don't want to start *cutting*. You do want to
Hi list,
Continuing to support Ubuntu 8.04 is foolhardy, and I propose we stop.
- Hardy desktop support ended May 2011; server support ended May 2013.
Support for Lucid desktops ended May 2013 (servers two years later). [1]
This is the upstream distro vendor's LTS policy, and the most
reasonable
2013/8/16 andy pugh
> Would it be possible for the code to determine the instantaneous
> relationship between current AXIS (trajectory?) velocity and the
> associated JOINT velocities? I think in theory this is just two calls
> to the kins module of a "now" and a "now + delta-t" point. The system
On Fri, Aug 16, 2013 at 11:31:54AM -0500, John Morris wrote:
> Hi list,
>
> Continuing to support Ubuntu 8.04 is foolhardy, and I propose we stop.
I'd support the idea of dropping hardy builds for 2.6 and master.
> - Hardy desktop support ended May 2011; server support ended May 2013.
> Support
On 8/16/2013 11:28 AM, Chris Radek wrote:
> On Fri, Aug 16, 2013 at 09:22:09AM -0500, Charles Steinkuehler wrote:
>>
>> I _think_ this is "spindle hold" in "conventional" LinuxCNC usage,
>
> motion.spindle-at-speed
>
>> where you don't want to start moving until the spindle is up to
>> cutting s
On Fri, Aug 16, 2013, at 02:28 PM, Charles Steinkuehler wrote:
> It sounds like this would work pretty well as a start, but unless I'm
> missing something it would still allow rapid moves on the extruder axis
> when the extruder wasn't at temperature. Ideally all extruder movement
> should be
On 8/16/2013 1:36 PM, John Kasunich wrote:
>
>
> On Fri, Aug 16, 2013, at 02:28 PM, Charles Steinkuehler wrote:
>
>
>> It sounds like this would work pretty well as a start, but unless I'm
>> missing something it would still allow rapid moves on the extruder axis
>> when the extruder wasn't at
I will look at the spindle-at-speed for M109,M190. It could be a better
solution than busy waiting in a bash script.
A cold extrude should probably fail a print. If that is done by triggering
a following error, would there be a way to make it obvious that it was the
extruder temperature that is
co-opting things like following error to a purpose that does not make
any intuitive sense for makes me a little queasy. The spindle-at-speed
makes intuitive sense, because in the abstract it is simply the tool is
ready flag. It does not matter as much that the tool is spinning up, or
the prin
On Aug 16 2013 12:36 PM, John Kasunich wrote:
> On Fri, Aug 16, 2013, at 02:28 PM, Charles Steinkuehler wrote:
>
>
>> It sounds like this would work pretty well as a start, but unless
>> I'm
>> missing something it would still allow rapid moves on the extruder
>> axis
>> when the extruder wasn't
On 8/16/2013 11:28 AM, Charles Steinkuehler wrote:
> It sounds like this would work pretty well as a start, but unless I'm
> missing something it would still allow rapid moves on the extruder
> axis when the extruder wasn't at temperature. Ideally all extruder
> movement should be gated by the
On 16 August 2013 22:24, David Bagby wrote:
> I find myself thinking that this conversation is twisted by the
> assumption that an extruder as an axis - I don't think it is.
You are not wrong, but…
The extrusion motor movement needs to be synched to motion. While XY
are not up to speed, the extru
On 8/16/2013 4:24 PM, David Bagby wrote:
> The topic at hand is: How can one use LCNC to control a stepper motor;
> when the motor is NOT an axis motor?
> Sounds like a Hal level question to me - an extruder needs a pulse
> generator that you can control (that gets the motor movement), some IO
>
I agree that the extruder is not an axis. And if the was inifinite time, and
and infinite number of monkeys to write core, and extruder object would
be cool.
In the meantime, if we are going to mash extruders into some existing
"thing" that LinuxCNC supports, is it more reasonable to think of the
On 16 August 2013 23:25, John Kasunich wrote:
> Can that simply be multiplied by a scale factor and
> used to drive the extruder?
I don't think it is as wrong as it looks.
G1 Xq10 Y10 A100 means "move 10mm each way and deposit 100mg of goop
in a motion-synchronised way as you go"
--
atp
If you
Does 3D printer g-code use relative coordinates?
On Fri, Aug 16, 2013, at 06:36 PM, andy pugh wrote:
> On 16 August 2013 23:25, John Kasunich wrote:
> > Can that simply be multiplied by a scale factor and
> > used to drive the extruder?
>
> I don't think it is as wrong as it looks.
>
> G1 Xq10
On 8/16/2013 6:12 PM, John Kasunich wrote:
> Does 3D printer g-code use relative coordinates?
XYZ are absolute.
Depending on the slicer program, E/A values for the extruder can be
setup as absolute with G92 reset (on layer change), absolute w/o reset,
or relative.
The most common option is proba
On Aug 16 2013 3:51 PM, andy pugh wrote:
> On 16 August 2013 22:24, David Bagby
> wrote:
>> I find myself thinking that this conversation is twisted by the
>> assumption that an extruder as an axis - I don't think it is.
>
> You are not wrong, but…
> The extrusion motor movement needs to be synch
On Aug 16 2013 3:24 PM, David Bagby wrote:
> On 8/16/2013 11:28 AM, Charles Steinkuehler wrote:
>> It sounds like this would work pretty well as a start, but unless
>> I'm
>> missing something it would still allow rapid moves on the extruder
>> axis when the extruder wasn't at temperature. Ideally
On 8/16/2013 2:51 PM, andy pugh wrote:
> On 16 August 2013 22:24, David Bagby wrote:
>> I find myself thinking that this conversation is twisted by the
>> assumption that an extruder as an axis - I don't think it is.
> You are not wrong, but…
> The extrusion motor movement needs to be synched to
On Aug 16 2013 7:56 PM, David Bagby wrote:
> On 8/16/2013 2:51 PM, andy pugh wrote:
>> On 16 August 2013 22:24, David Bagby
>> wrote:
>>> I find myself thinking that this conversation is twisted by the
>>> assumption that an extruder as an axis - I don't think it is.
>> You are not wrong, but…
>>
Hello everyone! I have LinuxCNC master branch working with RTAI on a 64-bit
3.4.58 kernel. Latency-test runs fine and the demo sim works nicely as well.
The makefile in LinuxCNC only compiles with this following patch that I mocked
up when using 64-bit RTAI:
http://pastebin.com/TEZwMLYz
Any c
41 matches
Mail list logo
