#linuxcnc-devel Logs

Feb 21 2018

01:32 AM linuxcnc-build: build #5371 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/5371 blamelist: Sebastian Kuzminsky <seb@highlab.com>
01:34 AM linuxcnc-build: build #5369 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/5369 blamelist: Sebastian Kuzminsky <seb@highlab.com>
01:35 AM linuxcnc-build: build #5368 of 1300.rip-precise-i386 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/5368 blamelist: Sebastian Kuzminsky <seb@highlab.com>
01:36 AM linuxcnc-build: build #3529 of 1400.rip-wheezy-i386 is complete: Failure [4failed runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/3529 blamelist: Sebastian Kuzminsky <seb@highlab.com>
01:37 AM linuxcnc-build: build #5369 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/5369 blamelist: Sebastian Kuzminsky <seb@highlab.com>
01:37 AM linuxcnc-build: build #3530 of 1403.rip-wheezy-amd64 is complete: Failure [4failed runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/3530 blamelist: Sebastian Kuzminsky <seb@highlab.com>
01:39 AM linuxcnc-build: build #3731 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/3731 blamelist: Sebastian Kuzminsky <seb@highlab.com>
01:39 AM linuxcnc-build: build #3045 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/3045 blamelist: Sebastian Kuzminsky <seb@highlab.com>
01:39 AM linuxcnc-build: build #4582 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/4582 blamelist: Sebastian Kuzminsky <seb@highlab.com>
01:40 AM linuxcnc-build: build #1996 of 1500.rip-jessie-i386 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/1996 blamelist: Sebastian Kuzminsky <seb@highlab.com>
01:41 AM linuxcnc-build: build #1998 of 1520.rip-jessie-amd64 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1520.rip-jessie-amd64/builds/1998 blamelist: Sebastian Kuzminsky <seb@highlab.com>
01:41 AM linuxcnc-build: build #1998 of 1530.rip-jessie-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1530.rip-jessie-rtpreempt-amd64/builds/1998 blamelist: Sebastian Kuzminsky <seb@highlab.com>
01:41 AM linuxcnc-build: build #1996 of 1510.rip-jessie-rtpreempt-i386 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1510.rip-jessie-rtpreempt-i386/builds/1996 blamelist: Sebastian Kuzminsky <seb@highlab.com>
01:42 AM linuxcnc-build: build #3197 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/3197 blamelist: Sebastian Kuzminsky <seb@highlab.com>
01:47 AM linuxcnc-build: build #384 of 1630.rip-stretch-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1630.rip-stretch-rtpreempt-amd64/builds/384 blamelist: Sebastian Kuzminsky <seb@highlab.com>
01:49 AM linuxcnc-build: build #385 of 1610.rip-stretch-rtpreempt-i386 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1610.rip-stretch-rtpreempt-i386/builds/385 blamelist: Sebastian Kuzminsky <seb@highlab.com>
01:51 AM linuxcnc-build: build #5382 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/5382 blamelist: Sebastian Kuzminsky <seb@highlab.com>
02:01 AM linuxcnc-build: build #3541 of 1405.rip-wheezy-armhf is complete: Failure [4failed runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/3541 blamelist: Sebastian Kuzminsky <seb@highlab.com>
02:10 AM linuxcnc-build: build #575 of 1540.rip-jessie-armhf is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1540.rip-jessie-armhf/builds/575 blamelist: Sebastian Kuzminsky <seb@highlab.com>
02:10 AM linuxcnc-build: build #5390 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/5390 blamelist: Sebastian Kuzminsky <seb@highlab.com>
07:40 AM jepler: yay I officially wrote the worst python code ever
07:46 AM skunkworks: heh - Yay?
07:48 AM skunkworks: You do know that I have written some python too - I think even your worse code is better than my attemps
07:53 AM jepler: just reacting to a comment on a github issue.
07:53 AM jepler: > FWIW, I'm rewriting axis.py for work things. Primarily, I'm doing cleanup (holy cow it's the worst python I've ever worked on),
08:04 AM skunkworks: aww - I hate people
09:37 AM seb_kuzminsky: that's rude :-(
09:38 AM cradek: when someone says "this is the worst code I've ever seen" I just laugh and think they must be really inexperienced
09:38 AM seb_kuzminsky: heh
09:39 AM seb_kuzminsky: "oh, my sweet summer child"
09:45 AM jepler: It looks like fake-name has written a fair amount of code; his github activity chart sure has more on it than me.
09:45 AM jepler: and, y'know, the organization of code ain't great...
09:45 AM jepler: I tried to stop bristling about it when I replied on that issue
09:50 AM seb_kuzminsky: your reply was super civil i thought
09:52 AM seb_kuzminsky: cradek: you have a random toolchanger on Jr, right? do you have feelings about https://github.com/LinuxCNC/linuxcnc/issues/330
09:55 AM cradek: yeah it has one
09:55 AM jepler: seb_kuzminsky: thanks for the double check
09:55 AM cradek: I have never had a problem but if your tests say there's a bug then there's a bug
09:56 AM cradek: I don't think I ever really try to use prefetch
09:56 AM seb_kuzminsky: yeah it's that kind of bug where if the user does something something goofy they can get it to mess up
09:56 AM cradek: oh prefetch + abort at the right time is needed? yuck.
09:57 AM seb_kuzminsky: prefetch & abort can do it, or funny gcode
09:57 AM seb_kuzminsky: TxM6 Ty TxM6 loads Ty, not Tx
09:57 AM cradek: my gcode is almost all hand-written and simple
09:58 AM seb_kuzminsky: sure
09:58 AM seb_kuzminsky: it's like that cutter comp bug you made fun of me for, where you enable cutter comp and then disable it without moving :-)
09:59 AM seb_kuzminsky: there's code in IO specifically to not prepare the tool in the spindle, leaving the previous tool prepared
09:59 AM seb_kuzminsky: i think it just forgets to update the prep pins in that case
10:12 AM skunkworks: did he just arguably agree with you?
10:12 AM skunkworks: never mind
10:28 AM jepler: what is happening
10:33 AM seb_kuzminsky: maybe he's editing his comment? github doesn't make that real clear
10:38 AM rene-dev: yes, thats editing
10:40 AM seb_kuzminsky: hi rene-dev
10:40 AM rene-dev: hi
10:41 AM seb_kuzminsky: are you seeing the "loading from the incorrect pocket" bug that gmoccapy/norbert is describing in his big comment? i can't reproduce that one
10:44 AM rene-dev: I never tried... Im looking into how to get rid of the tool limit. be it with sql, or with a dynamic data type.
10:45 AM seb_kuzminsky: ah ok
10:45 AM rene-dev: http://www.cplusplus.com/reference/map/map/ would do the job. also fixes the problem with the index number.
10:45 AM seb_kuzminsky: you mean the limit on at most 56 pockets?
10:45 AM rene-dev: yes
10:46 AM seb_kuzminsky: switching from a statically allocated array of tools to a map of tools will be pretty tricky i think
10:46 AM seb_kuzminsky: the array is currently in NML shared memory, used by both io and task/interp
10:46 AM seb_kuzminsky: so you'd have to come up with some way to share the map
10:46 AM seb_kuzminsky: or synchronize different copies of it
10:46 AM seb_kuzminsky: or something, i'm not sure
10:47 AM rene-dev: it only needs to be there so that io and task can access it?
10:47 AM seb_kuzminsky: i think so, yeah
10:47 AM seb_kuzminsky: well, and the GUIs, so they can do things like show the tool's diameter in the backplot
10:48 AM rene-dev: current tool is not the issue, you can have the current tool there
10:48 AM rene-dev: well, that issue would solve itself with sqlite. both could just access the database individually
10:48 AM seb_kuzminsky: sure
10:49 AM jepler: It is unfortunate that UIs can't currently access the whole tool table via NML; that forces workarounds like programs that read, parse, and fully rewrite the tool table file just to change one number.
10:50 AM seb_kuzminsky: so you'd not have an "internal" tool table at all, it would live only in the database? and you'd query the database anytime you wanted to know about tools? (other than the tool in the spindle, i guess)
10:50 AM seb_kuzminsky: jepler: you mean for things like tool length touch-off? isn't that via gcode?
10:50 AM rene-dev: yes
10:50 AM jepler: seb_kuzminsky: no, I mean the tool table editor
10:50 AM rene-dev: you only need to query it on a toolchange
10:50 AM jepler: the thing that looks like a spreadsheet
10:51 AM seb_kuzminsky: ah ok
10:51 AM rene-dev: the editor could also just access the db directly. much easier
10:51 AM rene-dev: im not even sure iocontrol needs the whole table...
10:51 AM rene-dev: it does sometimes, ok
10:52 AM seb_kuzminsky: i think we're talking about at least three things here:
10:52 AM seb_kuzminsky: 1. how the tools are stored on disk (text file vs database)
10:52 AM seb_kuzminsky: 2. how linuxcnc thinks about tools (toolno/pocket/index, nml shm, etc)
10:52 AM seb_kuzminsky: 3. bugs in the current implementation
10:53 AM seb_kuzminsky: i'm mostly thinking about 3 at the moment
10:53 AM rene-dev: yes, 1. came up when I looked into 2 and 3
10:53 AM seb_kuzminsky: i think rene-dev is thinking about 1
10:53 AM rene-dev: I was looking for the bug, and saw all the confusion...
10:53 AM seb_kuzminsky: there's sure a lot of confusion currently
10:53 AM rene-dev: also, I really dont like the idea that there are multiple pograms have the file open and mess around in it. how did that never couse a problem?
10:54 AM jepler: rene-dev: it absolutely causes problems.
10:54 AM rene-dev: so +1 for sqlite, it is designed to handle that. it also uses transactions, so its always consistent, even in a crash
10:55 AM rene-dev: this doesnt work if the tooltable is stored on a nfs volume, or when you are using Windows 95. I think we can rule that out.
10:55 AM seb_kuzminsky: changing/fixing 1 & 2 would begin, i think, but pulling all the code that accesses the tool table into a library, and hiding the implementation behind an API
10:56 AM rene-dev: yes, I started doing that. I now have a version of linuxcnc which doesnt have a tooltable :D
10:56 AM seb_kuzminsky: that API would tell us how & where linuxcnc actually uses the tool information
10:56 AM seb_kuzminsky: rene-dev: cool
10:56 AM seb_kuzminsky: does it still pass all the tests?
10:58 AM rene-dev: I never tried, now I know where the tooltable is acually used, and Im starting to put stuff back in.
10:59 AM rene-dev: but probably not, because you cant load a tool, as it doesnt load the tooltable.
11:00 AM rene-dev: seb_kuzminsky regarding the IOcontrol... how about removing everything toolchange related form IOcontrol, and put it in a remap?
11:00 AM rene-dev: would that not be much easier?
11:00 AM jepler: afk
11:00 AM seb_kuzminsky: rene-dev: i think remap is more broken than tool handling unfortunately
11:00 AM seb_kuzminsky: seeya jepler
11:01 AM rene-dev: is it?
11:01 AM seb_kuzminsky: rene-dev: i would welcome a careful cleanup of tool handling in master
11:01 AM seb_kuzminsky: it's a complicated, confusing part of our code, as you've noted
11:01 AM rene-dev: ok, good.
11:01 AM seb_kuzminsky: and it's super important to get it all right
11:01 AM rene-dev: whats broken about remaps?
11:02 AM seb_kuzminsky: i think the common code paths in tool handling all work, most of the time, though obviously there are still bugs in some corner cases (like #330)
11:02 AM rene-dev: because I use them on the toolchangers I programmed. and the iocontrol pins are just looped. so I was wondering why not just alwasy have a default remap, that pepole could then modify.
11:02 AM seb_kuzminsky: if we break tool handling, we break everyone's machines, and i don't want that
11:03 AM rene-dev: yeah
11:03 AM seb_kuzminsky: so any change here has to be very carefully done, and well tested
11:03 AM seb_kuzminsky: ok cool
11:03 AM seb_kuzminsky: i think the core functionality should be implemented inside linuxcnc, not as external remaps
11:03 AM rene-dev: beacuse that is how many other controls do it. you just have a m6 macro that is called, that does stuff.
11:04 AM seb_kuzminsky: that's how our Tx and M6 work too, we just implement it in HAL
11:04 AM rene-dev: so whats the core functionality? with no toolchanger, there is not much to do.
11:04 AM rene-dev: yes, but you cant move axis in hal. many toolchangers require that.
11:04 AM rene-dev: usually its go somewhere, fiddle with ios, go somewhere else.
11:05 AM seb_kuzminsky: we have a tool change location, task moves the machine there before fiddling with the tool prep/change pins
11:05 AM rene-dev: that might be ok for a lathe.
11:05 AM seb_kuzminsky: i think that's pretty standard, it's simple, and it works well on lathes and mills afaik
11:06 AM seb_kuzminsky: do you have a machine where that's not sufficient?
11:06 AM rene-dev: but rack, or umbella changers require more. almost all mills require more, to get the tool out. unless you have an arm, that does everything
11:06 AM seb_kuzminsky: yeah, the rack toolchanger i see
11:06 AM rene-dev: also umbrella
11:07 AM seb_kuzminsky: how does an umbrella work?
11:07 AM skunkworks: linuxcnc didn't handle that well until the remap changes.
11:08 AM skunkworks: Our umbrella moves the umbrella. - others require the Z axis to move
11:08 AM skunkworks: Like a tormach tool changer. (requires the z to move to change the tool)
11:08 AM rene-dev: https://www.youtube.com/watch?v=x06AFeAUCHs
11:08 AM seb_kuzminsky: i see, you move the umbrella to expose an empty pocket, move the spindle there and drop the tool, move the spindle out of the way, move the umbrella to expose the new tool, move the spindle there, and pick the tool up
11:09 AM seb_kuzminsky: yeah, that's two good examples of where the current built-in toolchanger code isn't flexible enough
11:09 AM rene-dev: https://www.youtube.com/watch?v=VzKACmvuV7A
11:09 AM rene-dev: they also cant prepare
11:10 AM rene-dev: any those style are very common, especially on DIY machines, because they are so simple
11:10 AM seb_kuzminsky: "prepare" for an umbrella is a multi-step process: prepare the destination pocket, drop the tool, prepare the source pocket, pick up the tool
11:11 AM rene-dev: but there is nothing to prepare
11:11 AM seb_kuzminsky: there isn't?
11:11 AM rene-dev: because there is no arm
11:11 AM rene-dev: no
11:11 AM seb_kuzminsky: i agree there's no arm
11:11 AM rene-dev: you always have to drop the current tool in the empty pocket first
11:11 AM seb_kuzminsky: by prepare i meant, rotate the umbrella to expose the empty pocket where you want to drop off the tool currently in the spindle
11:12 AM rene-dev: ok, you yould just drop it on the table ;D
11:12 AM cradek: you just have to put the old tool back where you got it
11:12 AM seb_kuzminsky: ah, you're saying, that pocket is already exposed because that's where you got the current tool from
11:12 AM cradek: that hole is still right there
11:12 AM seb_kuzminsky: right
11:12 AM rene-dev: well, it will be left there, because you just picked it up
11:12 AM * seb_kuzminsky is slow
11:12 AM seb_kuzminsky: the prepare of the new pocket comes after the drop-off of the current tool
11:13 AM rene-dev: thats not a prepare, thats part of the toolchange, and thats always time you waste.
11:13 AM seb_kuzminsky: ok
11:13 AM rene-dev: you can only speed up by arranging your tools properly, or speeding up the rotation.
11:15 AM rene-dev: one one machine the carousel is set up as an axis
11:15 AM rene-dev: on the other its just IOs, the hardware does the indexing
11:15 AM mozmck: We have a Haas VF1 and it has an umbrella changer - I didn't know that what it was called until now though :-)
11:15 AM rene-dev: I dont know is thats a general or a haas term... thats what haas calls it.
11:17 AM seb_kuzminsky: i think we should call it a parasol
11:18 AM rene-dev: norbert has this style https://www.youtube.com/watch?v=YKlXBZ4IZn8
11:19 AM seb_kuzminsky: nice rack
11:19 AM jepler: phrasing
11:19 AM seb_kuzminsky: i wonder if there's a clean way to deal with umbrella and rack toolchangers without remap :-/
11:22 AM seb_kuzminsky: i've gotta run again, but thanks all for talking about this and educating me
11:22 AM seb_kuzminsky: more later
11:46 AM KimK: Some (larger?) machines are made so it's too hard to fill/empty the carousel directly, it's too far away, so you always fill/empty the carousel via the spindle (it comes to you). Tool chains are sometimes that way too, especially if they are elevated to an inconvenient height.
11:51 AM cradek: I load mine only in the spindle. load an empty pocket, push the drawbar release button and stick the tool in the spindle
11:51 AM cradek: I don't think I could push tools directly into the pockets without some leverage
11:51 AM cradek: also I would have to stand in the chip pan to do it
12:50 PM hazzy: From my little experience umbrella tool changers are by far the most common on the smaller high speed machines, especially the vertical variant like the Brothers and Fanucs have.
12:52 PM hazzy: Don't think you can get much more elegant (or fast) a tool changer layout as this: https://youtu.be/ZSqrjo8Mjtk
01:10 PM rene-dev: hazzy what do you use for tooledits in hazzy?
01:12 PM hazzy: rene-dev: In the GTK3 version there is a tool edit widget, in the GTK2 version there is a tool edit notebook tab, very much like the one in PathPilot
01:13 PM hazzy: https://raw.githubusercontent.com/KurtJacobson/hazzy/master/screenshots/Screenshot_3.png
01:13 PM rene-dev: ok, and you edit the toolfile directly?
01:14 PM hazzy: Yes, I rewrite the whole thing and reload it after an edit, which is not ideal, but the simplest way I could come up with
01:14 PM hazzy: I really like the idea of using an SQL database
01:15 PM rene-dev: ah, you already follow that :)
01:15 PM rene-dev: glad you like that
01:15 PM rene-dev: yes, im working on that.
01:16 PM hazzy: Great! I can't wait to see what you come up with, I know it will be good :)
01:17 PM rene-dev: norbert is changing the tooledit widget to use sql, I asked him to put the sql stuff in a seperate file, so you can reuse it
01:17 PM seb_kuzminsky: that sounds like a step in the right direction
01:17 PM rene-dev: how is gtk3 getting along?
01:17 PM hazzy: Thank you!
01:18 PM seb_kuzminsky: i haven't made my mind up yet if i like sqlite for the tool table storage, but i know that i like cleaning up the internal tool access to be behind a well-defined API
01:18 PM rene-dev: seb_kuzminsky the io seems easy, but im not sure where in task the best place is to open the file
01:18 PM hazzy: Gtk3 stuff it not coming along so well, there are so many little bugs it is discouraging :(
01:19 PM rene-dev: so far everyone likes it. and it solves a lot of problems at once, and allows for very easy additions in the gui, for custom entries
01:19 PM hazzy: One thing that would be nice it to be able to add custom entries to the tool table database, say torch voltage for plasma etc.
01:20 PM rene-dev: thats what I mean. and the interp only uses what it needs. and the gui adds whatever the user wants. thc voltage, tool color, tool order number, tool life, tool max rpm...
01:21 PM seb_kuzminsky: those fields, like tool max rpm, would be ignored by the motion control core? it'd be up to the gui to enforce them? that seems troubling to me
01:21 PM hazzy: Great! This will open up a lot of possibility for things like tool life management as well
01:22 PM rene-dev: max rpm was just an example. but its easy to extend it. you can add anything in gut/ hal logic, or maybe later even enforce stuff in the core.
01:22 PM rene-dev: it just opens up possibilities, because one thing doesnt affect the other.
01:22 PM seb_kuzminsky: sure, i get that was an example, and it's a good one
01:22 PM seb_kuzminsky: per-tool max rpm seems really useful
01:23 PM rene-dev: but max rpm and max feed sound like good ideas
01:23 PM seb_kuzminsky: my edge finder has a max speed much lower than i usually turn my endmills, it'd be nice if i didn't have to remember to set the S word every time i pick that tool
01:23 PM rene-dev: or tool life, where it adds the time the tool is feeding
01:23 PM seb_kuzminsky: but i'd much prefer all the useful stuff to be implemented in the motion control core, rather than in the guis
01:23 PM rene-dev: yes, I made the same experience. they are not balanced very well ;D
01:24 PM seb_kuzminsky: write it once, debug it once, get the benefits everywhere
01:24 PM rene-dev: im just saying it can be anywhere. you probably dont want specific stuff like thc voltage there.
01:24 PM seb_kuzminsky: yeah, there are probably some things that belong in the core and some ... not in the core
01:24 PM rene-dev: or you can have flags, like that a tool is big, and do the toolchange slower
01:26 PM Roguish_ is now known as Roguish
02:16 PM Roguish_ is now known as Roguish
02:33 PM KimK: rene-dev: Re: your comment "[flag]...that a tool is big and do the toolchange slower" comment: I have also seen controls that allow you to flag that a tool is big enough to overhang the two adjacent pockets so that they shouldn't be used.
02:35 PM rene-dev: KimK yes, yet another thing that is possible and useful
02:58 PM jepler: struggling with irritation at #403
02:58 PM jepler: so you're bitching about my code in public and keeping your improvements secret
03:02 PM rene-dev: jepler yeah, I was wondering about that. isnt he required to publish it?
03:03 PM Roguish: jepler: ya just can't make some whiners happy all the time.......
03:46 PM jepler: rene-dev: no, your GPL duty to distribute source code only kicks in when you've distributed a binary. Using a binary internally within a company/business is not distribution in anyone's common understanding of the GPL. (and something that was clarified in the GPL3 iirc) So it's not a license problem at all. It's just an emotional problem for me..
03:47 PM JT-Shop: interesting to read the history behind Axis
03:47 PM seb_kuzminsky: yeah, i didn't know that either
03:47 PM jepler: the bits about my day job and the gui builder? it's all a long time ago..
03:47 PM JT-Shop: yea the bits about the gui builder
03:49 PM jepler: It's a neat design: Tk is designed to be introspective, so you can do things like "list all widgets inside widget W" and "list all properties of widget X that differ from the defaults"
03:49 PM jepler: and so you can have a live screen and produce some Tcl code to build exactly that screen
03:49 PM jepler: so the GUI builder is mostly a program for producing a Tcl script in exactly this way
03:50 PM jepler: .. and so the tools to manipulate the screens can all be written in Tcl
03:50 PM jepler: e.g., "loop through all the labels in the screen and make sure they have 3px spacing above and below, as the internal style guide calls for"
03:51 PM jepler: and cut and paste is *almost*: produce a script for a widget sub tree, do a search-and-replace with the new widget name, then execute the script
03:53 PM jepler: anyway, you can probably tell it's a project I remain proud of even though it never saw success outside of $DAY_JOB. (it is still used internally)
03:54 PM seb_kuzminsky: ugh, our tool handling really is a mess - i'm trying to write a test for #330/#409 and io uses tool-number, pocket, and index inconsistently, and it's different on random and non-random toolchanger configs
03:54 PM seb_kuzminsky: in a way that's making the fix for #330 needlessly hard
03:56 PM JT-Shop: I always wondered why Axis was a mix of python and TCL...
03:57 PM seb_kuzminsky: and it's different in io's hal pins vs the status buffer
03:57 PM seb_kuzminsky: and different again in io's undocumented parameter, which it uses to set other stuff later
03:57 PM seb_kuzminsky: sorry, now i'm whinging
04:03 PM rene-dev: seb_kuzminsky ah, now you see what I was talking about :)
04:03 PM seb_kuzminsky: no, i get it, i've been in this code before
04:04 PM rene-dev: ah, ok^^
04:04 PM seb_kuzminsky: notice i never argued that tool handling was well implemented, only that it worked ;-)
04:04 PM rene-dev: to me it looks like that pocket numbers never were intended to be used like norbert wants to use them, and like all other control handle them
04:05 PM seb_kuzminsky: my understanding is that the pocket number identifies the location in the tool storage mechanism
04:05 PM seb_kuzminsky: the tool number identifies the tool
04:05 PM rene-dev: yes, I get that. but the problem with that is, that pepole then tend to work around bugs, or only use the stuff that works the first time
04:05 PM rob_h: even on other controls you can reorder pockets to tool numbers like you can on linuxcnc now..
04:05 PM seb_kuzminsky: and the tool "index" is just an internal implementation detail
04:05 PM rene-dev: yes, sometimes the code comment tell something else
04:05 PM rob_h: as when your changer gets stuck and has a cry.. you need to edit the table and reorder what is where and in spindle etc
04:06 PM rene-dev: and then pepole never report what they find
04:08 PM rene-dev: https://github.com/LinuxCNC/linuxcnc/blob/8ca6b52ebe6fc451762f0f06c08a266944f978ea/src/emc/rs274ngc/interp_internal.hh#L716
04:08 PM rene-dev: it says index is pocket number. its not.
04:08 PM seb_kuzminsky: it sometimes is
04:08 PM seb_kuzminsky: on random toolchangers, index == pocket
04:08 PM seb_kuzminsky: on non-random it's not
04:09 PM seb_kuzminsky: i think
04:09 PM seb_kuzminsky: the deal is: linuxcnc is old, old software. it's been developed and maintained by lots of people
04:09 PM seb_kuzminsky: we are the current custodians, and we've inherited the project
04:10 PM rob_h: i think its quite "current" when compared to other controls too tho
04:10 PM seb_kuzminsky: our goal should be to do no harm, and to try to leave it better than we found it, for the folks that come after us
04:10 PM rob_h: as you can do alot of stuff with linuxcnc that its very costly options on other names
04:10 PM seb_kuzminsky: rob_h: that's really nice to hear, thank you
04:10 PM seb_kuzminsky: it's easy to get wrapped up in all the negativity
04:10 PM rob_h: indeed
04:10 PM rob_h: and its easy for people to moan too
04:10 PM rene-dev: I wasnt negative, I was just wondering how it could work at all ;D
04:11 PM seb_kuzminsky: rene-dev: i understand :-)
04:12 PM seb_kuzminsky: i was talking about my own negativity as much as anything
04:12 PM rene-dev: so as far as I see, a random toolchanger is, by its hardware, limited to swap the tool in the spindle with one of the pockets?
04:13 PM rene-dev: so on a toolchange, it needs to swap the pocket numbers?
04:13 PM seb_kuzminsky: that's my understanding as well
04:13 PM seb_kuzminsky: a non-random toolchanger puts the tool back in the pocket it came from
04:13 PM rene-dev: yep
04:13 PM seb_kuzminsky: a random toolchanger puts the tool in (potentially) a different pocket than it came from, with no known pattern
04:13 PM rob_h: yes thats correct
04:14 PM rene-dev: so, why is there then a different handling of numbers, and indexes, and pockets?
04:14 PM rob_h: as no tool ever goes back in the same pocket
04:14 PM rene-dev: where it really only needs to swap the numbers on a toolchange?
04:14 PM rob_h: unless dont have more than two tools but thats getting picky
04:14 PM seb_kuzminsky: tool numbers and pockets are a necessary split
04:14 PM seb_kuzminsky: the number identifies the tool, it's what you talk about in g-code
04:14 PM rob_h: i guess linuxcnc chose to swop pocket numbers and not tool numbers.. i guess so list is always in tool number order
04:14 PM rene-dev: yes, I know
04:14 PM seb_kuzminsky: the pocket identifies where that tool is, this can potentially change (on a random tc machine)
04:15 PM rene-dev: swapping tool numbers is a bad idea, that will mess with your offsets
04:15 PM seb_kuzminsky: the index i think is just an implementation detail
04:16 PM seb_kuzminsky: on a non-random config, when linuxcnc reads the tool table from disk into shared memory, it skips over empty pockets
04:16 PM seb_kuzminsky: so all the tools are in low-numbered indexes of the internal tool array
04:16 PM seb_kuzminsky: it's... confusing
04:18 PM rob_h: like when you have tool wear on a control.. you group tools together of same tool type.. so when one tool wears out.. it carry son with the next in the group so your code always calls the same t number
04:18 PM rob_h: just you get the new tool from the rack in a different pocket#
04:18 PM rene-dev: im not looking for a nice place to open the db in the interpreter... I picked here: https://github.com/LinuxCNC/linuxcnc/blob/8ca6b52ebe6fc451762f0f06c08a266944f978ea/src/emc/rs274ngc/rs274ngc_pre.cc#L2340
04:19 PM rene-dev: rob_h yes, a next_tool clolum. when its worn out, it picks another one.
04:19 PM rob_h: diff controls i find have different ways to show it etc.. but it all works the same under lying realy
04:20 PM rob_h: alot of my know how lies with fanuc as thats what we have on most machines.. we have afew other types .. friends have DMGs which is there own fancy front end that does alot for you
04:33 PM rob_h: like to see things changed for the better but not made worst so if you want some real world input i am happy to help out in this regard
04:59 PM rene-dev: seb_kuzminsky where in the makefile/configure stuff do I add libs?
05:12 PM jepler: rene-dev: with the target for each program or shared library that requires it, e.g. emc/iotask/Submakefile for iotask
05:12 PM jepler: for initial testing I recommend just hardcoding -lsqlite3 or whatever it is but ultimately it probably needs to be integrated to configure, which one of us can help you with at that time.
05:13 PM rene-dev: found it, thanks
05:13 PM jepler: so an untested patch would look sorta like
05:13 PM jepler: ../bin/io: $(call TOOBJS, $(IOSRCS)) ../lib/liblinuxcnc.a ../lib/libnml.so.0 ../lib/liblinuxcnchal.so.0 ../lib/liblinuxcncini.so.0
05:13 PM jepler: $(ECHO) Linking $(notdir $@)
05:13 PM jepler: - @$(CXX) $(LDFLAGS) -o $@ $^
05:13 PM jepler: + @$(CXX) $(LDFLAGS) -o $@ $^ -lsqlite
05:14 PM jepler: I think the interpreter also directly reads the tool table, so you might also soon find you need it at emc/rs274ngc/Submakefile for the target ../lib/librs274.so.0:
05:14 PM jepler: .. not sure, just an example / general statement that it might need to be added in more than one place
05:14 PM rene-dev: interpreter needs it via task, and iocontrol needs this
05:15 PM jepler: oh maybe the standalone rs274 program in src/emc/sai
05:15 PM jepler: .. it links with emc/rs274ngc/tool_parse.cc
05:15 PM jepler: just trying to help, don't mind me if it's not relevant yet to your work
05:15 PM rene-dev: yep, that as well
05:19 PM rene-dev: jepler the axis tooledit is tcl... https://www.sqlite.org/tclsqlite.html
05:20 PM rene-dev: so someone(tm) could change that, or axis just uses the tooledit widget, which also works as standalone program
05:22 PM jepler: libsqlite3-tcl/stable 3.16.2-5+deb9u1 amd64
05:22 PM jepler: SQLite 3 Tcl bindings
05:22 PM jepler: happily the tcl bindings are in debian (stretch) so that's fine so far
05:22 PM jepler: I didn't check the old distros we've previously promised to support for 2.8 though
05:30 PM Tom_L: interesting read here
05:35 PM seb_kuzminsky: i recommend against linking all those things against libsql directly
05:35 PM seb_kuzminsky: i propose creating a new tooltable library, containing this API we've mentioned once or twice, and linking the linuxcnc code against *it*
05:36 PM seb_kuzminsky: and that library links to libsql or whatever ends up being behind it
05:36 PM seb_kuzminsky: ie, make the abstraction the main thing, and hide the implementation
05:36 PM seb_kuzminsky: but i'm not the guy doing the work, so feel free to ignore me
05:43 PM skunkworks: buzz kill
05:45 PM rene-dev: seb_kuzminsky all the sqlite stuff will be in one file, called by all the things
05:45 PM rene-dev: but I dont know the make magic to make that into its own thing
05:46 PM seb_kuzminsky: you could look at how we make (for example) liblinuxcnchal, if you wanted to learn, or go ahead with your original plan, either way's fine by me
05:47 PM rene-dev: I like your idea better... just dont know how to do it :D anyway, let me finish it first^^
05:47 PM seb_kuzminsky: cool
05:48 PM seb_kuzminsky: i'm super excited you're doing this
05:49 PM rene-dev: dont get too excited, it will still be limited to 18446744073709551616 tools
05:50 PM seb_kuzminsky: aww, then why even bother
05:50 PM rene-dev: is there some convenience function to print EmcPose?
05:50 PM seb_kuzminsky: don't know, sorry
06:31 PM rene-dev: https://pastebin.com/zBi5tjDE
06:31 PM rene-dev: I know its not there... but what expects it to be there?
06:32 PM seb_kuzminsky: i've not seen that import error before
06:32 PM seb_kuzminsky: 'git grep loadToolTable' says it comes from src/emc/rs274ngc/tool_parse.cc
06:32 PM seb_kuzminsky: and is used by io, io2, and sai
06:33 PM rene-dev: tool_parse.cc is not in the makefile anymore
06:33 PM rene-dev: its not called from c
06:33 PM rene-dev: where could it be called form python?
06:33 PM rene-dev: and how, when it compiles?
06:38 PM seb_kuzminsky: rene-dev: 'git grep tool_parse.cc' tells me that it's in io's, task's, and sai's Submakefiles
06:42 PM seb_kuzminsky: rene-dev: i'd like your feedback on #410 if you get a chance among all your coding
06:42 PM seb_kuzminsky: it fixes #330
06:50 PM rene-dev: I have seen that part, and was wondering if that was related...
06:50 PM rene-dev: so #400 next? :)
06:51 PM rene-dev: I I think it just return the index instead of pocket number...
06:52 PM rene-dev: because current_pocket isnt the pocket number
06:52 PM rene-dev: so a pocket needs to be added to CANON_TOOL_TABLE
06:53 PM skunkworks: I vaugly remember andy fixing these problems in his branch...
07:01 PM rene-dev: The sql Branch?
07:04 PM seb_kuzminsky: skunkworks: really? oops... i wish i'd been awake enough to notice that
07:05 PM skunkworks: only a slight tingle in the memory bank...
07:05 PM skunkworks: I remember him talking about the issue
07:28 PM hazzy: Wow, I just glanced at andy's tooltable branch and it looks like he did a lot of work on that. That was in 2013, wonder if I can merge it and see how it works
07:29 PM Tom_L: iirc he was working on the carousel comp at the time
07:29 PM hazzy: That would make sense
07:44 PM rene-dev: it only replaces the tooltable in one place of many... its far from complete
07:50 PM hazzy: rene-dev: Ok, I was wondering about that. I did not read enough to understand what he had/had not changed
07:52 PM rene-dev: now im stuck in rcs_exec
08:05 PM rene-dev: why doesnt rtapi_print_msg(RTAPI_MSG_DBG, print, even if I have DEBUG = 0x7FFFFFFF?
08:45 PM jepler: rene-dev: rtapi_print_msg is controlled by the level set by a call to rtapi_set_msg_level
08:46 PM jepler: in a non-realtime component like io or task, it is local to the UNIX process
08:46 PM jepler: in a realtime component, it is global to all realtime components
08:46 PM jepler: the default is not set from inifile, but can be set in any task at any time by calling rtapi_set_msg_level
08:46 PM rene-dev: ah, so I have to call rtapi_set_msg_level myself?
08:46 PM rene-dev: ok
08:47 PM jepler: yes, unfortunately. It would be a better development experience if there were some other way, but that isn't the case right now. (patches to improve that would probably be relatively easy to accept to master, but I don't know exactly what the implementation should be ...)
08:48 PM jepler: you'll see many components, such as hal/components/stepgen.c, that change the message level then put it back later. It's arguable whether this is a good idea or not, but it's what is done.
08:52 PM rene-dev: I have now seen at least 3 previous attempts in the code to change the tooltable
11:46 PM KimK: Only 3? ;)