The problem with file I/O is you end up with flat files that do not describe the relationships between various entities in the system. I might add that any good programmer should also take the time to learn how to study a system, define the entities and create the relational data structures that define the entities. I get really pissed when I see people try to put relational data in a single CSV file because thats all they understand.
SQLlite is easy to implement in Python but the mind shudders about designing the User Interfaces to manage the data entry Andy proposed. I used to use development environments that built that for you. Once its in SQL, if you want flat files, there is a thing called a view... And Andy, if this ever gets legs, please make sure every table has a unique auto incrementing master key. Never use an Alphanumeric key for this. Every time I did that to save time, I ended up redoing it. But maybe you have learnt that now since 2013! But really, this conversation should be deferred until after 2.8 is released. Rod Webster *1300 896 832* +61 435 765 611 VMN® www.vmn.com.au On Wed, 8 Apr 2020 at 22:15, Reinhard <[email protected]> wrote: > Hi, > > On Mittwoch, 8. April 2020, 12:11:15 CEST andy pugh wrote: > > But, if we remove the current slot-memory from LinuxCNC, then every > > tool changer has to be an advanced tool changer. > > Here I disagree. For me, any person who wants to do software development > should know how to do file io. That's nothing advanced. > Current tooltable of linuxcnc (as all other persistence too) is filebased. > There's nothing wrong with it! > > Database is not a must have for cnc-controllers. Not at all! > A toolmanager would be easier to implement with database backend then with > file > io, ... > > You may object, that there's no difference whether atc does fileio or > whether it > uses a file from linuxcnc. > > What you think about this: is a stolen good the same than a gift? > In each case - one person has something that was owned by another before > ... > But I'm quite confident, that no human would consider these as equal. > So why is "robbery" in IT-world ok? > linuxcnc has its private properties, as well as any atc. Working together > should happen through a public interface (like nml or hal pins), not by > whitebox pattern. > > On Mittwoch, 8. April 2020, 12:20:37 CEST andy pugh wrote: > > Many years ago, and working with Tormach, we came up with a powerful > > database schema for a LinuxCNC tool catalogue. > > Amongst other things it supported a shared tool table for all machines > > in the factory (or, indeed, the World) with pre-configured carousel > > layouts and all sorts of other things. (and, being a database, users > > can add fields without breaking the built-in queries) > > http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ToolDatabase > > Yes, you gave me the link some time ago, but I created a new database > scheme. > For my opinion too many properties of different modules had been mixed in > same > tables. Not the way I think. > > On Mittwoch, 8. April 2020, 12:20:37 CEST andy pugh wrote: > > To make use of a database, though, the tool data has to be removed > > from motion / NML. All that needs (as far as I can tell, please tell > > me if I am wrong) is the data for the current tool > > Agree. > > > Reinhard > > > > > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers > _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
