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 rel
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, I
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 the
it can 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 t
er 2016 at 14:20, dragon 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.
>
> Interesting, I
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 a
Just wanted to share a BIG thanks to everyone who contributed!
-Todd
On 11/04/2016 10:46 PM, Sebastian Kuzminsky wrote:
> LinuxCNC 2.6.13 has been released.
>
> This release fixes a couple of bugs in the G-code interpreter, increases
> the number of supported stepgens to 16, and has numerous min
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 schema,
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 f
Thanks for checking...
On 11/01/2016 11:50 AM, andy pugh wrote:
> On 1 November 2016 at 16:13, dragon wrote:
>> Do you remember who you worked with at Tormach?
>
> Actually, looking back, it was someone at zbot that Tormach put me in
> touch with.
>
signature.asc
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 w
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 fa
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 t
Good point... I didn't even think of storing a mesh, wireframe, or SVG
of the tool profile in the DB.
I started playing with the path feature of the latest FreeCAD last
night. This morning I started to wonder what all of the different CAM
programs expect for reading in tool tables and if LinunCNC
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, o
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 the
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 w
Translation files are relatively easy to create and do not need to be
compiled with the rest of the linuxCNC stack. What does need to be
compiled in is support in the source code and in some cases, compiler flags.
Qt and python for sure, and I think Glade, all have translation (locale)
support.
C
18 matches
Mail list logo
