> On 10/27/2016 12:38 PM, Nicklas Karlsson wrote:
> >>> That component calculates its own "personality" parameter from a config
> >>> string.
> >> Good point, Andy - the pins available can depend on comp load-time
> >> arguments.
> > Yes pins available can depend on comp load-time but can the conf
Yes I know about the python tools, scheme is however used for other gschem
backends. If python works I can't see any reason to change.
> Nicklas, there are python tools that communicate with Gschem.
>
> I didnt want to look into Scheme, also did not try these.
> just fyi
>
> http://robertobuche
Nicklas, there are python tools that communicate with Gschem.
I didnt want to look into Scheme, also did not try these.
just fyi
http://robertobucher.dti.supsi.ch/files/2014/06/DescPython.pdf
some gEda shape creation in python
https://xgoat.com/wp/tag/python/
hth
tomp tjtr33
On 10/27/2016 12:38 PM, Nicklas Karlsson wrote:
>>> That component calculates its own "personality" parameter from a config
>>> string.
>> Good point, Andy - the pins available can depend on comp load-time
>> arguments.
> Yes pins available can depend on comp load-time but can the configuration?
>
On 10/27/2016 05:23 PM, Jim Craig wrote:
> I am trying to get Crapaholic to run. I have found the first issue and
> was able to get it to run and "show" the running hal confguration. There
> are some pretty major bugs as things have changed somewhat over the last
> 11 years. Is there a good python
I am trying to get Crapaholic to run. I have found the first issue and
was able to get it to run and "show" the running hal confguration. There
are some pretty major bugs as things have changed somewhat over the last
11 years. Is there a good python debugger that you all recommend. I
would like
Stewart,
That's one area, Iam interested is,as my cam program which is on Windows does
all the tooldatabase, as a server under access, so either bringing that across
to a Linux server, is one idea I have, and having the ability to extend this
into lcnc, as a sqlserver app may be good.
Sen
Ahhh... got it. From the discussion I though that this would be an
internal change. As an aux app I have much fewer objections as a LCNC
upgrade would not effect the basic operation.
On Oct 27 2016 11:37 AM, Sarah Armstrong wrote:
> sorry if i was not explicit , but i would keep gcode as is ,
On Oct 27 2016 11:44 AM, andy pugh wrote:
> On 27 October 2016 at 18:18, EBo wrote:
>> I'm just waiting at this point to see people prototype something
>> so we can look at it.
>
> Then I can only assume that you haven't been paying attention for the
> last 3 years.
sigh...
If someone implemente
Heh,
When common questions are:
Does LinuxCNC have cutter comp?
Does LinuxCNC have tool length offsets?
Does LinuxCNC have work piece offsets?
Does LinuxCNC have tap cycles?
Does LinuxCNC handle a tool changer?
etc!
Having the ability to handle the tool magazine and tool changing carousels
would b
On 27 October 2016 at 18:52, James Waples wrote:
> It seems all the projects linked to in this thread are quite stale unless
> I'm missing something.
No, you aren't missing anything. I made a branch, three years ago,
with (many of) the changes needed to use a database as the tooltable
and nobody
Sarah – That makes a lot more sense. I started panicking at the idea of
throwing gcode at a binary blob database hole.
> Then I can only assume that you haven't been paying attention for the last
3 years.
It seems all the projects linked to in this thread are quite stale unless
I'm missing someth
On 27 October 2016 at 18:18, EBo wrote:
> I'm just waiting at this point to see people prototype something
> so we can look at it.
Then I can only assume that you haven't been paying attention for the
last 3 years.
--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed
> > That component calculates its own "personality" parameter from a config
> > string.
>
> Good point, Andy - the pins available can depend on comp load-time
> arguments.
Yes pins available can depend on comp load-time but can the configuration?
Ordinary text file configuration do not depend
sorry if i was not explicit , but i would keep gcode as is , however
holding the gcode filename in the database as an entry to tie it all
together
having this as an additional to lcnc , but having say a list of colum names
that are used by lcnc
internaly , and say the database name held in the ini
I agree about the complexity part. The one issue that does make sense
to keeping it in a data store is that if someone moves the g-code to
clean up the dirs, then everything breaks. Other than that I think a
full on relational database would be more problems than it is worth. I
will not mind
OK. I like where your head is going, but are you willing to maintain
it in the long term? Also, how much of this functionality would be
embedded into the critical code path (that everything uses), and how
much of it would be addon applications which are nice to have but LCNC
still works if th
I would say that this is all doable, but I thought that tieing code to
fixtures was out of scope for the tool table (which I thought was the
scope of the discussion). That said, having the ability to scan a tool
and tracking it by barcode, RFID, imprinted magnetic strip/dots, would
be very use
What's wrong with a filesystem for gcode? There's already a pretty good
implementation distributed with the OS that LinuxCNC runs on ;).
Additionally, having an SQLite DB of gcode programs is overly complex and
makes getting gcode onto my control over a network share impossible. There
will likely b
i'd second that too John ,
having lcnc opened up to incorporate mysql for example , and openly
accessable formating
for the database , would go a long way , i think to a number of additional
variations , or even temporary read / write
perhaps a M code for auto run gcode once loaded , and any setup
I'd like to see the database of G code get selected by reading a bar
code on the part/fixture/etc. Read the bar code load the correct program
and when some input says go run the program.
JT
On 10/27/2016 11:44 AM, Sarah Armstrong wrote:
> i for one would like to see lcnc expanded to be able to
i for one would like to see lcnc expanded to be able to use a relational
database for a number of reasons
one for tooling and one for actual gcode, or combination of the two , where
say a schema layout txt file would essentially be pointed to from your ini
this could then relate a gcode database of
This popped up in the user IRC today
3 tool stores and two spindles. https://www.youtube.com/watch?v=IxBiWPZmcZI
Also I have been entering my gear cutters and hobs into a database for
a while, I have not yet put all columns needed for for some of the
workarounds I am thinking of
http://www.archiv
Realistically the "we can accomodate *this* much" is more of a design
limit. It is good to know for practical purposes, but not so important
from day to day. That said if I were working on it I would also make
sure that the tool table could be read out-of-core -- meaning that there
is some mo
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
On 10/27/2016 12:52 AM, andy pugh wrote:
> On 27 October 2016 at 04:08, Chris Radek wrote:
>> On Thu, Oct 27, 2016 at 12:00:16AM +0100, andy pugh wrote:
>>>
>>> And I think that there was at least one more that I haven't found.
>>
>> was it http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Halitosis
>
> No
James,
No biggy. I have tripped over my own tongue/fingers here as well.
Actually knocking up a demo would be nice from a working discussion. I
would say for speed and efficiency a couple of IPython notebooks with
exemplars would go a long way.
Also, my comment on Rust and maintenance was t
On Thursday 27 October 2016 09:01:00 James Waples wrote:
> EBo,
>
> You're right, in hindsight that wasn't a very well thought out
> statement. What I meant was to discuss what a minimal reimplementation
> would look like and doing that relatively quickly, as opposed to
> nailing down the entire d
On 10/26/2016 7:42 PM, Chris Morley wrote:
> Hello Jim.
>
>
> Linuxcnc has two gui menu based configuration programs,
>
> stepconf and pncconf. Do they not fit what you are trying to accomplish?
>
>
> IMHO helping maintain and expand these programs is better for the community,
> then dividing time
On 10/27/2016 8:43 AM, Sebastian Kuzminsky wrote:
> On 10/27/2016 02:47 AM, andy pugh wrote:
>> On 27 October 2016 at 01:59, Jeff Epler wrote:
>>> I'm totally open to 'comp' gaining a new output format that describes the
>>> component. that beats parsing manpage markup by a factor of about a
>>>
On 10/27/2016 02:47 AM, andy pugh wrote:
> On 27 October 2016 at 01:59, Jeff Epler wrote:
>> I'm totally open to 'comp' gaining a new output format that describes the
>> component. that beats parsing manpage markup by a factor of about a billion.
>> but somebody needs to design that format and im
On Oct 26 2016 9:40 AM, andy pugh wrote:
> On 26 October 2016 at 16:07, EBo wrote:
>>> This is NOT 1980. Memory (at this level) is free.
>
> Indeed. It is hard to imagine needing more than 5kB per tool.
The 1980 quote was not mine (the clip makes it appeare to attribute
that to me, but no offenc
EBo,
You're right, in hindsight that wasn't a very well thought out statement.
What I meant was to discuss what a minimal reimplementation would look like
and doing that relatively quickly, as opposed to nailing down the entire
desired feature set with a much longer discussion period.
This is a c
James,
You state: "Everyone could talk about things forever without anything
being implemented. As long as the right decisions are made..." What is
happening now is hashing out what people care to see. Other than that,
we are discussing what we foresee as potential issues with the approach
On 2015-02-22 20:59, John Thornton wrote:
> Calling things stupid and trying to intimidate the developers with
> kindergarten insults usually is not very productive in an open source
I'm not a nativ English speaker, and as I know neither is Norbert, hence maybe
I am missing the obscure intimidat
On 27 October 2016 at 01:59, Jeff Epler wrote:
> I'm totally open to 'comp' gaining a new output format that describes the
> component. that beats parsing manpage markup by a factor of about a billion.
> but somebody needs to design that format and implement it in comp.
It's also likely to be ra
On 27 October 2016 at 05:28, Jon Elson wrote:
> I now use Glade for building GUIs and attach that to c
> programs to do the dirty work.
> Vastly more understandable and maintainable
I am not so sure about that. I have recently had absolutely no replies
to queries on GTK IRC channels.
And, also, a
On 27 October 2016 at 04:08, Chris Radek wrote:
> On Thu, Oct 27, 2016 at 12:00:16AM +0100, andy pugh wrote:
>>
>> And I think that there was at least one more that I haven't found.
>
> was it http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Halitosis
No, I had forgotten that one. There is another that u
38 matches
Mail list logo
