On 7/28/2018 8:58 AM, Sebastian Kuzminsky wrote:
On 07/27/2018 02:39 PM, Kurt Jacobson wrote:
So the question is, why did LCNC choose to use relative positions for the
probe parameters? There must be a good reason to not follow what seems to
be a standard among other controllers, but the only
Hi Seb,
On 4/1/2014 1:45 PM, Sebastian Kuzminsky wrote:
I'm not sure exactly what state it's in currently. After i make the
2.6 branch I hope to speak with Sam Sokolik and Robert Ellenberg and
see where things stand. I'm hoping to merge it into master for the
following (2.7) release cycle
On 3/18/2014 12:31 AM, Andy Pugh wrote:
On 18 Mar 2014, at 01:44, David Bagby d...@calypsoventures.com wrote:
If G43 w/o an H word was a syntax error, this would not be an issue as
we'd stop at the G43 block.
Just to throw in another quirk. Lathe controls often have both M6 and G43
Hi,
Seb's email happened to draw my attention to this patch.
IMHO, the loadtool code already had a bug in it, and this patch will
make the bug happen 100% of the time that loadtool is used.
I understand that T#==H# is a common gcode convention. The key word here
is convention...
I am concerned
On 3/17/2014 1:00 PM, andy pugh wrote:
On 17 March 2014 19:09, David Bagbyd...@calypsoventures.com wrote:
The gocde state of a program should be controlled by the program
(according to the control language the program is written in: in this
case, gcode).
Yes, but, isn't it the case that
On 3/17/2014 2:46 PM, Gene Heskett wrote:
On Monday 17 March 2014 17:23:05 David Bagby did opine:
[snip]
This is not anything that I have ever played with. Why? Because I do the
majority of my TLO's via a probing touch, and set the corresponding G55-56-
etc co-ordinate system
Sigh - bad typo in my sentence:
On 3/17/2014 4:15 PM, David Bagby wrote:
That's not the same as setting a TLO value and using G43 to get TLO
compensation done in the control logic as MC moves are converted to MC
moves.
make that ... as WC moves are converted to MC coves.
Dave
Ah, I see that Dewey just pushed a patch that adds some control options
for G43 usage to ngcgui.
(ref loadtool.ngc: provide options for g43 control on the commit list).
The loadtool now looks like:
oloadtool call [#toolno][#use_g43][#h_for_g43][#verbose]
I see that as much better. I also see
Hi Robert,
If you try to do blending between feed and rapid moves, I think it needs
to be an option and that it's important that the option be turned off by
default.
FYI, my reasoning:
Today, LCNC is a G code driven CNC implementation.
C code is inherently a modal language and G0 G1 are
On 2/13/2014 11:34 AM, Chris Radek wrote:
On Thu, Feb 13, 2014 at 10:14:24AM -0800, David Bagby wrote:
In contrast, a rapid G0 move is go from A to B by spinning up the
motors as fast as they will go and end up at B.
The _only _thing guaranteed for a rapid move is that the machine will
end
Hi Seb,
I'd started to made a patch per yesterday's email thread. When I got up
this morning (I'm on Pacific time) I saw this thread and that Charles
had already done part of the change. Since the end result is the same,
I did not go back and apply his patch first and then re-create this
Charles,
On 1/16/2014 11:03 AM, Charles Steinkuehler wrote:
Either way, I don't really think the ARM/x86 platform key belongs in
the configuration selector at all.
Then I guess we are at really opposite points of view on this topic.
Let's take a bit little tip in the way back machine in
Seb and others,
I remembered that the doc you referenced mentions the LCNC repo on git hub.
That made me think that using git hub may save reinventing the wheel here...
I'm thinking that fork then pull request is favorable over push patch.
Instead of developing patches against the repo in
On 12/21/2013 6:53 AM, Dewey Garrett wrote:
...
From what you wrote, I'm inferring that you are maybe thinking only of
the x86 configs (which until recently has been the entire set).
It's all i know about -- I have only worked in the master branch of g.l.o:
Hi,
A reorganization of the x86/PC configs is welcome (and needed in my
view) - thanks.
From what you wrote, I'm inferring that you are maybe thinking only of
the x86 configs (which until recently has been the entire set).
A while back, I reorganized an ARM config directory to give it some
does for
projects that are 100% GPL).
Dave
On 9/11/2013 5:24 PM, Chris Radek wrote:
On Wed, Sep 11, 2013 at 03:53:42PM -0700, David Bagby wrote:
It seems to me that if everyone that made a change to those *had* to
contribute it back (due to GPL), we'd just get a bunch of patches
Jeff,
On 9/11/2013 6:27 PM, Jeff Epler wrote:
On Wed, Sep 11, 2013 at 07:41:36PM -0500, Charles Steinkuehler wrote:
If there are no objections, I will add a header indicating I release the
various device tree files I wrote into the public domain.
I would greatly prefer not calling new
On 9/11/2013 1:14 PM, Charles Steinkuehler wrote:
Thanks for looking through the files! Several of them are mine, and I
just missed adding the license header. I'm willing to license the
files GPLv2+ or whatever works best for the project, including public
domain or even something like
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 8/16/2013 2:51 PM, andy pugh wrote:
On 16 August 2013 22:24, David Bagby d...@calypsoventures.com 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
On 8/11/2013 7:42 AM, Kent A. Reed wrote:
What GUI is David running? Has he also observed the behavior you report?
Sorry I'm not in a position just now to replicate your results.
Regards,
Kent
The system is running from the SD card on the BBB. I've I've been
running Axis when the symptom
Hi,
This thread caused me to clean up some notes I'd jotted down during
Wichita related to this topic.
In this thread I think that different people are talking about different
aspects of a topic that I think of as implications of multiple
programmatic motion sources.
Alas I think about this
that I placed in the pics as
feeding motion. I need to think about this some more.
Dave
On 7/15/2013 6:01 PM, Jon Elson wrote:
David Bagby wrote:
Hi,
This thread caused me to clean up some notes I'd jotted down during
Wichita related to this topic.
In this thread I think that different people
On 7/12/2013 6:59 AM, Michael Haberler wrote:
I routinely build on the BeagleBone and have no surprises to report, meaning
this will be available as a build option as soon as we declare victory. Since
the last remnants of inline assembly code are gone, the
'--with-platform=foo' option
On 6/30/2013 10:36 PM, Chris Morley wrote:
Date: Sun, 30 Jun 2013 22:25:20 -0700
From: d...@calypsoventures.com
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] toolstore discussion notes: Andy/mhaberler
Andy, Michael,
The network accessibility of the data store and
Andy, Michael,
The network accessibility of the data store and the associated API is
key to both providing and understanding the functionality that this
approach could provide.
Is there a proposed design document that lays out the API?
Dave
During last week, there were several discussions about LCNC at a block
level; both how it is today and what could be tomorrow.
For those interested in a copy of the resulting diagrams, some pics I
took of the diagrams can be found here:
Charles,
Sorry for the delay - I had intended to follow up on this email last week.
Please see below
On 6/7/2013 12:08 PM, Charles Steinkuehler wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6/7/2013 1:31 PM, David Bagby wrote:
Hi,
We (Steve Stallings and I) would like to let you
On 6/10/2013 1:34 PM, Charles Steinkuehler wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6/10/2013 2:38 PM, David Bagby wrote:
If you have any specific pinouts setup already, I can help with
crafting a hal_pru_generic configuration that will match up with
your board. The HAL
Hi,
We (Steve Stallings and I) would like to let you know about a gadget
we’re expecting to bring to Wichita: The K9 SmorgasBoard.
The K9 is a hardware “cape” board for the BBB (and BBW) that was
designed as a developer’s tool for embedded LCNC work. The cape makes
most of the bone subsystems
Hi Kent,
I was your dev list post and noticed that your blog link says that
you're running the starter kit from Michael on a BBB and that it's a 3.8
kernel with Xenomai etc. I was about to build a 3.8 for the BBB etc,
but decided to ask Michael where to find whatever he's already built.
He
Hi,
I've been reading and thinking about this thread; I'd like to offer up
my 2 cents worth -
I have interest in making LCNC as easy to adopt and use as possible.
This interest has lead me to I've spend a fair amount of time thinking
about what aspects of LCNC assist or hinder LCNC adoption.
Hi,
I saw this post today on the BB lists. The 1st two URLs have good info
re device trees and BBB.
I thought I'd pass this along for those thinking about device
trees/Hal/BBB Pin mux interactions.
Dave
___
Looking for more Information on Device Tree Overlays Usage (Angstrom
-3.8
Wow, That was all nicely formatted and readable, then I pasted into
Thunderbird and hit send
Please excuse the odd format conversions that crept in (bold turned to
*, and underlined stuff only underlined the 2st and last chars of the
phrase and sentence periods seem to have lost spaces
Hi,
Sorry for the delay in responding, other things pulled me away from this
topic during the end of the week.
On 4/25/2013 2:39 PM, Charles Steinkuehler wrote:
OK, lots to comment on here. I may not hit everything, but further
details in-line (along with some major snippage to keep the
Hi Charles,
On 4/25/2013 5:55 AM, Charles Steinkuehler wrote:
On 4/24/2013 9:27 PM, David Bagby wrote:
Charles: Am I correct to assume that your LCNC stepgen PRU code is
configured to use the same BBW pins as the BeBoPr (I think I remember
reading that you were using that for prototyping)?
I
Hi,
I've been digging into the differences between the new Beaglebone Black
(BBB) and the original Beaglebone (white or BBW).In particular I've
beenreading the BB docs with an eye toward how the BBW-BBB changes may
impact the LCNC on BBW efforts.
Recently Michael said that there would soon be
From: David Bagby m...@calypsoventures.com
Reply-To: m...@calypsoventures.com
To: emc-developers@lists.sourceforge.net
Hi all,
While I've monitored this list for a couple of years, I think this is
the first time that I've offered some direct input -
Please excuse the delay in my
Kent,
Thanks for letting me know the the cc got thru for my 2nd try.
I think I'll just accept that sometimes email bits go walk about and
not fret over it unless it starts happening repeatedly.
Dave
On 10/4/2012 2:25 PM, Kent A. Reed wrote:
Dave:
I received your second try by way of the mail
Hi all,
While I've monitored this list for a couple of years, I think this is
the first time that I've offered some direct input -
Please excuse the delay in my input - I get the dev list emails as daily
digests.
Re Shouldn't Axis issue a g43 automatically when the user touches off
to the tool
Hi,
One of my spare time projects is poking around the EMC code in an initial
effort to learn how the pieces fit together.
The thread re the CNC workshop gave me a thought - It would be great to have
a chance to learn from EMC gurus how it's put together.
Is anyone who's familiar with EMC's
41 matches
Mail list logo
