#linuxcnc-devel Logs

Nov 17 2018

04:41 AM rmu: int Interp::find_tool_pocket(setup_pointer settings, int toolno, int *pocket) ???
05:17 AM jthornton: it would make sense to have a #linuxcnc-github channel to cut down on the static in here
05:58 AM rene_dev_: Rmu yes
07:09 AM rmu: rene_dev_: what is missing with the tool and pocket stuff? i just finished my ATC stuff, and i did the mapping between tool and pocket in O-word subroutine (for now)
07:09 AM rmu: rene_dev_: can i help debug something?
07:09 AM rene_dev_: yes, test my branch.
07:10 AM rene_dev_: https://github.com/LinuxCNC/linuxcnc/pull/528
07:10 AM rene_dev_: those commits apply to master and 2.7
07:10 AM rene_dev_: there is one problem left, where the remap still has the wrong number, so just use the interp variables, they are correct now
07:11 AM rmu: i'm going to check in my custom remapper if the pocket reported by the interp is what is expected and make sure custom remap and tool table agree
07:12 AM rmu: then it should catch any wrong situations without crashing the machine
07:14 AM rene_dev_: use those:
07:14 AM rene_dev_: #<_current_tool> - Return number of the current tool in spindle. Same as #5400.
07:14 AM rene_dev_: #<_current_pocket> - Return pocket number of the current tool.
07:14 AM rene_dev_: #<_selected_tool> - Return number of the selected tool post a T code. Default -1.
07:14 AM rene_dev_: #<_selected_pocket> - Return number of the selected pocket post a T code. Default -1 (no pocket selected).
07:14 AM rene_dev_: dont use whatever the glue code reports, they are not correct
07:15 AM rmu: yes i'm using that.
07:16 AM rene_dev_: then it should work :D
07:17 AM rene_dev_: https://github.com/LinuxCNC/linuxcnc/blob/master/nc_files/remap_lib/python-stdglue/stdglue.py#L136-L141
07:17 AM rmu: hardware of this machine is a bit stupid. if somebody hits estop while toolchange is in progress it could crash the spindle
07:17 AM rene_dev_: they are broken
07:17 AM rene_dev_: the underscore makes all the difference
07:18 AM rmu: doesn't really make sense to prepare those wrong local variables there
07:18 AM rene_dev_: I know
07:19 AM rene_dev_: the whole concept of the gcode calling python calling gcode, that defines parameters that are wrong, and are already defined correclty..... is a bit stupid
07:19 AM rene_dev_: I would much prefer if the remap just calls a gcode macro, like every other control
07:19 AM rmu: isnt it possible to use self.find_tool_pocket(tool) there?
07:20 AM rene_dev_: thats what stdglue does, but you dont need that. the interpreter exports correct variables.
07:20 AM rmu: yeah, i mean for kind-of backwards-compatibility
07:21 AM rene_dev_: find_tool_pocket is fixed now
07:22 AM rene_dev_: oh, its not in the current branch, so dont use it.
07:22 AM rmu: whoever implemented that originally just put it there so something is there without finishing it ;)
07:22 AM rene_dev_: its not easy to fix
07:22 AM rene_dev_: and probably never used a toolchanger
07:22 AM rene_dev_: if you start to use correct numbers internally, everything breaks
07:22 AM rene_dev_: because the pocket numbers are not unique
07:23 AM rmu: what does that mean
07:23 AM rmu: if somebody assigns two tools to the same pocket that would be the same as cutting into the machine bed
07:23 AM rmu: can't really do anything about it
07:26 AM rmu: is there a possibility to single-step g-code in those remapped stuff?
07:35 AM rene_dev_: I dont know
07:35 AM rene_dev_: yes, you can have 2 tools in the same pocket
07:35 AM rmu: in what kind of situation would that be useful
07:36 AM rene_dev_: https://www.ebay.de/itm/121864286068
07:36 AM rene_dev_: dual tool holders on a lathe
07:36 AM rene_dev_: or multiple setups on a mill, where you have more tools set up than pocket in the holder
07:36 AM rmu: yeah ok
07:37 AM rene_dev_: like you have a 20x changer, and use t1-20 for one part, and t21-41 for another part
07:37 AM rene_dev_: and just swap all of them between runs
07:37 AM rene_dev_: without setting them up again
07:37 AM rmu: i also have some kind of 90° drilling tool that in theory could be put into the tool changer that has 2 opposing drill bits
07:37 AM rene_dev_: yes
07:38 AM rene_dev_: or on a lathe, where you have gangtooling and revolver mixed up
07:38 AM rene_dev_: so sometimes you need to turn the revolver, and somethimes not
07:39 AM rene_dev_: so the pocket number is not unique, but the index is. and the index is passed along internally
07:39 AM rmu: seems there needs to be a way to customize tool nr <-> pocket mapping
07:39 AM rene_dev_: and the index gives you everything, but the pocket does not, as the real pocket is ambiguous
07:39 AM rene_dev_: there is, in the tool table
07:39 AM rene_dev_: one field for tool number, and another for pocket number
07:40 AM rmu: but this mapping could be dynamic
07:40 AM rene_dev_: it is, on random toolchangers
07:40 AM rene_dev_: you can just change it, if you rearrange your changer
07:41 AM rene_dev_: or what do you mean by dynamic
07:42 AM rmu: 2 spindles taking tools from one changer. only one free pocket.
07:42 AM rene_dev_: I have not even looked into multi spindle :D
07:43 AM rene_dev_: but imho that should already work. you just need to take care of things in the toolcnage macro
07:43 AM rmu: point is that tool always has to be put into free pocket
07:43 AM rene_dev_: no, the tool is always put back into the home pocket on non-random changers
07:43 AM rene_dev_: and in the pocket of the next tool on random changers
07:43 AM rmu: ok, so i can change pocket number in toolchange macro? i think the #<_selected_pocket> and #<_current_pocket> are read only
07:44 AM rene_dev_: they are
07:44 AM rene_dev_: iocontrol swaps pockets for random changers
07:44 AM rmu: so imagine having something in between your random changer, that exchanges the tool with another, and the non-random
07:45 AM rene_dev_: I know, imho the pocket swap should be done in the macro
07:45 AM rmu: hmm. don't understand, but i will not come around activating the second spindle anytime soon
07:46 AM rene_dev_: the idea of the remap glue stuff is that you can write to interp variables, and do stuff like that
07:46 AM rene_dev_: the problem is, that it wont behave as expected :D
07:48 AM rmu: i need more git practice... i have some documentation fixes queued for a PR
07:52 AM rene_dev_: doc fixes go in 2.7
07:52 AM rene_dev_: I made the mistake before :D
07:52 AM rene_dev_: unless they document stuff that is in master only
09:48 AM Tom_itx: is there a way to access tool diameter in the tool table from the hal file?
09:52 AM rmu: Tom_itx: #5410 is the diameter of the current tool, but that's probably not want you want
09:55 AM rmu: Tom_itx: in theory (untested), you could save current tool number in some variable, use M61 Q<newtoolnumber> to tell linuxcnc that magically tool <newtoolnumber> is in the spindle, then quers #5410, then M61 Q<savedtoolnumber> to restore state
09:55 AM rmu: afk
01:30 PM pcw_home: Thank you Chris!
01:37 PM CMorley: Thank you Peter!
02:52 PM rene_dev_: Pcw_home cmorley can you explain why?
02:52 PM rene_dev_: in theory the external signal is better
02:54 PM CMorley: Peter said this in the forum:
02:54 PM CMorley: Why exactly the internal command derivative works better than using the external commanded velocity is something I do not understand, but is likely a sample period delay issue somewhere. So currently best to leave the pin unconnected for both servo and stepper systems.
03:04 PM rene_dev_: I changed how the internal deriv was calculated recently
03:05 PM rene_dev_: it used to be exactly the same as the internal, now its one peroid quicker
03:07 PM rene_dev_: https://github.com/LinuxCNC/linuxcnc/commit/76d03302c6849ee4f70b7b0a46db025b64c12bc0
03:34 PM pcw_home: Yeah I think because the command and feedback at not time aligned (so you need to set the PID option error_previous_target) you need the delayed command deriv
03:35 PM pcw_home: (it might be ok to use the non delayed derivative if error_prev_target were false but this causes trouble with the I term )
03:36 PM pcw_home: not sure who thought it would be good to not align feedback with command because it causes quite a mess
03:55 PM rene_dev_: you dont want an I term in the position loop
03:56 PM rene_dev_: I think the hostmot stepgen pid should be fixed, so that this is not an issue anymore
03:56 PM rene_dev_: I can do it, and it is on my list of things...
04:18 PM pcw_home: You typically need I in a torque loop and this is where the time offset of command and feedback is an issue
04:19 PM pcw_home: but also if you simple use a small bit of I to remove static errors in a velocity loop it will cause problems
04:20 PM pcw_home: the hostmot position mode should be fixed to use an internal PID loop and built in headroom but thats a fair project
04:24 PM rene_dev_: I know, but Im talking about position loops, as in the hostmot stepper
04:26 PM pcw_home: thats what I was talking about (the built in position mode is not very good)
04:26 PM rene_dev_: yes, but why, and why is it not fixed? :D
04:28 PM pcw_home: easy enough to work around (though it causes pain in suffering because of needlessly complex hal files)
04:35 PM pcw_home: plus there's a pretty big backlog of unsupported hostmot2 stuff/bugfixes in addition to the stepper position mode troubles
04:43 PM rene_dev_: which other backlog?
04:44 PM rene_dev_: yeah, its the complicated hal files, and the additional vel/acc setting that makes things complicated and confusing for new pepole
04:46 PM pcw_home: yeah the PID stepgen control works well but that and all the headroom nonsense are not good
04:47 PM pcw_home: backlog is new module support, some encoder bugfixes, encoder enhancements etc
04:48 PM rene_dev_: which module support? I already had some ideas how to make all the hostmot modules more flexible and modular
04:49 PM rene_dev_: what annoys me, is to add a new module, you have to add its functions all over the place
04:50 PM rene_dev_: would be much easier to have a struct, with fucnction pointers, like it is done in the linux kernel, or the stmbl hal
04:50 PM rene_dev_: https://github.com/rene-dev/stmbl/blob/master/shared/comps/or.c#L18-L31
04:54 PM rene_dev_: https://sigrok.org/gitweb/?p=libsigrok.git;a=blob;f=src/hardware/demo/api.c;h=7d3e08872d07c21b38832845a138d5cf2bd3fe80;hb=HEAD#l549
04:54 PM rene_dev_: like this
04:55 PM pcw_home: yeah ist shoud be easier to add a new module (ultimately it would be better if the IDROM provided more metadata)
04:56 PM rene_dev_: something self describing like smart serial would be nice, but as a hostmot module only
04:58 PM pcw_home: Yes that would be really nice, Wish I had started that way...
04:59 PM pcw_home: module support: Inm/Inmux, 50% mode added to pwmgen, dpainter
05:04 PM rene_dev_: dpainter? for laser cutters?
05:50 PM pcw_home: Yes, for motion synchronized data painting (either on/off or PWM)
07:56 PM Tom_itx is now known as Tom_L
08:45 PM jepler: "that's another CAD of worms"
09:26 PM linuxcnc-build: build #2343 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/2343 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
09:33 PM jepler: 10.609: timeout waiting for joint 0 to stop at -1.000 (pos=0.000, vel=0.000)
09:33 PM jepler: hm spurious?
09:33 PM * jepler frowns at linuxcnc-build
09:33 PM linuxcnc-build: build #5735 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/5735 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>