#linuxcnc-devel Logs

Feb 24 2018

05:28 AM hazzy1 is now known as hazzy
09:34 AM rene-dev: how do I run a test? the terminal window just closes when I try...
09:48 AM jepler: rene-dev: from the top directory of the linuxcnc git clone, . scripts/rip-environment, then runtests. You can run a specific test with e.g., runtests tests/abs.0
10:15 AM rene-dev: ah, now it works. how do I get details about the failure?
10:17 AM rene-dev: jepler I now completley changed tool handling, so that there is no more limit at all.
10:17 AM rene-dev: it could now use a sqlite, or the old tooltable backend. any thoughts?
10:17 AM rene-dev: or even both, depending on file extension...
10:51 AM seb_kuzminsky: rene-dev: awesome!
10:51 AM hazzy: rene-dev: Hurray!!!!
10:52 AM seb_kuzminsky: if a test fails you can cd to its directory and look at 'result' (stdout) and 'stderr'
10:52 AM rene-dev: a test? currently all toolchange realted tests fail ;D
10:53 AM rene-dev: but thats most likeley because the cant even read the tooltable
10:53 AM seb_kuzminsky: lol
10:53 AM seb_kuzminsky: sure
10:53 AM seb_kuzminsky: updating the code is one thing, updating all the tests is another
10:54 AM rene-dev: random toolchangers wont work the way they used to, they need some work
10:54 AM seb_kuzminsky: this also brings up an important point - what would a user have to do to convert their running system to deal with this new change?
10:54 AM seb_kuzminsky: that needs to be documented, probably in docs/src/getting-started/updating-linuxcnc.txt
10:54 AM rene-dev: if we go for sqlite tooltable really only convert the tooltable
10:55 AM rene-dev: problem is, random toolchangers use the index as pocket numbers, which I think is stupid and wrong. problem is, the index doesnt exist anymore.
10:55 AM seb_kuzminsky: which reminds me, there's quite a bit of documentation about toolchangers and the tool table file that will probably need to be updated in your branch too
10:56 AM rene-dev: look at this: https://github.com/LinuxCNC/linuxcnc/blob/8ca6b52ebe6fc451762f0f06c08a266944f978ea/src/emc/task/emccanon.cc#L1976-L1982
10:57 AM seb_kuzminsky: yeah i think the index isn't useful at all, it's just an implementation detail that is needlessly exposed outside of the toolchanger code
10:57 AM rene-dev: independent form what Im doing now, I think the toolhandling should be removed from iocontrol, and all be handled in a remap
10:58 AM rene-dev: thats how all the other controllers do it, and having only one very flexible way of doing toolchanges simplifies a lot
10:58 AM seb_kuzminsky: yep, that comment echoes what you told be about rack and umbrella toolchangers earlier
10:58 AM rene-dev: there are 2 problems with the way iocontrol handles toolchanges: you cant move the axis, and you cant handle faults
10:59 AM seb_kuzminsky: we'll have to think about that (doing all m6 in remap)
10:59 AM rene-dev: yes, just always have m6 done by a macro, which the user then can edit
11:00 AM rene-dev: I would even prefer to do it in python, as expecially doing IO logic in gcode is very annoying to do
11:01 AM rene-dev: I would even go further than that, and remove iocontrol altogether. if you remove the tool handling, only coolant and enable is left...
11:01 AM seb_kuzminsky: you're a programmer, but most of our users are not, they need a solution that works out of the box
11:02 AM seb_kuzminsky: yeah, getting rid of io would sure simplify things
11:02 AM rene-dev: a toolchanger always requires programming
11:02 AM seb_kuzminsky: i disagree
11:02 AM seb_kuzminsky: the toolchanger we have now works for lots of people, without any programming
11:02 AM rene-dev: you mean manually changing tools?
11:02 AM seb_kuzminsky: much of what io does could/should be done within task
11:03 AM seb_kuzminsky: manual and carousel both work great with 0 programming today
11:03 AM rene-dev: iocontrol is really only there because befoere there was hal
11:03 AM rene-dev: manual ok, you could have a default config
11:04 AM rene-dev: but how does carousel work without programming?
11:04 AM rene-dev: maybe on a lathe. but anything where you need to clamp/unclamp requires programming...
11:06 AM seb_kuzminsky: oh yeah, and tool turrets on lathes work too
11:06 AM seb_kuzminsky: clamping/unclamping is easy to do in hal
11:07 AM seb_kuzminsky: (by "no programming" i don't mean "no hal circuitry")
11:07 AM rene-dev: hal is touring complete ;D
11:07 AM rene-dev: turing
11:10 AM rene-dev: I think you could have the functionality of iocontrol tool pins with 2 easy and short default remaps
11:11 AM rene-dev: that lube stuff can also go... is it even possible to use that?
11:11 AM rene-dev: everybody seems to do the lube form hal now
11:22 AM seb_kuzminsky: rene-dev: i caution you against trying to fix every problem at once
11:23 AM seb_kuzminsky: you've bitten off a big piece with the tool-file handling, and it sounds like you've done the coding part
11:23 AM hazzy: rene-dev: I really like the idea of doing all M6 in remap, and having defaults for manual TC and simple ATCs
11:23 AM hazzy: It seems like even now it would be neater to have manual TC be a remap, rather than having hal manualtoolchange basically simulate the out put from a toolchanger to make everything happy.
11:23 AM seb_kuzminsky: there's still the testing & documentation part
11:23 AM rene-dev: I know
11:23 AM seb_kuzminsky: keeping the branch limited and focused makes it *much* more reviewable, which makes it much more likely to be merged
11:24 AM rene-dev: the problem with what Im doing now is, that the tool limit is hardcoded almost everywhere. so that is a lot of stuff at once already.
11:24 AM seb_kuzminsky: we've had folks before get carried away with making tons of unrelated changes, it ended in catastrophe and bad feelings all around
11:24 AM rene-dev: I know...
11:24 AM seb_kuzminsky: ok cool i'll stop harping on it :-)
11:24 AM seb_kuzminsky: i'd love to look at what you've done, when you're ready to share
11:25 AM rene-dev: Im only changing the tool storage backend, but that requires a lot of changes unfortunately
11:25 AM seb_kuzminsky: sure
11:25 AM rene-dev: im cleaning it up as we speak...
11:26 AM rene-dev: but its nowhere near being finished. Tx M6 and M61 work, but havent verifies any outputs. but the tool gets changed
11:26 AM rene-dev: what doesnt currently work are any of the set tooltable gcodes, thats next.
11:27 AM rene-dev: meanwhile norbert is working on the tooledit widget
11:48 AM jepler: the tooledit standalone program, or the thing within his ui program?
01:18 PM rene-dev: jepler the widget, but it can be used as standalone as well, so other UIs like axis can use it.
01:47 PM * skunkworks__ cheers from the cheap seats
03:48 PM rene-dev: jepler seb_kuzminsky I have a few Ideas how to simplify the toolchanging, while retaining compatibility with old configs...
04:44 PM seb_kuzminsky: rene-dev: i like the sound of that!
04:45 PM rene-dev: seb_kuzminsky so you want to keep TOOL_CHANGE_POSITION and TOOL_CHANGE_WITH_SPINDLE_ON and stuff like that, for simple setups
04:45 PM rene-dev: how about, the interpreter sets those settings form the ini as parameters, which are then evaluated in the remap
04:46 PM rene-dev: that would remove a lot of code, and give users a starting point for their toolchanger
04:46 PM rene-dev: because currently there are 2 options, and its not easy to go form one to the other
04:47 PM rene-dev: im having trouble getting stuff form the ini... so inifile.Find("TOOL_TABLE", "EMCIO") gets me the filename. how do I convert that in the full path, which should be relative to the ini?
04:48 PM jepler: linuxcnc's normal startup script changes directory to the one with the .ini file
04:49 PM jepler: otherwise, if you're asking "how does one manipulate path strings in python", that's in the os.path module...
04:50 PM seb_kuzminsky: rene-dev: there's an environment variable with the config dir, set by the `linuxcnc` launcher script
04:50 PM rene-dev: no, Im in c...
05:03 PM rene-dev: also, currently the tool on startup is 0 for nonrandom changers.
05:04 PM rene-dev: norbert saves the tool, and reloads it on startup. but I really think that functionallity should be buildin, and not in the gui
05:04 PM rene-dev: store tool in some non volatile parameter
05:06 PM rene-dev: ransom toolchangers use tooltabel entry 0 for that.
05:07 PM jepler: in C(++) we already depend on some parts of boost, so if you want a proper path manipulation library may I recommend boost filesystem.
05:08 PM rene-dev: the code that does what I need should already be there...
05:08 PM rene-dev: https://github.com/LinuxCNC/linuxcnc/blob/af15a4d90e1d51d5309db65fe1c9511e486df411/src/emc/ini/initool.cc#L44
05:09 PM rene-dev: but that doesnt work for some reason...
05:12 PM seb_kuzminsky: i agree it would be good if non-random toolchangers remembered what tool was loaded through linuxcnc restarts
05:12 PM seb_kuzminsky: i don't know if we can use pocket 0 on non-random, like we do on random (i haven't thought about it)
05:12 PM rene-dev: yes, the code just doesnt do it :D
05:13 PM rene-dev: https://github.com/LinuxCNC/linuxcnc/blob/8ca6b52ebe6fc451762f0f06c08a266944f978ea/src/emc/rs274ngc/rs274ngc_pre.cc#L2347
05:14 PM rene-dev: it should just work if you remove the if
05:20 PM rene-dev: ah, no it wont. because of this: https://github.com/LinuxCNC/linuxcnc/blob/8ca6b52ebe6fc451762f0f06c08a266944f978ea/src/emc/rs274ngc/tool_parse.cc#L116
05:47 PM seb_kuzminsky: yeah my experience with the linuxcnc code base suggests there are no quick simple fixes
05:48 PM seb_kuzminsky: which is why the test suite is soooo important
05:54 PM rene-dev: im just in the process of getting tests to pass
06:25 PM rene-dev: seb_kuzminsky jepler https://github.com/LinuxCNC/linuxcnc/tree/master/tests/interp/compile
06:25 PM rene-dev: how important is that?
06:37 PM rene-dev: I can probably use GET_EXTERNAL_TOOL_TABLE, but use toolnumbers instead of pocket numbers...
07:09 PM jepler: the APIs tested in that test, basically for having their signatures match, are in effect public APIs of LinuxCNC and shouldn't be broken in minor releases or without good reason.
07:10 PM jepler: if there's good reason, we can break it in our development branch
07:11 PM rene-dev: ok, so I figure something out.
07:11 PM rene-dev: but what I did, is moved the tooltable from iocontrol to the interpreter
07:13 PM rene-dev: which is a much better place for it, as only ever a Txx, M61, and G10 ever need to access it.
07:13 PM rene-dev: and the gui of course
07:14 PM rene-dev: I then changed all the tool related nml messages, so the other parts dont need the tooltable, as they can so everything from the message
07:14 PM rene-dev: so there is no reload or sync required anymore. it reduces the complexity a lot
07:45 PM jepler: it me https://thedailywtf.com/articles/the-telltale-snippet