#linuxcnc-devel | Logs for 2018-11-17
Back
[00:06:52] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15c-morley opened issue #529: Gmoccapy error with overrides after merge from 2.7 02 https://github.com/LinuxCNC/linuxcnc/issues/529
[01:07:06] -!- c-log has quit [Ping timeout: 264 seconds]
[01:09:08] -!- c-log has joined #linuxcnc-devel
[01:49:49] -!- ve7it has quit [Remote host closed the connection]
[02:19:39] -!- c-log has quit [Ping timeout: 268 seconds]
[02:21:49] -!- c-log has joined #linuxcnc-devel
[05:40:06] <rmu> int Interp::find_tool_pocket(setup_pointer settings, int toolno, int *pocket) ???
[06:16:12] <jthornton> it would make sense to have a #linuxcnc-github channel to cut down on the static in here
[06:56:35] <rene_dev_> Rmu yes
[07:48:53] -!- Tom_L has quit [Read error: Connection reset by peer]
[07:51:03] -!- Tom_itx has joined #linuxcnc-devel
[07:56:48] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15rene-dev commented on issue #529: I think I messed up the merge: https://github.com 02 https://github.com/LinuxCNC/linuxcnc/issues/529#issuecomment-439614695
[08:01:17] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15gmoccapy pushed 1 new commit to 06master: 02 https://github.com/LinuxCNC/linuxcnc/commit/55aadc3fcae3e66df65b84cc8458d41ef55bf3c9
[08:01:17] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06master 1455aadc3 15Norbert Schechner: gmoccapy_2_3_3_4 - fixed an error caused due to wrong merge of 2.7 to master...
[08:01:43] -!- c-log has quit [Ping timeout: 245 seconds]
[08:03:58] -!- c-log has joined #linuxcnc-devel
[08:07:38] <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)
[08:07:50] <rmu> rene_dev_: can i help debug something?
[08:07:59] <rene_dev_> yes, test my branch.
[08:08:33] <rene_dev_> https://github.com
[08:08:43] <rene_dev_> those commits apply to master and 2.7
[08:09:19] <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
[08:10:19] <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
[08:10:42] <rmu> then it should catch any wrong situations without crashing the machine
[08:12:12] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15rene-dev commented on issue #528: looks like the remap is still broken, there is no test for them. I will add a workaround for that. but the interp variables are ok, just use them in the m6 remap. 02 https://github.com/LinuxCNC/linuxcnc/pull/528#issuecomment-439615814
[08:12:59] <rene_dev_> use those:
[08:13:00] <rene_dev_> #<_current_tool> - Return number of the current tool in spindle. Same as #5400.
[08:13:00] <rene_dev_> #<_current_pocket> - Return pocket number of the current tool.
[08:13:00] <rene_dev_> #<_selected_tool> - Return number of the selected tool post a T code. Default -1.
[08:13:00] <rene_dev_> #<_selected_pocket> - Return number of the selected pocket post a T code. Default -1 (no pocket selected).
[08:13:18] <rene_dev_> dont use whatever the glue code reports, they are not correct
[08:13:32] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15gmoccapy closed issue #529: Gmoccapy error with overrides after merge from 2.7 02 https://github.com/LinuxCNC/linuxcnc/issues/529
[08:13:41] <rmu> yes i'm using that.
[08:14:40] <rene_dev_> then it should work :D
[08:15:30] <rene_dev_> https://github.com
[08:15:31] <rmu> hardware of this machine is a bit stupid. if somebody hits estop while toolchange is in progress it could crash the spindle
[08:15:33] <rene_dev_> they are broken
[08:15:50] <rene_dev_> the underscore makes all the difference
[08:16:24] <rmu> doesn't really make sense to prepare those wrong local variables there
[08:16:48] <rene_dev_> I know
[08:17:25] <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
[08:17:58] <rene_dev_> I would much prefer if the remap just calls a gcode macro, like every other control
[08:17:58] <rmu> isnt it possible to use self.find_tool_pocket(tool) there?
[08:18:44] <rene_dev_> thats what stdglue does, but you dont need that. the interpreter exports correct variables.
[08:19:09] <rmu> yeah, i mean for kind-of backwards-compatibility
[08:19:44] <rene_dev_> find_tool_pocket is fixed now
[08:20:35] <rene_dev_> oh, its not in the current branch, so dont use it.
[08:20:40] <rmu> whoever implemented that originally just put it there so something is there without finishing it ;)
[08:20:45] <rene_dev_> its not easy to fix
[08:20:50] <rene_dev_> and probably never used a toolchanger
[08:21:05] <rene_dev_> if you start to use correct numbers internally, everything breaks
[08:21:14] <rene_dev_> because the pocket numbers are not unique
[08:21:37] <rmu> what does that mean
[08:22:07] <rmu> if somebody assigns two tools to the same pocket that would be the same as cutting into the machine bed
[08:22:13] <rmu> can't really do anything about it
[08:24:39] <rmu> is there a possibility to single-step g-code in those remapped stuff?
[08:33:25] <rene_dev_> I dont know
[08:33:33] <rene_dev_> yes, you can have 2 tools in the same pocket
[08:34:12] <rmu> in what kind of situation would that be useful
[08:34:30] <rene_dev_> https://www.ebay.de
[08:34:37] <rene_dev_> dual tool holders on a lathe
[08:35:02] <rene_dev_> or multiple setups on a mill, where you have more tools set up than pocket in the holder
[08:35:11] <rmu> yeah ok
[08:35:26] <rene_dev_> like you have a 20x changer, and use t1-20 for one part, and t21-41 for another part
[08:35:37] <rene_dev_> and just swap all of them between runs
[08:35:45] <rene_dev_> without setting them up again
[08:35:48] <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
[08:35:56] <rene_dev_> yes
[08:36:24] <rene_dev_> or on a lathe, where you have gangtooling and revolver mixed up
[08:36:44] <rene_dev_> so sometimes you need to turn the revolver, and somethimes not
[08:37:27] <rene_dev_> so the pocket number is not unique, but the index is. and the index is passed along internally
[08:37:43] <rmu> seems there needs to be a way to customize tool nr <-> pocket mapping
[08:37:54] <rene_dev_> and the index gives you everything, but the pocket does not, as the real pocket is ambiguous
[08:38:03] <rene_dev_> there is, in the tool table
[08:38:10] <rene_dev_> one field for tool number, and another for pocket number
[08:38:39] <rmu> but this mapping could be dynamic
[08:38:54] <rene_dev_> it is, on random toolchangers
[08:39:04] <rene_dev_> you can just change it, if you rearrange your changer
[08:39:44] <rene_dev_> or what do you mean by dynamic
[08:40:41] <rmu> 2 spindles taking tools from one changer. only one free pocket.
[08:41:04] <rene_dev_> I have not even looked into multi spindle :D
[08:41:32] <rene_dev_> but imho that should already work. you just need to take care of things in the toolcnage macro
[08:41:40] <rmu> point is that tool always has to be put into free pocket
[08:42:09] <rene_dev_> no, the tool is always put back into the home pocket on non-random changers
[08:42:17] <rene_dev_> and in the pocket of the next tool on random changers
[08:42:19] <rmu> ok, so i can change pocket number in toolchange macro? i think the #<_selected_pocket> and #<_current_pocket> are read only
[08:42:29] <rene_dev_> they are
[08:42:58] <rene_dev_> iocontrol swaps pockets for random changers
[08:43:04] <rmu> so imagine having something in between your random changer, that exchanges the tool with another, and the non-random
[08:43:32] <rene_dev_> I know, imho the pocket swap should be done in the macro
[08:44:16] <rmu> hmm. don't understand, but i will not come around activating the second spindle anytime soon
[08:44:46] <rene_dev_> the idea of the remap glue stuff is that you can write to interp variables, and do stuff like that
[08:44:58] <rene_dev_> the problem is, that it wont behave as expected :D
[08:47:16] <rmu> i need more git practice... i have some documentation fixes queued for a PR
[08:50:30] <rene_dev_> doc fixes go in 2.7
[08:50:41] <rene_dev_> I made the mistake before :D
[08:50:55] <rene_dev_> unless they document stuff that is in master only
[09:07:28] -!- JT-Shop has quit [Remote host closed the connection]
[09:11:27] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15TurBoss commented on issue #514: Hello, ... 02 https://github.com/LinuxCNC/linuxcnc/issues/514#issuecomment-439619890
[09:13:36] -!- JT-Shop2 has quit [Quit: Leaving]
[10:46:32] <Tom_itx> is there a way to access tool diameter in the tool table from the hal file?
[10:51:06] <rmu> Tom_itx: #5410 is the diameter of the current tool, but that's probably not want you want
[10:53:44] <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
[10:54:05] <rmu> afk
[10:56:02] <Tom_itx> log
[10:56:02] <c-log> Tom_itx: Today's Log http://tom-itx.no-ip.biz:81
[11:42:01] -!- Jayy_ has joined #linuxcnc-devel
[11:43:01] -!- Jayy_ has quit [Client Quit]
[12:22:05] -!- Roguish has joined #linuxcnc-devel
[13:27:43] -!- ve7it has joined #linuxcnc-devel
[14:26:00] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15c-morley pushed 1 new commit to 06master: 02 https://github.com/LinuxCNC/linuxcnc/commit/dc1574085a1424ccb455a161740cd622acc02fa2
[14:26:00] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06master 14dc15740 15Chris Morley: pncconf -remove signal to PID.command-deriv...
[14:29:16] <pcw_home> Thank you Chris!
[14:36:03] <CMorley> Thank you Peter!
[15:50:33] -!- andypugh has joined #linuxcnc-devel
[15:50:57] <rene_dev_> Pcw_home cmorley can you explain why?
[15:51:11] <rene_dev_> in theory the external signal is better
[15:52:24] <CMorley> Peter said this in the forum:
[15:52:28] <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.
[16:03:21] <rene_dev_> I changed how the internal deriv was calculated recently
[16:03:48] <rene_dev_> it used to be exactly the same as the internal, now its one peroid quicker
[16:05:34] <rene_dev_> https://github.com
[16:32:32] <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
[16:33:48] <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 )
[16:35:04] <pcw_home> not sure who thought it would be good to not align feedback with command because it causes quite a mess
[16:53:38] <rene_dev_> you dont want an I term in the position loop
[16:54:35] <rene_dev_> I think the hostmot stepgen pid should be fixed, so that this is not an issue anymore
[16:54:51] <rene_dev_> I can do it, and it is on my list of things...
[17:16:24] <pcw_home> You typically need I in a torque loop and this is where the time offset of command and feedback is an issue
[17:17:31] <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
[17:18:28] <pcw_home> the hostmot position mode should be fixed to use an internal PID loop and built in headroom but thats a fair project
[17:23:19] <rene_dev_> I know, but Im talking about position loops, as in the hostmot stepper
[17:24:41] <pcw_home> thats what I was talking about (the built in position mode is not very good)
[17:25:19] <rene_dev_> yes, but why, and why is it not fixed? :D
[17:26:37] <pcw_home> easy enough to work around (though it causes pain in suffering because of needlessly complex hal files)
[17:33:30] <pcw_home> plus there's a pretty big backlog of unsupported hostmot2 stuff/bugfixes in addition to the stepper position mode troubles
[17:41:48] <rene_dev_> which other backlog?
[17:42:33] <rene_dev_> yeah, its the complicated hal files, and the additional vel/acc setting that makes things complicated and confusing for new pepole
[17:44:49] <pcw_home> yeah the PID stepgen control works well but that and all the headroom nonsense are not good
[17:45:44] <pcw_home> backlog is new module support, some encoder bugfixes, encoder enhancements etc
[17:46:49] <rene_dev_> which module support? I already had some ideas how to make all the hostmot modules more flexible and modular
[17:47:47] <rene_dev_> what annoys me, is to add a new module, you have to add its functions all over the place
[17:48:37] <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
[17:49:20] <rene_dev_> https://github.com
[17:52:43] <rene_dev_> https://sigrok.org
[17:52:50] <rene_dev_> like this
[17:53:54] <pcw_home> yeah ist shoud be easier to add a new module (ultimately it would be better if the IDROM provided more metadata)
[17:54:34] <rene_dev_> something self describing like smart serial would be nice, but as a hostmot module only
[17:56:30] <pcw_home> Yes that would be really nice, Wish I had started that way...
[17:58:04] <pcw_home> module support: Inm/Inmux, 50% mode added to pwmgen, dpainter
[18:02:45] <rene_dev_> dpainter? for laser cutters?
[18:45:00] -!- KimK has joined #linuxcnc-devel
[18:48:29] <pcw_home> Yes, for motion synchronized data painting (either on/off or PWM)
[20:11:53] -!- mozmck_lp has joined #linuxcnc-devel
[20:18:58] -17WAA4YWT:#linuxcnc-devel- [13linuxcnc] 15c-morley commented on issue #514: Sorry I got busy...I have confirmed the error.... 02 https://github.com/LinuxCNC/linuxcnc/issues/514#issuecomment-439659999
[20:18:58] -17SAA2EAV:#linuxcnc-devel- [13linuxcnc] 15c-morley closed issue #514: pncconf error with units in fields 02 https://github.com/LinuxCNC/linuxcnc/issues/514
[20:19:04] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15c-morley reopened issue #514: pncconf error with units in fields 02 https://github.com/LinuxCNC/linuxcnc/issues/514
[20:34:27] -!- mozmck_lp has quit [Quit: Leaving.]
[20:51:54] -!- Roguish has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
[20:55:09] Tom_itx is now known as Tom_L
[20:56:52] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15rene-dev commented on issue #528: I got another bug reported: on prepare, the pocket numbers are delayed by one in the remap. No idea why the tests didnt catch that... 02 https://github.com/LinuxCNC/linuxcnc/pull/528#issuecomment-439661515
[21:18:33] -!- andypugh has quit [Quit: andypugh]
[21:43:55] <jepler> "that's another CAD of worms"
[21:48:03] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15c-morley pushed 1 new commit to 06master: 02 https://github.com/LinuxCNC/linuxcnc/commit/577b88c2bf4313f243373d73f7f24190392a94e7
[21:48:03] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06master 14577b88c 15Chris Morley: pncconf -fix scale/limits setting with different locales...
[21:49:37] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15c-morley commented on issue #514: Ok I pushed a fix for this to master.... 02 https://github.com/LinuxCNC/linuxcnc/issues/514#issuecomment-439663487
[22:24:41] <linuxcnc-build> build #2343 of 1520.rip-jessie-amd64 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[22:31:32] <jepler> 10.609: timeout waiting for joint 0 to stop at -1.000 (pos=0.000, vel=0.000)
[22:31:35] <jepler> hm spurious?
[22:31:39] * jepler frowns at linuxcnc-build
[22:32:10] <linuxcnc-build> build #5735 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org blamelist: Chris Morley <chrisinnanaimo@hotmail.com>