Back
[00:00:45] <jepler> * jepler just ran two 10000-line programs using "step from start" and all was well
[00:00:59] <jepler> .. so it must be fixed this time
[00:01:01] <cradek> yay!
[00:01:09] <cradek> ship it
[00:01:12] <jepler> heh
[00:01:36] <jepler> I also discovered a problem with the new hostmot2 drivers that was fixed by another "accept any version" change
[00:01:52] <jepler> (encoders are version 3 since they got the probe latch input, but 2.3 expected version 2)
[00:02:45] <jepler> so with any luck I'll package up 2.3 tomorrow
[00:03:40] <cradek> sadly I saw a bug with tool_change_quill_up the other day, but I haven't been able to reproduce it
[00:03:45] <cradek> it went 'up' diagonally
[00:03:49] <jepler> ugh
[00:03:53] <cradek> I think I had jogged, then MDI a tool change
[00:04:01] <jepler> ugh
[00:04:20] <cradek> one of those where the interp's current position was out of date but it didn't know to reread it
[00:04:39] <cradek> affects 2.3 of course
[00:04:48] <cradek> let me try some more right now
[00:04:53] <jepler> ok
[00:04:54] <jepler> I'll bbl
[00:05:12] <jepler> thanks for investigating
[00:09:12] <cradek> nope I can't make it do it
[00:09:22] <cradek> wonder if it's related to wheel jogging
[00:24:12] <cradek> curses, I can't make it happen
[00:28:01] <jt-plasma> want me to try I seem to have a knack for fouling things up lately
[00:28:37] <cradek> if you can figure out how to do it that'd be great
[00:28:43] <cradek> I know it's lurking
[00:28:51] <jt-plasma> LOL
[00:29:02] <cradek> I'm pretty sure I aborted a program run, then jogged, then MDI T1M6
[00:29:08] <cradek> I have a quill up AND a tool change position
[00:29:21] <jt-plasma> 2.4?
[00:29:23] <cradek> I *think* it "quill upped" to the spot above where the program aborted
[00:29:32] <cradek> instead of straight up above the jogged position
[00:29:40] <cradek> yes very recent 2.4 branch
[00:30:53] <jt-plasma> ok, I'll see if I can make it do the same
[00:31:06] <cradek> thanks!
[00:33:43] <jt-plasma> three digits for tool change position?
[00:34:15] <cradek> yes something-something-zero
[00:53:00] <jt-plasma> cradek: unable to make the unexpected happen... I must be on a turn around
[01:04:01] <cradek> darn - thanks for trying
[01:04:06] <cradek> I don't understand it.
[04:11:48] <jepler> wow, the glade people must never do normal everyday things like diff what glade writes from one run to the next. who can tell what chris morley was up to in this commit based on the diff of pncconf.glade? git show a50bdd835ce53580cfe49edc7729e4a01a1f8395
[04:11:52] <jepler> I sure can't.
[04:17:26] <CIA-89> EMC: 03jepler 07master * r7f606f5c6164 10/docs/src/gcode/main.lyx: Add info about M2
[04:17:26] <CIA-89> EMC: 03jepler 07master * r80c77cbe0329 10/src/emc/usr_intf/pncconf/pncconf.py: fix loading of 2 mesa boards in HAL file
[04:17:29] <CIA-89> EMC: 03jepler 07master * r002f67acd8d8 10/src/emc/usr_intf/pncconf/pncconf-help/ (4 files): Update help pages
[04:17:29] <CIA-89> EMC: 03jepler 07master * ra50bdd835ce5 10/src/emc/usr_intf/pncconf/ (pncconf.glade pncconf.py): servo test, mesa test panel and spindle pwm settings
[04:18:25] <CIA-89> EMC: 03jepler 07master * r6725cc0b0515 10/src/emc/usr_intf/pncconf/pncconf.py: Adjust default baseperiod and HAl command changes
[04:18:28] <CIA-89> EMC: 03jepler 07master * r7a573b887820 10/src/configure.in: Fix 'checking for ANSI C header files... no' with --enable-simulator
[04:18:28] <CIA-89> EMC: 03jepler 07master * rdabaefef9a23 10/src/emc/usr_intf/emcsh.cc: fix typos on interp messages
[04:18:29] <CIA-89> EMC: 03jepler 07master * rcfdf63fdd905 10/src/ (9 files in 5 dirs): Merge branch 'v2.4_branch'
[04:18:30] <CIA-89> EMC: 03jepler 07master * ra55ee00007bd 10/src/hal/halmodule.cc: let Python programs determine sim vs rt
[15:41:52] <CIA-89> EMC: 03jepler 07v2.4_branch * r4959c8d45957 10/src/configure.in: let c/c++ know the required kernel version
[15:41:53] <CIA-89> EMC: 03jepler 07v2.4_branch * r2c5ed60c481b 10/src/hal/halmodule.cc: let python know the required kernel version
[15:41:53] <CIA-89> EMC: 03jepler 07v2.4_branch * rf06bcc026070 10/src/hal/drivers/probe_parport.c: fix naming conflicts with parport_pc
[15:52:13] <Guest307> Guest307 is now known as skunkworks_
[16:36:05] <cradek> jepler: both jthornton and I tried to reproduce the quill-up diagonally problem, and didn't. but, I know it's there.
[16:37:13] <cradek> I think the position sync happens when switching auto/manual/mdi task modes. I couldn't come up with a way to move the machine manually then issue an mdi command without causing a sync between them. can you?
[16:37:55] <cradek> I bet it's wheel jogging that does it, but it seems disabled in all but task=manual (free planner) modes
[16:39:50] <cradek> oh I just thought of something I didn't test: run program, abort somewhere, wheel jog, run program starting with TxM6
[16:40:04] <cradek> i.e. don't involve mdi
[16:40:14] <cradek> I will try it later (wrong computer here)
[16:41:51] <jepler> maybe one of rfl or start-with-step misses synch?
[16:42:30] <cradek> also good idea
[16:42:48] <cradek> bbl, warrior needs food badly
[16:45:58] <jepler> see you
[16:51:37] <micges> JT-Hardinge: hi
[16:52:24] <micges> JT-Hardinge: one thing before I forgot: on devel manual on relatime components page, on pwmgen part there is typo
[16:52:38] <JT-Hardinge> micges: hi
[16:52:53] <micges> on both example commands should be 'halcmd loadrt pwmgen output_type='
[16:59:11] <micges> but on second example there is 'step_type='
[17:07:25] <JT-Hardinge> ok, thanks micges
[17:07:46] <micges> np
[18:17:53] <CIA-89> EMC: 03jthornton 07master * refbbae8a1c4d 10/docs/src/hal/rtcomps.lyx: fix typo
[18:17:56] <jepler> argh I broke it
[18:18:34] <jepler> (r2c5ed60c481b /src/hal/halmodule.cc: let python know the required kernel version)
[18:20:27] <CIA-89> EMC: 03jthornton 07master * re7f847bd6ab8 10/docs/src/config/stepconf.lyx: markup fixes and add info on E-Stop
[18:21:14] <jthornton> jepler: do I need to do anything extra to add these to 2.4?
[18:23:52] <jepler> jthornton: yes. for changes that are for 2.4 and master, you should make them on v2.4_branch; they'll be made on master later when I merge v2.4_branch into master.
[18:24:11] <jthornton> ok, I though I was on 2.4 :/
[18:24:15] <jepler> since you made those changes on master, you have to cherry-pick to get them on v2.4_branch
[18:24:33] <jepler> (or I can, if you like)
[18:25:14] <jthornton> if you can that would be nice I don't have a clue to the syntax and hate mess things up
[18:25:24] <jepler> OK, I'll do that
[18:26:02] <jthornton> Ok, it says I've checked out v2.4 now :)
[18:26:20] <jthornton> * jthornton gets back to trouble shooting the hardinge
[18:27:40] <CIA-89> EMC: 03jepler 07v2.4_branch * r2c7e6d1a08fb 10/src/hal/halmodule.cc: Fix sim build failure introduced in 2c5ed60c481b
[18:27:40] <CIA-89> EMC: 03jepler 07v2.4_branch * rd6aa1bf14c27 10/docs/src/hal/rtcomps.lyx: fix typo
[18:27:41] <CIA-89> EMC: 03jepler 07v2.4_branch * rc21d6e314fed 10/docs/src/config/stepconf.lyx: markup fixes and add info on E-Stop
[18:31:30] <cradek> jepler: I think AXIS's interpreter isn't getting the tool information. when I load comp311.ngc I expect to see two paths separated by the radius of T4, which is nonzero. I don't see the offset path though. When I run it, I do get two separate paths.
[18:31:39] <jepler> cradek: ugh
[18:32:16] <cradek> v2.4.0-pre1-14-gdabaefe fwiw
[18:43:23] <jepler> cradek: I agree
[18:43:42] <jepler> GET_EXTERNAL_TOOL_TABLE()
[18:43:42] <jepler> get_tool 4 (4, 0.0, 0.0, 1.2729999999999999, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.20100000000000001, 0.0, 0.0, 0)
[18:43:46] <jepler> 4 0.000000 0.000000 1.273000 ... 0.201000 ...
[18:43:53] <jepler> but the debugging statements I added look plausible
[18:44:19] <cradek> is 0.201 the diameter there?
[18:44:29] <jepler> yes
[18:45:31] <jepler> so GET_EXTERNAL_TOOL_TABLE in gcodemodule.cc is getting plausible numbers
[18:49:09] <JT-Hardinge> jepler: the 5i20 card is bad, I swapped out with my plasma to verify
[18:49:30] <CIA-89> EMC: 03cmorley 07v2.4_branch * rf394f6c259e4 10/src/emc/usr_intf/pncconf/pncconf.py: Fix some conditional checks / spelling typos
[18:52:24] <jepler> cradek: it has something to do with determining what tool to use
[18:52:24] <jepler> g41 d4 g1 y4
[18:52:27] <jepler> ^^^^ works
[18:53:22] <jepler> Interp::convert_cutter_compensation_on is using find_tool_pocket in the case that d is specified, otherwise it uses 0 which axis reports as empty
[18:53:27] <cradek> maybe settings->tool_table[0] isn't filled out when a tool is loaded?
[18:53:37] <cradek> ok
[18:53:52] <cradek> I wonder what's supposed to do that...
[18:54:05] <jepler> I'll look some more after food
[18:54:10] <cradek> thanks
[18:54:19] <cradek> also, I finally reproduced the other thing
[18:57:24] <cradek> load and run comp311.ngc, wait until it gets to line 14 (a long move), hit escape, jog down in Y a ways, click line 20 and 'run from here', expect it to go up and then to tool change position, but instead it goes diagonally somewhere strange, then to tool change position
[18:58:34] <cradek> heck you don't even have to jog
[18:59:23] <cradek> ^ this is running a configuration with TOOL_CHANGE_QUILL_UP and TOOL_CHANGE_POSITION
[18:59:55] <cradek> (I don't know if I was using rfl when it bit me irl)
[19:00:29] <cradek> I'm off to do some real work
[19:00:39] <cradek> (thanks again jepler)
[19:06:36] <jepler> it seems like sai has the same behavior
[19:07:53] <jepler> er, no, I take it back .. sai is OK
[19:08:26] <jepler> and we are testing that: ./ccomp/lathe-comp/test.ngc:g41
[19:21:06] <jepler> in milltask there's a call to Interp::synch after a toolchange. that's when 0 gets loaded with the right info
[19:21:44] <jepler> #0 0x00007fb3f44a583e in Interp::load_tool_table (this=0x626e40)
[19:21:44] <jepler> at emc/rs274ngc/rs274ngc_pre.cc:629
[19:21:44] <jepler> #1 0x00007fb3f44a5aa0 in Interp::synch (this=0x626e40)
[19:21:44] <jepler> at emc/rs274ngc/rs274ngc_pre.cc:1165
[19:21:46] <jepler> #2 0x00000000004067a0 in emcTaskPlanSynch () at emc/task/emctask.cc:405
[19:22:09] <jepler> there's nothing like that in axis, and it doesn't do iotask-like manipulation of the 0th slot either
[19:25:33] <jepler> (how's that work, anyway?)
[19:32:25] <jepler> er, no; I'm back to thinking cutter comp doesn't work in sai
[19:42:27] <CIA-89> EMC: 03cmorley 07master * rd7e43a00b28e 10/src/emc/usr_intf/pncconf/ (pncconf.glade pncconf.py): Revert "servo test, mesa test panel and spindle pwm settings"
[19:44:39] <jepler> cradek: yes, it did get broken when random_toolchange got merged
[19:45:09] <jepler> 14b8248a3917512e7ed6ced766e5c032c5397119 is good; 5fa491d570d9619f295a9fab593a8b2446c4e18d is bad
[22:44:21] <cradek> jepler: ffff!
[22:53:55] <jepler> so the interpreter always uses the inifile value to determine random toolchanger
[22:54:14] <jepler> but axis always acts like a nonrandom toolchanger
[22:54:45] <cradek> oh is that the problem?
[22:55:01] <jepler> I thought I'd fixed it by making interp_convert use index = settings->current_pocket but that fails to preview on axis with a random toolchanger configuration
[22:55:07] <jepler> so probably it's wrong for actual random machines too
[22:55:32] <cradek> you mean cutter comp doesn't actually work on random machines?
[22:55:55] <jepler> no, I mean that my change broke actual work on random machines
[22:56:06] <cradek> oh ok
[22:56:37] <jepler> I think that this *plus the ability to have axis run in nonrandom mode* may fix it:
[22:56:38] <cradek> (good - still many weeks to 2.4.0 deadline)
[22:56:41] <jepler> +++ b/src/emc/rs274ngc/interp_convert.cc
[22:56:43] <jepler> @@ -1800,7 +1800,7 @@ int Interp::convert_cutter_compensation_on(int side, //!< side of path cutte
[22:56:47] <jepler> }
[22:56:49] <jepler> } else {
[22:56:51] <jepler> but I was too tired to do the second thing (new canon call and all)
[22:56:53] <jepler> if(block->d_flag == OFF) {
[22:56:56] <jepler> - index = 0;
[22:56:58] <jepler> + index = settings->random_toolchanger ? 0 : settings->current_pocket;
[22:58:34] <cradek> if you made the new canon call would the interp use that instead of reading the ini directly?
[22:59:20] <cradek> (it reads the ini directly for other things, maybe all of which are layer violations)
[23:05:06] <cradek> yuck, retract plane in diameter mode seems wrong when retract is along X
[23:37:23] <CIA-89> EMC: 03cmorley 07v2.4_branch * r84b4ba051c84 10/src/emc/usr_intf/pncconf/pncconf.py: fix tests to tell you when they wont work without rt