I think a file format that's a bit more structured than plaintext might be
a good idea, especially if there is potentially a lot more information that
can be associated with a tool, as well as being able to define tool types
etc. Is there a need or desire for a pluggable storage backend? Something
flexible enough to support reading from SQLite, a remote Postgres database,
JSON or binary blobs etc. The data structures required by LinuxCNC are
likely to be quite rigid, so perhaps we just need to make the right choice
of storage backend and live with it.
Whatever *storage* solution is found, I'm very much in favour of the
*interface* it being a pluggable, standalone library. Something that
LinuxCNC integration has as a primary goal, but also something where
interfacing with it through e.g. Rust bindings or a Python script is still
a reasonable possibility.
On Wed, 26 Oct 2016 at 13:29 TJoseph Powderly <tjt...@gmail.com> wrote:
> (best read with fixed width font ;-)
>
> Tool Number Limit
> or
> Limitations of Tool Tables?
>
> The limitation might be the structure ( as in C ) , not the number of
> entries.
>
> thinking that tool diameter, length, rpm, feed, stepover, plunge
> increment might suffice
> ignores the power level, pulse width for a laser,
> and the ontime offtime gapvoltage overburn safetymargin for edm
> and force and dwell for polishing machines
>
> many processess are stepwise ( one tool at a time ,sometimes rough,
> semi-rough, finish)
> but the attributes of some tools just aint accommodated
>
> so
> why not just associate an tool with an index into a technology?
> and the tech stored in simple ascii flat files.
>
> maybe:
> the file format could be up to the integrator
> and the communication of stored data TO the devices up to him also
>
> i did similar using custom mcodes that read a flat data file for sink edm
> and just sidestepped the linuxcnc tool tables
>
> the M codes were passed the 2 parms,
> the name of the technology file and the index into it
>
> the tech file was identified by a number, was suited to the tool and
> work materials
> (this is edm, odd, but maybe a mindset jogger and therefore good )
>
> the index was one of several settings in that tech,and was unique for a
> tool
> eg: undersize/overburn gapvalue ontime offtime safety margin and more
>
> in this way 2 parameters could specify many tool informations
>
> the 'g-code' looked like
> 'M122 P[techfilenumber] Q[indexOrPowerLevel]'
>
> this command would read the file, parse the data, and could assign the
> data to devices
>
> data base file example:
> each row is just a list of data for one tool
> each subsequent row is a diminished power setting
> ( like upping the rpm & reducing the cut depth on a end mills
> finishing pass )
>
> the title line is ignored, the column header is ignored, the end
> footer is ignored
> ( those lines are just for hu-mans )
>
> NR is the index, higher NR is higher power, lower is ... lower power
> ----------------------------flat file begin-------------------------------
> BEGIN 99999932.E MM
> NR IP HV GV ON OFF SV AJD ET AR P NA VE RA VW RAD STPA
> CODE BXGV ISO XJMP AUX5 AUX6
> 25 18 0 45 16 8 9 3.6 1.4 75 0 10 0 0 0 2.692 0 0
> 35 0 1 0 0
> 24 16 0 50 12 6 9 3.6 1.4 70 0 10 0 0 0 0.02 1.143 0
> 35 0 1 0 0
> 23 16 0 50 6 4 9 3.6 2 70 0 10 0 0 0 0.048 0.762 0
> 40 0 1 0 0
> 22 16 0 50 3 3 9 3.6 3 70 0 10 0 0 0 0.069 0.508 0
> 45 0 0 0 0
> 21 8 0 60 2 3 9 3.6 3 70 0 10 0 0 0 0.099 0.381 0
> 45 0 0 0 0
> 20 8 0 55 1 3 9 3.6 3 65 0 10 0 0 0 0.112 0.254 0
> 45 0 0 0 0
> 19 5 0 55 1 3 9 3.6 3 65 0 10 0 0 0 0.117 0.203 0
> 45 0 0 0 0
> 18 3 0 55 1 3 9 3.6 3 65 0 10 0 0 0 0.122 0.127 0
> 45 0 0 0 0
> 17 2 0 55 1 3 9 3.6 3 65 0 10 0 0 0 0.127 0.076 0
> 45 0 0 0 0
> [END]
> ------------------eof-------------------------
>
> note the flat file structure is up to you!
> you can make it as wide as you like, and have strings!
> you only need to be able to USE the info by writing snippets of code
> SMOP heh heh heh
>
> an example how to read such a flat file with Mcode and python
> ( began on a system that only had numeric filenames, therefore weird to
> most people )
> ( tho this 'limitation' becomes an advantage to a control that has no
> strings ;-)
>
> ------------M122 reads file (with numeric name) and index into that file
> -----------------
> !/usr/bin/python
> # M122, test reading EtabUNS given M122 P999999xx Qnn
> # simply prints the CorrectUNS ( etab RAD value -2.54 for mm etabs)
> # RAD is 15th element on 2nd line ( 16th elem on 3rd line for humans but
> what do we know )
> # fyi the NR is is (26 - ndx) !!
> #
>
> import sys, subprocess
>
> ncfileprefix="/home/tomp/Desktop/ETABS/406ETABS/"
>
> ns=(sys.argv)[1]
> print ">",ns,"<"
> nf=float(ns)
> etabnum=int(nf)
> etabname=ncfileprefix+(str(etabnum))+(".ENC")
> #print "debug etabname "+etabname
>
> ns=(sys.argv)[2]
> nf=float(ns)
> ni=int(nf)
> # if i said m122 P99999932 Q25, i'd want the 1st data line which is 2,
> so 25becomes2 n=27-input?
> EtabLNum=27-ni
> fhndl=open(etabname, 'r')
> #print fhndl
> econds=fhndl.readlines()
> fhndl.close()
> #print fhndl
> #print econds
> # fields in etab file NR IP HV GV ON OFF SV AJD ET AR P
> NA VE RA VW RAD STPA CODE BXGV ISO XJMP AUX5 AUX6
> # fields used on 1st gladevcp NR IPk On Off Rad Pol TCut TJump
> # indices 0 1 4 5 15 10 7 8
> ns = str.split(econds[EtabLNum])[0]
> nf = float(ns)
> NR = int(nf)
>
> ns = str.split(econds[EtabLNum])[1]
> nf = float(ns)
> IPk = int(nf)
>
> ns = str.split(econds[EtabLNum])[4]
> nf = float(ns)
> nf = nf * 4
> OnT = int(nf)
>
> ns = str.split(econds[EtabLNum])[5]
> nf = float(ns)
> nf = nf * 4
> OfT = int(nf)
>
> ns = str.split(econds[EtabLNum])[15]
> Rad = float(ns)
>
> ns = str.split(econds[EtabLNum])[10]
> nf = float(ns)
> Pol = int(nf)
>
> ns = str.split(econds[EtabLNum])[7]
> TCut = float(ns)
> -------eof---------------------------
>
> heres an example of how to use the retrieved data
>
> setting hardware oscillator up with on and off times in uSecs
> ---------------------M110 P[on] Q[off]---------------------------------
> #!/bin/bash
>
> # M110 sets ontime and offtime
> # you supply u32 ints for number of uSecs HAH! aint no ints in bash,
> only strings afaict
>
>
> # from dgarr f=123.456; echo ${f%%.*}
>
> #f=$1
> #echo ${f%%.*}
>
> halcmd sets onval ${1%%.*}
> halcmd sets offval ${2%%.*}
>
> #halcmd sets offval $2
>
> exit 0
>
> --------------------------------eof---------------------------------------------
>
>
> oh yeah, a pyvcp qtvcp galdevcp display can show you info
> even let you pick settings, all outside the limits of the linuxcnc table
> framework
>
> outside of mainstream linuxcnc aint neccesarily good,
> but i just solve problems for myself ( limited scope )
>
> these files are _extremely_ unique for my own use
> not likely to be useful except as a crazy model
> or, use them if you like '-)
>
> video of use
> M1xxReadDB-WriteHalPins.ogv at Videobin
>
> https://videobin.org/+ejk/ic0.html
>
> (beware videobin renames the file to .ogg tho its really a .ogv so
> rename as needed if you grab it )
>
> ok, so there's ways to work around without changing anything inside
> linuxcnc
>
> regards
> tomp tjtr33
>
>
>
> On 10/26/16 15:47, Sarah Armstrong wrote:
> > James,
> > Following your conversations with interest, I would like to have a
> situation where any database could be used, for instance merging in say a
> Microsoft access database, via a server, that way I could link in to my cam
> tool database.
> > From camworks.
> >
> > So for me some scriptable interface would be ideal, although I see say a
> tool database and a tool wear database being 2 separate databases, relation
> linked etc.
> >
> >
> >
> >
> >
> > Sent from BlueMail
> >
> >
> >
> > On 26 Oct 2016, 09:34, at 09:34, James Waples<jamwaff...@gmail.com>
> wrote:
> >> Machines with more than 56 tools are becoming a lot more common so
> >> removing
> >> this arbitrary limit would be quite important to a lot of people. From
> >> a
> >> personal standpoint, I would like to be able to group my tools by
> >> number
> >> (0-99 for endmills, 100-199 for drills, etc). I tried this once before
> >> but
> >> was surprised by an error when I tried adding tool T100. Sounds like
> >> there's some technical debt that would be good to clean up.
> >>
> >> On Tue, 25 Oct 2016 at 21:35 EBo<e...@sandien.com> wrote:
> >>
> >>> On Oct 25 2016 9:03 AM, andy pugh wrote:
> >>>> On 25 October 2016 at 15:25, EBo<e...@sandien.com> wrote:
> >>>>> That said, what is the most maintainable long term
> >>>>> solution?
> >>>> Change nothing....
> >>> Then why did the subject come up in the first place? Isn't there
> >> bugs
> >>> that is causing issues and problems are arising?
> >>>
> >>> EBo --
> >>>
> >>>
> >>>
> >>>
> >>
> ------------------------------------------------------------------------------
> >>> The Command Line: Reinvented for Modern Developers
> >>> Did the resurgence of CLI tooling catch you by surprise?
> >>> Reconnect with the command line and become more productive.
> >>> Learn the new .NET and ASP.NET CLI. Get your free copy!
> >>> http://sdm.link/telerik
> >>> _______________________________________________
> >>> Emc-developers mailing list
> >>> Emc-developers@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/emc-developers
> >>>
> >>
> ------------------------------------------------------------------------------
> >> The Command Line: Reinvented for Modern Developers
> >> Did the resurgence of CLI tooling catch you by surprise?
> >> Reconnect with the command line and become more productive.
> >> Learn the new .NET and ASP.NET CLI. Get your free copy!
> >> http://sdm.link/telerik
> >> _______________________________________________
> >> Emc-developers mailing list
> >> Emc-developers@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
> ------------------------------------------------------------------------------
> > The Command Line: Reinvented for Modern Developers
> > Did the resurgence of CLI tooling catch you by surprise?
> > Reconnect with the command line and become more productive.
> > Learn the new .NET and ASP.NET CLI. Get your free copy!
> > http://sdm.link/telerik
> > _______________________________________________
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>
>
> ------------------------------------------------------------------------------
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> _______________________________________________
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
