Back
[06:59:46] <skunkworks> m:\
[06:59:50] <skunkworks> heh
[11:44:12] <KGB-linuxcnc> 03jepler 05master 32460b2 06linuxcnc 10docs/man/man3/rtapi_module_param.3rtapi * document the interpretation of MODULE_LICENSE strings
[11:44:12] <KGB-linuxcnc> 03jepler 05master 8bf2bf6 06linuxcnc 10docs/src/hal/comp.txt * Fix MODULE_LICENSE strings, refer to our documentation of their interpretation
[11:44:15] <KGB-linuxcnc> 03jepler 05master 198b45e 06linuxcnc * Merge branch 'v2.5_branch'
[12:09:17] <andypugh> I see that the hardy builds triggered by my last push failed. Is that my fault? Looking at the logs it looks like an apt-get failure of the buildbot?
[12:18:27] <cradek> yeah, it's not your fault
[12:31:20] <Tom_itx> the bot just didn't wanna take blame
[12:41:07] <linuxcnc-build> build #1017 of deb-hardy-rt-binary-i386 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-hardy-rt-binary-i386/builds/1017 blamelist: Jeff Epler <jepler@dsndata.com>
[12:41:35] <linuxcnc-build> build #1015 of deb-hardy-sim-binary-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-hardy-sim-binary-amd64/builds/1015 blamelist: Jeff Epler <jepler@dsndata.com>
[12:43:43] <linuxcnc-build> build #1014 of deb-hardy-sim-binary-i386 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-hardy-sim-binary-i386/builds/1014 blamelist: Jeff Epler <jepler@dsndata.com>
[13:27:11] <IchGuckLive> hi why is there a linuxcnc3 channel setup
[13:27:42] <jepler> anyone can create any channel for any reason.
[13:28:16] <IchGuckLive> ok thanks jepler good work as always you do apriciate :D
[13:28:27] <IchGuckLive> By
[14:22:13] <cradek> cmorley: I think andypugh is right that JR1050 is making the mistake of asking for a solution (incorrect solution based on misunderstandings) instead of asking for the best way to solve his problem
[14:22:42] <cradek> stopping motion for a tool change, including spindle orient, is utterly common -- and has nothing to do with feedhold and needs no new feedhold-related features
[14:22:54] <cradek> he is mistaken that he's the first one to retrofit a real machine :-)
[14:25:42] <cradek> andypugh: also - if you need orient for a tool change, that should be handled in the tool change logic, and whether there's an m code that also does it is irrelevant
[14:25:54] <cradek> there are all sorts of ways machines orient their spindles
[14:26:21] <cradek> mine uses a mechanical stop plunger, two sensing switches, and a "creep with low torque" function of the vfd
[14:26:42] <cradek> the sequencing is done in ladder as part of the tool change (while the carousel turns!)
[14:26:43] <andypugh> True enough, and M19 in a remapped G-code is probably superflous if it is a tool-change
[14:27:23] <cradek> you might want an orient m-code for other reasons (withdrawing a boring bar is one possibility I can think of)
[14:28:19] <cradek> but for a tool change sequence, talk about m19 and/or feedhold is just a misunderstanding
[14:30:50] <pcw_home> seem like it would be better to have less policy set in "motion", not more
[14:30:54] <pcw_home> seems
[14:31:33] <andypugh> This is more an interpreter thing. The machine _can't_ interpret G-code when tool-changing.
[14:31:50] <andypugh> (Unless the tool change itself is G-code anyway)
[14:32:01] <andypugh> The program is by definition halted.
[14:32:51] <cradek> yes the whole series of questions is based on wrong turns along the line
[14:34:45] <cradek> I actually have a spindle orient (and lock in place and vfd disable) toggle switch on the console of jr, and I use it to tighten my albrecht chuck
[14:35:27] <cradek> would also be smart to use it while the probe is loaded
[14:36:41] <pcw_home> Pretty sure I figured out the encoder bug
[14:36:42] <pcw_home> its probably always been there but masked by the fact that most
[14:36:44] <pcw_home> FPGA cards are configured at linuxcnc startup so all counter registers
[14:36:45] <pcw_home> start at 0. This is no longer true with the 5I25/6I25 etc
[14:38:29] <cradek> yay!
[14:39:12] <pcw_home> Not sure but believe the strange behavior related to linking
[14:39:13] <pcw_home> rawcounts to a signal is because of the bi-directional nature of rawcounts
[14:40:00] <pcw_home> probably the encoders should be cleared at startup
[14:40:01] <andypugh> In which layer is rawcounts bidirectional?
[14:40:43] <pcw_home> not sure i just noticed in encoder.c, the hal pin goes both ways
[14:42:24] <pcw_home> I think its all just aesthetic but someone on the forum complained about
[14:42:25] <pcw_home> random positions at startup (before homing)
[14:46:27] <skunkworks> I think I use m100 and m101 for spindle orient. (plus it does it when the tool gets changed..)
[14:46:36] <skunkworks> (pre m17)
[14:46:49] <skunkworks> and I use it for probing
[14:47:24] <pcw_home> The positions are not really random, they are scaled (encoder count mod 2^16)
[14:47:26] <pcw_home>
[14:47:52] <skunkworks> the spindle comp does it. I think there is a Lock, is_locked pins
[16:08:28] <cradek> my machine also won't do a tool change unless Z is on the home switch, since that means the head is up all the way in tool change position. it would break the arm otherwise. that is another good example of the things you can do in a toolchange ladder (or hal logic) but makes no sense in the motion controller.
[16:09:24] <cradek> then before it signals that the tool change is done (letting the gcode motion continue) the sensor that shows the arm is back in its home position must be true
[16:09:42] <cradek> otherwise the arm would not last but a second...
[16:10:52] <skunkworks> bang!!
[16:13:45] <andypugh> cradek: Ye be preaching to the choir...
[16:14:21] * cradek shrugs
[16:14:44] <cradek> cmorley is here too, and I don't think he's currently a member of our choir
[16:15:39] <skunkworks> I don't think I am setup as safe as I could be. But I have don't quite a bit of machining on the k&t with no suprises.
[16:16:15] <cradek> some of mine is redundant. tool change position puts the head up automatically - but why not hardwire it to be sure, it's important
[16:16:26] <skunkworks> sure
[16:16:39] <cradek> (I moved the home switch a bit to make that possible)
[16:16:41] <skunkworks> I think - like most things - hey it works