On 04/18/2012 09:14 PM, gene heskett wrote:
[huge snip]
To make an overly long story a bit shorter, I bought another 2Gb key that
was actually formatted fat32, and copied everything I needed to it, then
took it over to the neighbors. It installed twice, the second time took.
Now I have to
Hello, gentlemen!
I have 2 strange things about LinuxCNC, I hope that someone can help
me out with an advice.
First is that the machine has only servo thread and servo period set
at 50 ns (running at 2 kHz). About a minute after starting
LinuxCNC, I get realtime error, check dmesg for
On 19 March 2012 02:17, Steve Blackmore st...@pilotltd.net wrote:
Effectively LinuxCNC only looks ahead one line.
This rather depends on what you mean by Look Ahead.
One decision that I think might adversely affect LinuxCNC is that as
far as I know LinuxCNC will always move in such a way as to
On 19 April 2012 13:20, Viesturs Lācis viesturs.la...@gmail.com wrote:
First is that the machine has only servo thread and servo period set
at 50 ns (running at 2 kHz). About a minute after starting
LinuxCNC, I get realtime error, check dmesg for details.
I get this with a particular USB
19 квітня 2012 р. 15:20 Viesturs Lācis viesturs.la...@gmail.com написав:
The motors still do not want to move. Not even steppers. Does anyone
have any idea, what might be wrong? Everything was working before that
initial stop responding to input pins situation and I have not
changed anything
Gene,
Sorry to hear of the issues you had! I have been away from email today, so
only just catching up - but glad to hear you got it sorted out in the end.
Regards
Adrian
On 19 April 2012 11:14, gene heskett ghesk...@wdtv.com wrote:
On Wednesday, April 18, 2012 09:05:32 PM gene heskett did
I don't think that would work well. Think about the situation where you
have several (mostly straight) short line segments, the last being the
shortest, and then a 90deg turn. I think many would find it unacceptable
to overshoot the last segment 10thou if you were doing something like
inside
On 19 April 2012 14:04, Stephen Dubovsky smdubov...@gmail.com wrote:
But I see how it might be a limiting factor for a modern Hass class speed
machine w/ massive spindle hp and feed rates possible when profiling.
It shouldn't be a limit on any machine with decent G-code. I am
describing a
On Thu, 19 Apr 2012, Viesturs L?cis wrote:
Date: Thu, 19 Apr 2012 15:20:09 +0300
From: [UTF-8] Viesturs L?cis viesturs.la...@gmail.com
Reply-To: Enhanced Machine Controller (EMC)
emc-users@lists.sourceforge.net
To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net
On Thu, 19 Apr 2012, Andrew wrote:
Date: Thu, 19 Apr 2012 15:49:38 +0300
From: Andrew parallel.kinemat...@gmail.com
Reply-To: Enhanced Machine Controller (EMC)
emc-users@lists.sourceforge.net
To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net
Subject: Re: [Emc-users] 2
2012/4/19 andy pugh bodge...@gmail.com:
On 19 April 2012 14:04, Stephen Dubovsky smdubov...@gmail.com wrote:
But I see how it might be a limiting factor for a modern Hass class speed
machine w/ massive spindle hp and feed rates possible when profiling.
It shouldn't be a limit on any machine
On Thursday, April 19, 2012 10:34:37 AM Mark Wendt did opine:
On 04/18/2012 09:14 PM, gene heskett wrote:
[huge snip]
To make an overly long story a bit shorter, I bought another 2Gb key
that was actually formatted fat32, and copied everything I needed to
it, then took it over to the
On 19 April 2012 15:53, Viesturs Lācis viesturs.la...@gmail.com wrote:
Yes, it actually was watchdog. I saw in dmesg that it had bit after I
increased the servo period from 500 us to 750 us, but completely
forgot about the timeout, which also was set at 500 us.
That's probably over-cautious.
On 19 April 2012 16:13, Stephen Dubovsky smdubov...@gmail.com wrote:
For 3d profiling CAM usually writes the g-code. I don't know anyone who
would hand calculate tens of thousands of little segments:) As such, I
don't know that its necessarily poor quality. It has to generate as many
On Thursday, April 19, 2012 11:19:00 AM Adrian Carter did opine:
Gene,
Sorry to hear of the issues you had! I have been away from email today,
so only just catching up - but glad to hear you got it sorted out in
the end.
Regards
Adrian
Ahh, the ghost re-appears! :)
Yes, I think I
On 04/19/2012 10:15 AM, gene heskett wrote:
On Thursday, April 19, 2012 10:34:37 AM Mark Wendt did opine:
Humm, inserted into my reader, its presence is acknowledged, but its
not accessible. The usb system issues a boatload of resets but never
gets any farther than listing it as sdg, sdh,
Well, generating an arc as tiny G1 moves seems a poorer solution than
G2 or G3 moves...
There are a number of reasons for doing this:
Many CAM packages don't use arcs internally. Breaking arcs into line
segments can greatly simplify the maths.
When doing 3D work you can quite often get arcs
2012/4/19 Stephen Dubovsky smdubov...@gmail.com:
Around tight curves, that requires lots of short sections w/
high changes in velocity. But you have to go slow within the limits of the
machine around those anyway.
Just like Andy said - if there is curve in the part, then that is why
there
On Thursday, April 19, 2012 12:08:58 PM Mark Cason did opine:
On 04/19/2012 10:15 AM, gene heskett wrote:
On Thursday, April 19, 2012 10:34:37 AM Mark Wendt did opine:
Humm, inserted into my reader, its presence is acknowledged, but its
not accessible. The usb system issues a boatload
I think this is a fairly common problem. There are a number Gcode
generators out there that take curvy cutting patterns and turn
them into huge files full of short G1 moves. The Gcode generator people
expect the machine controller to gobble up the crappy G code and create
smooth motions at
-Original Message-
From: Viesturs Lacis [mailto:viesturs.la...@gmail.com]
Sent: Thursday, April 19, 2012 11:08 AM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Trajectory planning and other topics
from a EMC(LinuxCNC) newbie (TheNewbie)
snip
Just like Andy
The big problem is that very often the curves in the drawing are not
true arcs. This is especially common in artistic and sign work. The
quality of the CAM output is directly dependent on the quality of the
input drawing. Drawings that contains just arcs and lines will generate
nice clean
On 19 April 2012 18:44, Steve Stallings steve...@newsguy.com wrote:
There are many cases where short segments are currently the
only workable solution. Among these:
...
2) The path is curved, but not a true arc. It could be
an oval, an ellipse, or even a spline or nurbs path.
I _think_
2012/4/19 Les Newell les.new...@fastmail.co.uk:
The big problem is that very often the curves in the drawing are not
true arcs. This is especially common in artistic and sign work. The
quality of the CAM output is directly dependent on the quality of the
input drawing. Drawings that contains
Viesturs Lācis wrote:
I think that this issue is fighting the consequence instead of fixing
the real cause.
People want to change the look ahead behavior, but I am completely
sure that fixing the cause - getting normal g-code is much easier. At
least for those things that my machines are
On 04/19/2012 11:25 AM, gene heskett wrote:
On Thursday, April 19, 2012 12:08:58 PM Mark Cason did opine:
On 04/19/2012 10:15 AM, gene heskett wrote:
On Thursday, April 19, 2012 10:34:37 AM Mark Wendt did opine:
Humm, inserted into my reader, its presence is acknowledged, but its
not
I agree that there are always cases where curve fitting simply doesn't
work. But I have seen some large curvy lines in a single plane that
could have been curve fitted, that spanned over several feet of distance
that were described as G1 segments that were no more than .005 inches long.
That
What about a new plane selection block which allowed you to define an arbitrary
plane using 3 points?
On Apr 19, 2012, at 2:32 PM, Chris Radek wrote:
On Thu, Apr 19, 2012 at 09:18:52PM +0300, Viesturs L??cis wrote:
How hard would it be to add that? It would require 3 coordinates for
each
2012/4/19 Chris Radek ch...@timeguy.com:
On Thu, Apr 19, 2012 at 09:18:52PM +0300, Viesturs L??cis wrote:
How hard would it be to add that? It would require 3 coordinates for
each of start, end and center point.
The guts of linuxcnc already support this kind of motion and have for
some
On 4/19/2012 1:53 PM, Jon Elson wrote:
Viesturs Lācis wrote:
2012/4/19 Stephen Dubovskysmdubov...@gmail.com:
Around tight curves, that requires lots of short sections w/
high changes in velocity. But you have to go slow within the limits of the
machine around those anyway.
Just like
:) not so fast - never is a very long time! :)
On Apr 19, 2012 2:00 PM, Chris Radek ch...@timeguy.com wrote:
On Thu, Apr 19, 2012 at 09:45:42PM +0300, Viesturs L??cis wrote:
Uhhh, You are right, halfcircles. All three points are on a straight
line, around which the arc can freely rotate. I
SheetCam does not support NURBS curves internally. When it imports a
drawing, all non-circular curves are broken down into lots of very small
line segments. It then does arc matching on those line segments and any
other line segments in the drawing before finally merging any
ludicrously short
On 19 April 2012 19:57, Chris Radek ch...@timeguy.com wrote:
That is just the worst problem. Your system doesn't uniquely identify
any arc. For every start, center, end points there are a pair of arcs
that share the points. This is why we have G2/G3. If you don't have
a normal vector you
On 4/19/2012 9:02 PM, Kenneth Lerman wrote:
Is anyone here interested in writing a filter that takes as input a
tolerance (error band) and a sequence of motions (arcs and line
segments) and generates a new sequence of motions that duplicates the
original within the error band? It sounds like
2012/4/19 Les Newell les.new...@fastmail.co.uk:
SheetCam does not support NURBS curves internally. When it imports a
drawing, all non-circular curves are broken down into lots of very small
line segments. It then does arc matching on those line segments and any
other line segments in the
2012/4/19 andy pugh bodge...@gmail.com:
On 19 April 2012 19:57, Chris Radek ch...@timeguy.com wrote:
That is just the worst problem. Your system doesn't uniquely identify
any arc. For every start, center, end points there are a pair of arcs
that share the points. This is why we have G2/G3.
No, I was actually working with an OEM who sold a sign software package
that generated Gcode (very expensive). The problem was that their
software generated way too many short segments for no good reason which
caused problems
on the machine controls (it wasn't LinuxCNC or Mach3). They simply
On 20 April 2012 01:38, gene heskett ghesk...@wdtv.com wrote:
On Thursday, April 19, 2012 11:19:00 AM Adrian Carter did opine:
Gene,
Sorry to hear of the issues you had! I have been away from email today,
so only just catching up - but glad to hear you got it sorted out in
the end.
Hello,
If anyone is interested I posted some picture of my HCNC project machine. I
have started the retro rebuild process.
Warning: the pictures my be disturbing to some machine lovers because of
all the missing parts...:)
Viesturs Lācis wrote:
2012/4/19 Jon Elson el...@pico-systems.com:
But, LinuxCNC does not do arbitrary arcs, but only arcs in one of the three
orthogonal planes.
How hard would it be to add that? It would require 3 coordinates for
each of start, end and center point.
The first
Chris Radek wrote:
The correct solution is probably to specify the plane's normal vector.
While it's entirely possible to do, I doubt anyone would ever use this
feature if someone did the work to implement it.
Yup, messy. Maybe NURBS is really the way to go, it seems to solve several
of
Kenneth Lerman wrote:
Others have stated that arcs must be in one of three orthogonal planes.
Since linuxcnc can do helices, that isn't precisely true.
A helix is a special case, where an arc in one of the 3 defined planes
adds a
coordinated linear movement of one axis not involved in the
Hi Mike,
Looks like a fun project.
But,,
I dont want to discourage you too much but if you use a Stepper or something
to turn
the turret you will have to address some issues.
The turret has to have air to hold it down while machining. this air is
part of a pretty complicated system involving
..suppose you had a five axis millimg setup with the normal xyz plus alpha-beta
rotation of the cutter rotation axis about a shperical center. then suppose
that to take advantage of these spindle axes, you wanted to mill a planar facet
on a part that was tipped at say five degrees to the x and
The cuttoff slide was air over hydrolic to make it move smoother, just get rid
of it
and use a cut off for a lathe that way you can put a little chamfer on the
OD before you part off.
Collet closer is air.Hope you have the solenoids for it because they keep
the collet closed after the air is
I don't remember the complete syntax and symbols used but on my fanuc 15m
control G68 sets the rotation angle of one rotary axis. You can use two G68
lines to rotate two rotary axes. The regular 2D code then works at the
angle described by the G68 definitions. It takes some thought to get the
On 19.04.12 12:25, gene heskett wrote:
Ahh, but which sd* is it: From dmesg when I plug in the reader:
[snipped uninformative dmesg output]
Having a usb card reader with a small SD card in it, lying on the desk,
I've just plugged it in for comparison with your tribulations. On ubuntu
10.04, I
On Thursday, April 19, 2012 11:07:08 PM Mark Cason did opine:
On 04/19/2012 11:25 AM, gene heskett wrote:
On Thursday, April 19, 2012 12:08:58 PM Mark Cason did opine:
On 04/19/2012 10:15 AM, gene heskett wrote:
On Thursday, April 19, 2012 10:34:37 AM Mark Wendt did opine:
Humm,
I know this is a serious topic but this happened to me on my 15m:
G68 axis rotation
M68 turns on the comveyor on this machine.
Yeah you know what I did
Some sadistic machine tool builder did that on purpose
Terry
- Original Message -
From: Stuart Stevenson stus...@gmail.com
To:
On Friday, April 20, 2012 12:32:56 AM Adrian Carter did opine:
On 20 April 2012 01:38, gene heskett ghesk...@wdtv.com wrote:
On Thursday, April 19, 2012 11:19:00 AM Adrian Carter did opine:
Gene,
Sorry to hear of the issues you had! I have been away from email
today, so only just
let the machine keep track of where the intial part origin goes when rotary
axis moves with a macro that contains trig, the rotation centers of the machine
setup, and g92s. then just do all the programming based on that single part
origin. the gcode is then portable between different
It seems to me that the likelihood of fixing all of the methods of gcode
generation such that they don't generate short line segments is
approximately zero. Also, it seems that even if a proprietary LinuxCNC
gcode extension allowed arbitrary plane arcs, splines, etc. that the
likelihood of CAM
52 matches
Mail list logo
