On 12.01.12 02:22, gene heskett wrote:
But, now there is a new CadSoft Eagle problem for all of us that renders
the whole project moot.
Apparently my freebie copy of eagle has timed out, the screen it opens
is about 75% transparent and extremely bleached out, rendering it unusable.
Gene, I
On 12.01.12 17:28, gene heskett wrote:
Which is the reason I am going out to get another armload of 2 1/2 ring
binders after dinner, I'm going to convert it to dead trees.
Very glad to hear that the eagle has been landed, if not yet fully
tamed. One reminder, there are two manuals,
On 13.01.12 02:58, gene heskett wrote:
On Friday, January 13, 2012 01:52:13 AM Erik Christiansen did opine:
As Rainer says, once the peculiarities of parts editing are sufficiently
mastered, it's fairly easy.
And apparently that is my first requirement, the detector end in these slot
Forgot to mention that the 1_mystuff.lbr library need only be copied to
the lbr directory in your install, for the application to pick it up
when it starts. (Just thought I'd save wear on those manual pages. :-)
Erik
--
Meskimen's Law:
There's never time to do it right, but always time to
On 14.01.12 23:25, gene heskett wrote:
But what I now see in the strace output is a fail of a FUTEX that could
have been there all along, whatever the heck that futex is.
Well, t'aint so different from a mutex (which is just a semaphore, or
mutual exclusion flag, normally used by threads
On 16.01.12 05:11, gene heskett wrote:
On Monday, January 16, 2012 05:05:23 AM kurniadi engkur did opine:
Hai,
Saya membuat profil Netlog dengan foto saya, video, blog, dan event dan
saya ingin menambahkan kamu sebagai teman sehingga kamu dapat
melihatnya. Pertama-tama, kamu harus
On 17.01.12 20:30, gene heskett wrote:
On Tuesday, January 17, 2012 07:15:33 PM Fox Mulder did opine:
Am 17.01.2012 21:47, schrieb gene heskett:
Checking requirements, I see that libpng14.so.14 is required so
you helped me build a script: gene@shop:/opt/eagle-6.1.0$ cat
bin/eagle
On 17.01.12 21:30, Ed Nisley wrote:
On Tue, 2012-01-17 at 20:30 -0500, gene heskett wrote:
If I fix the library,
will that fix the schematic when it is next loaded?
Nope, the schematic holds copies of all the components, so that you
can't inadvertently wreck all your circuits with a
On 17.01.12 21:31, Jack Coats wrote:
IMHO, we need to keep references to EMC and EMC2 on the web site as
'historical artifacts', and also reference the NIST project that
started the initial 'Enhanced Machine Controller' project and named
it. Like in
On 18.01.12 00:59, gene heskett wrote:
Well, the only marks on the package show on top of it and they are
confusing. On about a 20x blowup of the pdf'd brochures page showing the
pin names, it looks like this for a bottom view.
led end sensor end
-Free Agreement, AIUI.
It's not as if our name is EMC. It is Enhanced Machine Control.
In a dispute, that is what would have to be objected to, and forbidding
the English speaking world from using abbreviations seems ambitious.
Enrico Caruso could not legitimately have complained that Erik
On 18.01.12 09:06, Dave Caroline wrote:
I would have expected some public discussion about new names etc
before a final decision
Yes, but it was probably frustrating enough to haggle with the
litigious lot, without becoming the meat in a sandwich. After we've all
blown off steam, I kinda figure
On 18.01.12 10:01, gene heskett wrote:
I was under the impression that there was a hidden linkage
between the schematic and the footprint.
The hidden linkage is the pin mapping in the package. The package
automatically appears in the board view when the symbol is placed in the
schematic.
On 29.01.12 09:31, Michael Haberler wrote:
Am 29.01.2012 um 06:37 schrieb Erik Christiansen:
--
$var1 = $foo + 1
$var2 = 10
if $var1 $var 2
...
else
...
endif
--
Indeedy, but even the '$' is unnecessary.
I'm not sure
On 29.01.12 12:59, andy pugh wrote:
On 29 January 2012 12:29, Erik Christiansen dva...@internode.on.net wrote:
While that could be 'de-hashed' without an alternative numbered
parameter identifier, I don't see how you'd propose to handle:
#43 = foo / #44
I am puzzled how you would
On 29.01.12 08:57, Kent A. Reed wrote:
Erik:
There's nothing secretive about emc-developers. Anyone can subscribe
to the list and anyone can peruse its archive of messages. (see the Wiki)
My point was not self-referential, it related to keeping the discussion
in front of all users. I feel
On 29.01.12 14:20, andy pugh wrote:
On 29 January 2012 14:02, Erik Christiansen dva...@internode.on.net wrote:
oo = 1
OK, O Codes. They'll all go in a declutter, replaced by their naked
keywords,
No, that is creating a second named parameter in order to be more
ambiguous later
On 29.01.12 10:23, Kent A. Reed wrote:
On 1/29/2012 9:52 AM, Erik Christiansen wrote:
And if we make the effort to update the subject line, as I have done,
then the post is still presented in the thread by my mailreader, but
the subject immediately identifies it as a digression. There being
On 29.01.12 13:12, Kenneth Lerman wrote:
On 1/29/2012 9:02 AM, Erik Christiansen wrote:
But I haven't seen a troublesome gcode example yet. :-)
Remember that just because a computer can understand a grammar does not
mean that a person can. (Consider the C++ grammar.)
Point taken. (And perl
On 29.01.12 11:14, Kent A. Reed wrote:
On 1/29/2012 10:55 AM, Erik Christiansen wrote:
...
What further simplifies the task is that we can, for example, group the
clauses which are common to G0, G1, etc., and give them a name. The part
of the grammar tree for G1 then gets the handling
On 29.01.12 13:30, Kenneth Lerman wrote:
On 1/29/2012 10:55 AM, Erik Christiansen wrote:
What further simplifies the task is that we can, for example, group the
clauses which are common to G0, G1, etc., and give them a name. The part
of the grammar tree for G1 then gets the handling
On 29.01.12 19:31, Michael Haberler wrote:
Am 29.01.2012 um 16:55 schrieb Erik Christiansen:
What further simplifies the task is that we can, for example, group the
clauses which are common to G0, G1, etc., and give them a name. The part
By 'grouping common clauses' do you mean
On 29.01.12 23:05, Kenneth Lerman wrote:
Are you suggesting that a three axis machine where there is
no A axis should have a different grammar than a four axis machine that
does have an A axis.
No, there is no such constraint in the current parser, and there is no
reason to imagine that
On 30.01.12 02:33, Steve Blackmore wrote:
On Sun, 29 Jan 2012 10:43:18 -0800, [Kirk] wrote:
Regarding messing with the g-code interpreter, my vote is that g-code
should describe axis position, feedrate; and spindle speed and
direction, and little more. Everything else should be handled with
I'm still catching up on a 1200 post backlog across a couple of lists,
so here's a late reply.
On 25.01.12 05:44, gene heskett wrote:
I looked at the gawk man page, didn't see any mention of floating point
math so I kept on looking. Bash only does integer. Didn't see any mention
of sed
On 30.01.12 05:35, Mark Wendt wrote:
On 01/30/2012 01:14 AM, Erik Christiansen wrote:
snippage
1) Be mnemonic. i.e. give some farnarckling clue as to what the command
does. (Even MOV is orders of magnitude superior to 0x01 or g01.)
Erik, is this what you meant by farnarkling
On 30.01.12 12:37, Kent A. Reed wrote:
On 1/30/2012 7:54 AM, Kenneth Lerman wrote:
I would hope for
1) a formal description of the grammar we already have. As Erik points
out, the LinuxCNC interpreter implicitly defines a grammar. It's just
hard to tell what the grammar is. It's hard to
On 30.01.12 07:54, Kenneth Lerman wrote:
On 01/30/2012 12:28 AM, Erik Christiansen wrote:
What is being missed here is that the present parser does all that you
fear above, just without the maintainability and documentation benefits
conferred by a higher level implementation, using powerful
On 01.02.12 00:05, Michael Haberler wrote:
ok, while this wonderful discussion was raging on, I built a working
parser for the current linuxcnc dialect, as an experiment in
feasability (this is NOT an end-user tool!)
It would take all the fun out of it, if it were. :-)
Before using the debug
On 31.01.12 21:45, dave wrote:
To my uncluttered mind ... read blank ...
is this a good way to set the state of a machine at any given line as a
precursor to restart from line no?
IIUC¹, running an interpreter through the code from line 1 to a given
line, with all external actions
On 01.02.12 11:48, Michael Haberler wrote:
Am 01.02.2012 um 09:23 schrieb Erik Christiansen:
The grammar specifies expression and control flow constructs, but seems
100% devoid of any explicit gcode grammar. I've scrolled up and down
twice now, but still can't see any rapids, moves
On 01.02.12 20:32, Kenneth Lerman wrote:
On 01/31/2012 11:14 PM, Erik Christiansen wrote:
Any need to know the run-time state of a modality before run-time is
illusory. That which needs to be known at run-time needs to be known at
run time, not before. It is worth understanding that the run
On 01.02.12 08:42, dave wrote:
On Wed, 1 Feb 2012 19:34:09 +1100
Erik Christiansen dva...@internode.on.net wrote:
On 31.01.12 21:45, dave wrote:
To my uncluttered mind ... read blank ...
is this a good way to set the state of a machine at any given line
as a precursor to restart
On 01.02.12 16:45, Michael Haberler wrote:
Am 01.02.2012 um 13:36 schrieb Erik Christiansen:
On 01.02.12 11:48, Michael Haberler wrote:
Currently I dont see a formal way to describe the interdependencies of
several words on a block. You can do the optional parameter words
On 02.02.12 09:11, John Kasunich wrote:
On Thu, Feb 2, 2012, at 08:20 PM, Erik Christiansen wrote:
On 01.02.12 20:32, Kenneth Lerman wrote:
3 -- A semantic analyzer (whether rule based or coded) will be necessary.
Do you want to prove some property of the gcode program, such as whether
On 03.02.12 12:49, Erik Christiansen wrote:
What I did in July does already check for some run-time conflicts which
I found in the doco, e.g. Turning on radius compensation in an illegal
plane:
The snippet can pick up the conflict in a simple fall-through gcode
program, but not if the axes
On 04.02.12 16:25, Michael Haberler wrote:
This is different from the original language: the pre-oword syntax was
context-free, which is why there's a meaningful EBNF in the Tom Kramer
report, and working context-free parsers based on ANTLR and bison like
here:
On 04.02.12 18:04, gene heskett wrote:
What would you folks use when you need an insulated pallet?
If nothing out of the junkbox will do, I'd fish out my old tin of
automotive bog and make up a few suitably sized slabs. Admittedly,
they'd have to be machined on the outside too, to make them
On 05.02.12 18:35, Dave Caroline wrote:
For the relatively smaller edge case of those wanting to
hand-code sophisticated machine control, gcode (even the LinuxCNC flavor)
For a lot of us hand coding is not an edge case, the available free
open source cam tools simply do not cater for
On 06.02.12 09:05, dave wrote:
andy pugh bodge...@gmail.com wrote:
So:
G95 G96 G7
M3 S500
G1 X100 Z50
Might become:
SpindleOn(mode=CSS, Speed=500)
Feed(X=100, Z=50, mode=FeedPerRev)
Did this just break coordinated feed?
I must say the clarity is better but you must be COBOL
On 07.02.12 09:47, andy pugh wrote:
On 7 February 2012 05:34, Erik Christiansen dva...@internode.on.net wrote:
let's have:
Spindle On mode=CSS Speed=500
Now the same verb can take different arguments:
Spindle Off
So that the programmer is dealing with a _language_
On 07.02.12 07:11, Stuart Stevenson wrote:
APT does this and has since the 1960s.
Thanks for the heads up. That textual CAM package is very interesting,
even though it neither documents our LinuxCNC dialect nor provides a
more human readable variant of same. We could change our goal to gcode
Hopefully self-reply is permissible when not due to too-rapid pressing
of send, but a useful update of progress.
On 07.02.12 20:47, Erik Christiansen wrote:
To allow us to program G96 D3000 S500, this time not starting the
spindle, we also need to support:
Spindle mode=CSS Revs3000 Speed=500
On 07.02.12 19:17, Stuart Stevenson wrote:
My comment was dual purpose.
To encourage you to use the APT language and syntax when you develop the
language for running LinuxCNC.
I'll have to look for some APT language doco then. Maybe it does provide
sufficient gcode equivalents for
On 08.02.12 11:00, andy pugh wrote:
On 8 February 2012 05:37, Erik Christiansen dva...@internode.on.net wrote:
But is the following much more readable than raw gcode?
INDIRV/0,1,0 $$ direction the tool initially moves
http://en.wikipedia.org/wiki/APT_(programming_language)
Has
On 08.02.12 14:02, Viesturs Lācis wrote:
Thirdly, I tend to agree with Steve Blackmore, who posted in another
thread that g-code is basically a standard in cnc world with lots of
minor variations, but the essence is the same.
IMHO drifting away from it would considerably decrease appeal of
On 08.02.12 07:21, Stuart Stevenson wrote:
Again - shamelessly
My interest is having a full free APT system on Linux. Inclusion in
LinuxCNC would cause development - voila - APT on Linux. :)
OK, I have some catching up to do. Is Apt on linux highly desirable
because there is no other free
On 08.02.12 14:12, andy pugh wrote:
On 8 February 2012 14:02, Viesturs Lācis viesturs.la...@gmail.com wrote:
Erik proposed this line:
Arc CW X0 Y1 Centre X1 Y0.5 Feedrate 25
Is centre x1 y0,5 are incremental distance from current point or
absolute coordinates of center point?
Well, the
On 10.02.12 13:13, craig wrote:
In considering progrmming languages it is worth noting that there are a
fair number of people, like me, who are clerically challenged. 80% to
90% of my errors are typographical. The number of such errors is highly
correlated to the number of key strokes.
On 11.02.12 10:51, BRIAN GLACKIN wrote:
One question, from someone who hasn't used CAM. The CAM package would
provide a way to specify the number of tool passes, to reach the final
depth of a machining operation?
Thankyou Brian, for replying to my question in that paragraph.
(Unfortunately,
Here's Brian's post, as it came through this end of the email pipe:
» » »
Subject: Re: New dialects [Was: Do CAM instead? ]
Yes, much more readable. The downside is that you can't do a restart at
line without specifying which iteration of the outer loop to restart
from. And neither the GUIs
On 12.02.12 13:03, Alan wrote:
So my question is really about allowing extensibility in the future. I
do not think that I am talking here about filters which to my limited
understanding are something like a macro facility. Have I got that right
or are they more than that?
From the
On 14.02.12 15:20, gene heskett wrote:
The encoder wheel
itself will be trapped between the spindle bearing lock buts.
Gene, have you considered using a piece of thin PCB material for the
encoder wheel, since all your sheet Al is toffee? A piece of the brown
phenolic stuff would be easier on
On 15.02.12 20:24, Erik Friesen wrote:
Can anyone give me some pointers on X server, if 10.04 uses it, or more
information on how to do what is hinted to here -
http://rtai.dk/cgi-bin/gratiswiki.pl?Latency_Killer
Pretty much every linux/unix distro uses X11, and so has an X server.
See
On 17.02.12 21:55, Kirk Wallace wrote:
I looked in some of the include files and didn't see where FOR_ALL_INSTS
was defined, but gave up after a while.
Kirk, you made me curious. Here's a quick way to that kind of stuff:
$ egrep -r FOR_ALL_INSTS /usr/local/src/emc2-dev-17a4ae5/ /tmp/grep
$
On 19.02.12 00:29, Kent A. Reed wrote:
I see that I last participated on the first of February. I was diagnosed
with pneumonia the next day and have been out of it since.
And the antibiotics leave you like a wrung-out dishrag too, ISTR. It's
great to hear that you have most of that behind you
On 20.02.12 21:03, gene heskett wrote:
Assuming its hooked backwards, how much normal one diode drop current going
the wrong way does it take to kill a typical LED?
Not much. Limiting the current to the microamps which I'd consider
(possibly) safe make it difficult to detect any output if
On 20.02.12 23:46, gene heskett wrote:
On Monday, February 20, 2012 11:39:08 PM Erik Christiansen did opine:
Why isn't practice ever nearly as straightforward as theory? ;-)
That I believe, we can lay right in Murphy's lap. Which ought to be as hot
as Micky D's coffee. Maybe that SOB
On 21.02.12 07:00, Ed Nisley wrote:
On Tue, 2012-02-21 at 16:15 +1100, Erik Christiansen wrote:
But it has banana sockets, so it'll do me.
Murphy also has his way with them, particularly nowadays:
http://softsolder.com/2012/02/08/power-supply-banana-jack-misfit/
Grumble...
I do like
On 25.02.12 10:10, andy pugh wrote:
On 25 February 2012 01:11, kqt4a...@gmail.com wrote:
Could you please elaborate
Are you sailing between planets,
(Sat here waiting for the taxi)
I will be on the boat Derry/Londonderry and can be tracked here:
On 19.02.12 09:29, Kirk Wallace wrote:
In looking at the wiki APT page:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?AptProgrammingForEMC
there is a link:
http://www.nfrpartners.com/nfraptlang.htm
What comes to mind is that APT may not be easier for simple g-code
tasks,
Kirk, you've
On 26.02.12 14:14, Roland Jollivet wrote:
And I thought thread rolling required huge rollers
http://www.youtube.com/watch?v=rt8VfgfWa54
OK, it is a small OD, but I did'nt think it was doable. The whole
contraption looks pretty lightweight .
Hey, yes, that's very doable-looking. Found
On 26.02.12 09:00, Stuart Stevenson wrote:
I am an unashamed proponent of APT so take these comments in that light.
And after reading what I've snipped below for brevity, I better
understand the appeal of APT. You're on the other side of the complexity
bridge from those of us yet to cross it.
On 26.02.12 09:04, dave wrote:
[... Description of some APT possibilities snipped ]
The only reason to do this is to make reasonable CAM available to
those that don't have the $$ or are just philosophically resistant to
using non-GPL software.
Yes, a popular FOSS CAM tool, well loved by
On 27.02.12 20:54, Lars Andersson wrote:
In EMC.ini I have PROGRAM_PREFIX = /home/la/emc2/scripts.
This seems to affect defaults for both script and gcode files.
I would like to have different paths for script and gcode files.
Can I have that?
On 28.02.12 16:19, Eric H. Johnson wrote:
On 28.02.12 12:32, dave wrote:
Check this mill out. Used to make the molds for the America's Cup
boats.
http://www.janicki.com/5-axis-milling.html
That offhand mention of contra-torque backlash elimination is kinda
interesting, but perhaps it's not that different from a loaded ballnut
pair?
On 18.03.12 10:54, Kirk Wallace wrote:
Thinking a little more, I suppose I could float the ATmega along with
the KBIC and isolate the TTL side of the RS485 chip. This puts me into
thinking about floating supplies.
A little NME0505D is reasonably cheap, but only has 1 kv isolation,
which is
On 13.03.12 16:09, Kirk Wallace wrote:
Since none of the source files ever changed, none of the #ifdef
RTS_ENABLE's got done.
Kirk, that's pretty much the only reason for using make - to speed up
software builds which take too long if everything is done, even if only
one file has been changed.
On 20.03.12 22:21, Kirk Wallace wrote:
I've got my brain sore thinking about this, so I'm a little foggy, but
it seems the safest way to do this is to break the g-code program into a
separate program for each tool change.
If doing that, then we might keep the files for a job in a directory
On 21.03.12 08:29, dave wrote:
On Wed, 21 Mar 2012 19:24:52 +1100
Erik Christiansen dva...@internode.on.net wrote:
On 20.03.12 22:21, Kirk Wallace wrote:
I've got my brain sore thinking about this, so I'm a little foggy,
but it seems the safest way to do this is to break the g-code
On 21.03.12 10:27, Kirk Wallace wrote:
On Wed, 2012-03-21 at 19:24 +1100, Erik Christiansen wrote:
On 20.03.12 22:21, Kirk Wallace wrote:
If there [were]
where might have been a left over accent from Saint Patrick's Day.
Please accept my apologies for the pedantry. (One possible
On 22.03.12 11:24, gene heskett wrote:
On Thursday, March 22, 2012 09:59:01 AM Erik Christiansen did opine:
But LinuxCNC doesn't know its current state in an exportable way, so has
nothing to put on a stack, AIUI. And we don't have gcode interrupts. For
the moment, we seem to only have
On 23.03.12 16:47, Erik Christiansen wrote:
Sub drill_em_there (123.456, 789.012) {
Rel Drill X#1 Y#2 Z1.5 Retract 2.8 Repeat 3 // Drills 3 holes.
}
Ugh, too much typing of grammars and emails, and not enough observation.
Those parameters shouldn't
On 23.03.12 08:53, Michael Haberler wrote:
As for introspection on state at the gcode level, see
http://www.linuxcnc.org/docs/devel/html/gcode/overview.html#_predefined_named_parameters_a_id_sec_predefined_named_parameters_a
Many thanks for that link, Michael. And I thought that:
On 23.03.12 15:24, Viesturs Lācis wrote:
The thing is that there is a hill with trees on one side of the house.
It is very nice, because to large extent it protects the house from
western winds (statistically wind from west is most common in LV, as
it blows from sea/ocean to continental
On 23.03.12 18:34, Viesturs Lācis wrote:
Is there a place, where I can read, how are such things set up? I am
thinking that such a repeater could be placed on the roof of barn
(very far end of it is not blocked by the trees on the hill), which
is not the place, which could be conveniently
On 23.03.12 10:59, gene heskett wrote:
On Friday, March 23, 2012 10:23:48 AM Erik Christiansen did opine:
Sub drill_em_there (123.456, 789.012) {
Rel Drill X#1 Y#2 Z1.5 Retract 2.8 Repeat 3 // Drills 3
holes. }
I just got lost, 3 holes but only one XY specified
You're up bright and early on a Saturday morn, Gene. :-)
On 24.03.12 05:43, gene heskett wrote:
On Saturday, March 24, 2012 04:41:17 AM Erik Christiansen did opine:
In a later post, it did sink in that a gcode subroutine has its own
scope, so similarity to a 'C' block with the same
On 23.03.12 11:20, Michael Haberler wrote:
[ snipped links to more doco than you could read in one weekend ]
See tests/remap/introspect/oword.py for state access.
Interesting that a 7-week old copy returns e. :-)
(Perhaps it's just a non-zero return value that's expected.)
I'll sneak up on a
On 23.03.12 11:20, Michael Haberler wrote:
You will find lots of examples for embedded Python usage in the canned
demos under configs/sim/remap, and regression tests using these
features, like under tests/remap and tests/interp.
In
a window above the C1G so I can see all them
purty leds flickering away as it works.
That seems worth doing, especially if it goes up on that high shelf,
where it's highly visible.
On Saturday, March 24, 2012 10:07:19 AM Erik Christiansen did opine:
Having just finished subroutines
On 24.03.12 15:31, Michael Haberler wrote:
Am 24.03.2012 um 13:27 schrieb Erik Christiansen:
On 23.03.12 11:20, Michael Haberler wrote:
You will find lots of examples for embedded Python usage in the canned
demos under configs/sim/remap, and regression tests using these
features, like
On 27.03.12 01:46, gene heskett wrote:
What do we normally assume to be the fwd drop of the usual LED, I assume
IR, opto-isolated input?
The good old 4N25 to 4N37 range is typically 1.18v at 10 mA, according
to the datasheet, so a bit less than the 1.6v we're used to from red
LEDs. (OK, I
On 27.03.12 00:45, Kirk Wallace wrote:
The manual I found here:
http://www.scribd.com/doc/47247471/2M542-Manual
says at the bottom of page 6, that 5 Volts can be applied to the inputs
without a limit resistor, unless I'm missing something. Maybe there is
already a limit resistor inside.
On 27.03.12 07:02, gene heskett wrote:
On Tuesday, March 27, 2012 06:07:01 AM Erik Christiansen did opine:
By the way, what's a 2M542?
The smallest of a fairly well regarded line of Chinese drivers, 50 volt,
4.2 amp stepper driver. It can microstep at 1/128 but I run them at 1/16
where
On 03.04.12 09:23, gene heskett wrote:
They run very well indeed, until you quit an app. At which point there
seems to be a 5 to 10% possibility of the whole box going away about 1
second after the apps screen goes away, leaving a black screen frozen
mouse cursor. Hit the reset or power
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 20.04.12 09:53, Viesturs Lācis wrote:
I was thinking about Kenneth's idea:
2012/4/19 Kenneth Lerman kenneth.ler...@se-ltd.com:
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
On 20.04.12 12:25, Jon Elson wrote:
Stuart Stevenson wrote:
Doesn't even G02/G03 result in a series of very small linear moves sent to
the servo motors? Wouldn't a NURB conversion do the same thing
Yes, in a way. But, the G02/G03 is known to be a single move, so
there is no velocity
On 21.04.12 23:23, Jon Elson wrote:
Viesturs Lācis wrote:
What I see the big issue for solving this in trajectory planner or
whatever _inside_ LinuxCNC is that I do not see, how to determine by
some hard facts, what is the best way to determine the lookup amount.
The number of blocks
On 26.04.12 09:31, Gabriel Willen wrote:
Andy would you care to enlighten me a little on your sign lookup table? I
have an xmega laying around I have been playing with. I have it decoding
and picking up the hall positions. But I'm not grasping the sign lookup
table. I have read a half a
On 15.05.12 16:48, Kent A. Reed wrote:
On 5/15/2012 4:12 PM, dave wrote:
dave@dsk:~$ cd /media
dave@dsk:/media$ chmod 0777 -v -R -f Lexar
mode of `Lexar' changed to 0777 (rwxrwxrwx)
dave@dsk:/media$ fdisk /media/Lexar
last_lba(): I don't know how to handle files with mode 40700
You
On 16.05.12 19:24, Erik Christiansen wrote:
Kent, what is the fs_type on your USB stick?
Sorry Gentlemen; s/Kent/Dave
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security
On 18.05.12 17:25, Kent A. Reed wrote:
On 5/18/2012 4:28 PM, Przemek Klosowski wrote:
BTW, now that we can't use EMC2 any more, and LinuxCNC seems longish
and awkward to type, I am tempted to start using LCNC.
It has seemed to me LCNC would be a good compromise if anyone starts
tackling
On 18.05.12 23:09, Jon Elson wrote:
The description in the user manual is almost completely incomprehensible.
G10 L20 makes a little bit of sense, G10 L2 makes no sense at all.
The new web page:
On 19.05.12 13:47, Terry Christophersen wrote:
LMC or LNC sounds good to me
LMC says National Semiconductor CMOS op-amps to me, e.g. LMC662,
but if you added two pen strokes, we'd have: EMC :-)
If LinuxCNC really is too long to type, what about: LC ?
(Does that resonate at all? ;-)
Erik
On 22.05.12 21:44, Jon Elson wrote:
Matt Shaver wrote:
I would also be interested in hearing from any people with experience
in Fortran who would be interested in helping port this code to the
Linux platform. If you could indicate your level of Fortran experience
and any reasons for
On 23.05.12 09:55, Dave wrote:
I must admit that I have a strand of regular Cat 5 solid cable that runs
through the air between my house and garage/shop about 20 feet.. It was
meant to be a temporary fix - 10+ years ago.
It has survived ice, snow, wind, some tree branches bouncing on it and
On 23.05.12 11:25, Jon Elson wrote:
The only solution is to make the common blocks an include file. If
the compiler doesn't support that,
Please read the second half of my post from yesterday, in reply to
yours, first raising include. It provides links and some information on
gfortran,
On 23.05.12 11:25, Jon Elson wrote:
The only solution is to make the common blocks an include file. If
the compiler doesn't support that,
While I didn't manage to find basic gfortran INCLUDE doco in the keyword
index, it is here:
http://gcc.gnu.org/onlinedocs/gcc-3.3.6/g77/INCLUDE.html
OK,
1 - 100 of 839 matches
Mail list logo
