Jon,
Coming from more of a user integrator person here...
I think that I am with you on liking option 3 the best with number 2
next in line. I would even go so far as marking the 'old' driver as
deprecated and slated for removal on the next release. That warns
everyone that if they want to run
For what it's worth... I would second the notion that the new behavior
be the default. Much higher likelihood that it would "just work."
On 02/27/2017 10:52 AM, Jon Elson wrote:
> On 02/27/2017 09:42 AM, John Kasunich wrote:
>>
>> On Sun, Feb 26, 2017, at 03:51 PM, Jon Elson wrote:
>>> Actually,
None of the users' files should get touched during an update... tool
tables, .hal and .ini files, etc.
If we are worried about breaking the sqlite tool table file there are
far larger issues and you better not be touching user files, at least
not without asking if they want to keep the old, new,
There was some talk of it down in Wichita last week. I offered to work
on building some newer install and/or live images. The devs that were
there wanted to pin down kernel versions first. Once they have that
sorted out, I can work on an ISO.
I think the big concern is that there are road blocks
I am working towards implementing lathe roughing cycles g71/g72. There
was some discussion in Wichita as to using remap or integrating this
into interp. I am trying to get a feel for what the devs would prefer.
If a remap implementation is preferred, is there a proposal for shipping
these remaps
14:20, dragon <tfishw...@gmail.com> wrote:
>> I am working towards implementing lathe roughing cycles g71/g72. There
>> was some discussion in Wichita as to using remap or integrating this
>> into interp. I am trying to get a feel for what the devs would prefer.
>
be used as a starting
point to finally get the lathe roughing cycles implemented.
Thanks,
Todd
On 11/14/2016 09:48 AM, Sebastian Kuzminsky wrote:
> On 11/14/2016 08:20 AM, dragon wrote:
>> That was exactly my plan as well. Use a sub to make it more in line with
>> the way that linuxC
Personally I think that an interface and possible backing DB to tie
gcode, tools, and machines together is a great idea but should
definitely be separate from the tool table. It is an edge case and while
many users make use of the tool table, including those that do not even
have ATCs, there are
Andy,
I just looked at these two links. I REALLY like what you started here.
If you are open to my thoughts I will find some time in the next couple
of days to flesh out some further ideas and directions for this. I think
you made a great start.
Do you remember who you worked with at Tormach? I
If it is just for software development, why not use a virtual machine?
That is what I have been doing. Of course I am using a Linux host OS but
that should not make any difference.
YMMV
On 11/03/2016 10:08 AM, Jim Craig wrote:
> I am contemplating installing the linuxcnc live image on my laptop
I could use a bit of "back story" to help me understand the entire
problem. I spent a bunch of time browsing the code and looking at the
developer docs and notes over the past few days. I have some bigger
questions and thoughts, now.
If we put aside for a second the issues of defining a DB
Thanks for checking...
On 11/01/2016 11:50 AM, andy pugh wrote:
> On 1 November 2016 at 16:13, dragon <tfishw...@gmail.com> wrote:
>> Do you remember who you worked with at Tormach?
>
> Actually, looking back, it was someone at zbot that Tormach put me in
> touch w
For what it is worth, I am with Andy on this. An actual DB, even
something simple like SQLite, opens up many additional possibilities
while helping to prevent breaking a custom parser.
As he mentioned... this would allow other custom applications written in
almost any language to interact with
As I said in my previous mail... there are many ways to do this fairly
easily in linux. To directly answer your last question, yes, it does.
Some of the options for switching depend on your desktop environment, if
you are using one, but it can be as simple as different launchers for
running axis
My vote would be for QT5 and trying to write for python 2 AND 3
compatibility of the code. Of course I'm not the one writing it though.
My personal opinion is that LinuxCNC builds for wheezy need to be
relegated to bug fixes and such and all new features 'officially'
supported on only newer OS
15 matches
Mail list logo
