Back
[01:38:29] <steve_stallings> steve_stallings is now known as steves_logging
[06:59:18] <micges_work> good morning all
[07:17:49] <alex_joni> hi
[08:40:53] <CIA-8> EMC: 03micges 07joints_axes3 * r8d3b5368caeb 10/src/emc/motion/control.c: Fix preloading free mode planner to avoid ferror on enabling
[10:53:37] <CIA-8> EMC: 03micges 07joints_axes3 * r78bdafcf4d61 10/src/emc/motion/control.c: Avois small joint move when enabling motion
[11:42:54] <micges_work> alex_joni: in
http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=src/emc/motion/teleop-notes;h=079041cb35a1e5f8978499a7e0eaf261709f8cac;hb=646e3506a5a4f71e8a11cbe0d9c185a3dbd37544
[11:43:48] <micges_work> in coord mode, free mode planner must be preloaded, it means to set that planner current pos to actual?
[11:45:49] <micges_work> other words preload is set planner in state that after enabling it there is no move?
[11:54:34] <CIA-8> EMC: 03micges 07joints_axes3 * rc8716de03f33 10/src/emc/motion/control.c: Fix preloading free tp on coord->free switch to avoid ferror
[12:27:30] <alex_joni> micges_work: yes
[12:34:01] <micges_work> jepler: execvp() works correctly in v2_3_branch
[12:35:15] <micges_work> jepler: execvp() patch works correctly in v2_3_branch ;)
[12:54:46] <jepler> micges_work: thank you for testing
[12:56:35] <micges_work> np
[12:57:53] <CIA-8> EMC: 03jepler 07v2_3_branch * rd32c346ce50b 10/ (debian/changelog src/emc/task/emctaskmain.cc): fix hang for M1xx code that cannot be executed (SF#2836077)
[13:26:25] <CIA-8> EMC: 03micges 07joints_axes3 * r8a47eb60bbf4 10/src/emc/motion/control.c: Improve soft limit checks to report which joint and limit they are exceeded
[13:37:11] <CIA-8> EMC: 03micges 07joints_axes3 * r093e05a41145 10/src/emc/motion/control.c: Avoid flood of messages when exceed soft limit
[14:03:12] <micges_work> bbl
[14:36:57] <cradek> I have several situations where hal/ladder can detect that either a requested prep or tool change shouldn't start, or did not finish correctly. One example is if it detects the drawbar doesn't hook properly. Right now it just "never finishes" so emc's execution doesn't go on. I'd like there to be a better way to signal an error/abort, but what?
[14:37:53] <jepler> what would you like to have happen?
[14:37:54] <skunkworks> some sort of setable timeout? after x amount of time - throw a error?
[14:38:05] <skunkworks> or toss an error
[14:38:30] <jepler> is this drawbar thing something the operator could correct and continue from, or will it be stop - fiddle - rfl?
[14:40:01] <cradek> abort the program, go to estop, anything is fine - just don't continue - don't make me shut down emc to get it to function again
[14:40:30] <cradek> there's the TC and prep loopbacks. maybe there could be two responses - success and error?
[14:40:57] <jepler> and it would be like an abort?
[14:40:59] <cradek> another error condition is no air pressure
[14:41:09] <cradek> so I guess some of them could be recovered
[14:41:18] <cradek> sorry, I'm not sure what I want
[14:41:21] <jepler> I'm not sure if you're asking what should be added to emc to make this natural, or for a hackish way to get what you want?
[14:41:30] <cradek> one sec
[15:53:43] <cradek> jepler: I think what I want is this: I can tell io/task that the requested thing failed. Program execution stops. io/task stops waiting for the confirmation signal and goes to a sane state so I can run the program again.
[15:59:58] <cradek> currently I think there is no way to recover from an unsuccessful prep or tool change
[16:00:38] <CIA-8> EMC: 03jepler 07master * reee44ba41b9f 10/scripts/emc.in: shorten the error message in this case
[16:00:51] <jepler> is one "toolchanger failed" input enough? how will the toolchanger know when it's OK to stop asserting the error condition?
[16:01:23] <cradek> I don't know
[16:01:55] <cradek> I think it does not make sense for a prep and tc to happen at the same time, so they could both use the same error input.
[16:02:03] <jepler> or maybe the toolchanger could assert "prepared" or "changed" + "abort"
[16:02:22] <cradek> we talked about the loopback handshaking -- if there is a separate "and it didn't work" input, the same handshaking would work I think
[16:02:36] <jepler> I can believe that
[16:02:44] <cradek> yeah I think that's what I typed too
[16:03:05] <jepler> so if prepare failed, you assert prepare-error and prepared, until you see prepare go false again
[16:04:14] <cradek> yes that sounds right
[16:04:44] <cradek> (is it time to kill iotask yet?)
[16:06:21] <micges> cradek: I've started killing it ;)
[17:32:48] <robh> cradek, i have had that same problem to when intergrating auto changer on error call back to emc. as if i was to call a tool that does not exsist i can not reject it very easy only try and find it or give a finish signal right back to get out tool changer loop
[18:05:33] <cradek> robh: that's a case I hadn't considered.
[18:29:15] <jepler> hm, can iocontrol not show operator messages?
[18:33:28] <mshaver> I can tell you, that on a Yasnac MX-1 (a Fanuc like control), that if something in the tool changer process doesn't happen (like the arm not finishing its swing) the whole thing just hangs up until you push "stop". Then, it's absolute hell trying to convince it that it should move the toolchanger back to a known good state. There's a whole complicated procedure...
[18:33:47] <mshaver> Anything better than that is progress!
[18:34:18] <cradek> mshaver: M21! M23! M24!
[18:34:30] <cradek> mshaver: (I saw this)
[18:35:01] <cradek> mshaver: it does it if you don't put the table in the right place before the tool change. It is too dumb to move the table, but smart enough to know the arm will smash into it
[18:35:26] <cradek> ... and also too dumb to stop before it gets halfway through the tool change
[18:38:21] <mshaver> cradek: yep, that's the sequence! Sometimes it takes a couple passes through for it to get happy again...
[18:39:29] <cradek> those pages in the manual were well-used
[18:47:09] <skunkworks> cradek: was the control on the jr a fanuc?
[18:48:48] <cradek> it was a yasnac like mshaver is talking about
[18:50:01] <skunkworks> heh - I scanned over what matt wrote and saw the 'fanuc' and not 'like control'
[19:22:13] <CIA-8> EMC: 03jepler 07master * re1a968ae8f34 10/docs/man/man3/ (hal_param_new.3hal hal_pin_new.3hal): fix prototypes for several functions