Back
[07:33:55] <jthornton-> how do you add an apt source from the command line?
[07:34:50] <jthornton-> step 5 is missing something
http://linuxcnc.org/docs/2.7/html/getting-started/getting-linuxcnc.html#_installing_on_debian_wheezy_with_preempt_rt_kernel
[08:33:48] <jthornton-> and google says sudo add-apt-repository "deb...
[09:10:51] <KGB-linuxcnc> 03John Thornton 052.7 a0123bc 06linuxcnc 10docs/src/getting-started/getting-linuxcnc.txt Docs: clear up installing preempt-rt kernel * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a0123bc
[10:18:09] <jepler> PCW: I haven't done anything to try to induce errors yet, but I still get a bunch of error messages when I start my hal threads. also, I notice that in the pinout summary everything is still just an IOPort, apparently no ports were reserved for the sserial which is weird
[10:18:14] <jepler> http://pastebin.com/NJbHUH45
[10:19:21] <jepler> is 7i92 sserial thought to work, or is that something else that was never tested yet?
[10:21:18] <pcw_home> It should work (Ethernet sserial works fine)
[10:21:49] <pcw_home> power problem ?
[10:22:14] <jepler> I am using a 5V1A power supply into the 7i92, then cable-powering everything else
[10:22:40] <jepler> is there a good location on the 7i73 to check my voltage?
[10:24:49] <pcw_home> not sure, probably a regulator pin
[10:26:06] <pcw_home> It should not be very picky however ( its all 3.3V from a LDO regulator so should be OK down to 4V or so )
[10:26:12] <jepler> C18 near the RJ jack measures a good 5.01V on my meter. if it dips when starting linuxcnc, I don't see it on the readout
[10:26:46] <jepler> and C19 3.29v
[10:27:47] <jepler> shouldn't I expect that in the pinout that linuxcnc shows at startup, the pin use is not "IOPort" for all pins?
[10:28:34] <pcw_home> maybe signal integrity issue with cabling? whats between the 7I92 and 7I74?
[10:28:51] <jepler> ribbon cable under 1'
[10:31:13] <pcw_home> ribbon cables are not great for the 7I74 especially (50 pin/ 7I44 are fine, parallel port 25 pin pinout is not good)
[10:32:03] <jepler> I was hoping a short one would be OK. My junk box only turned up DB25 M-F cables so far, plus this cable.
[10:33:08] <pcw_home> did you compile the bitfile yourself?
[10:34:04] <jepler> yes, but starting with source from 7i92.zip, not hostmot2-firmware
[10:34:47] <pcw_home> i have a patched UART8 module that gets along with a 10 foot flat cable here
[10:35:26] <jepler> (I don't see any 7i74 firmwares in 7i92.zip anyway)
[10:35:36] <jepler> Ok, I can rebuild with that pretty easily
[10:36:14] <jepler> oh I see 7i92_7i77_7i74D.bit but I wonder if the 7i74 is on the right connector (I need it on P1 because of my cable limitations)
[10:37:20] <jepler> the detection step to find the 7i73 seems to work every time, which makes me want to think the cabling is fine
[10:38:06] <pcw_home> 7i77_7I74 means 7I77 onDB25, 7I74 on header
[10:38:44] <pcw_home> looks like it blew up in the detection part
[10:38:51] <jepler> oh it does?
[10:39:36] <pcw_home> the fact that the I/O pins are not marked as sserial suggests that to me
[10:40:12] <jepler> OK
[10:40:13] <jepler> Board hm2_7i92.0.7i73.1.0 Hardware Mode 0 = nokeyboardnodisplay
[10:40:36] <jepler> these lines, which seemed to be the same everytime, made me think it was doing something
[10:44:25] <pcw_home> yeah its working up to a point
[10:45:42] <pcw_home> Also those errors dont seem like the ones with noise issues
[10:47:38] <pcw_home> maybe try another sserial card (the 7I69 is also cable powered)
[10:48:34] <pcw_home> wonder what the remote fault was?
[10:50:06] <jepler> Board hm2_7i92.0.7i69.1.0 Hardware Mode 0 = mesa_pinout
[10:50:07] <jepler> ...
[10:50:30] <jepler> pins come up as all IOPort, then communication errors
[10:52:29] <pcw_home> but the no id error is only check at startup so it didn't get past that
[10:52:36] <pcw_home> checked
[10:53:27] <jepler> hm2/hm2_7i92.0: Smart serial card hm2_7i92.0.7i69.1.0 error = (14) No Remote ID
[10:53:30] <jepler> this one?
[10:53:44] <pcw_home> Yes
[10:56:09] <pcw_home> try channel 7
[10:59:55] <jepler> Board hm2_7i92.0.7i69.1.7 Hardware Mode 0 = mesa_pinout
[11:00:02] <jepler> moving the cable moves where the board is detected
[11:02:02] <pcw_home> so not sure if this is a SI issue with the flat cable or some generic problem
[11:03:05] <jepler> I assume with nothing connected the I/Os shold be TRUE ?
[11:03:46] <pcw_home> yes
[11:04:56] <jepler> .. I reverted sserial.c only to back before micges's error handling changes. I get no errors printed, including when I unplug the cable, but the I/Os all read as false
[11:05:42] <pcw_home> thats weird
[11:06:04] <pcw_home> updated files to improve SSLBPs RX UARTs noise immunity:
[11:06:05] <pcw_home> http://freeby.mesanet.com/uartr8.vhd
[11:06:07] <pcw_home> http://freeby.mesanet.com/sserialwa.vhd
[11:07:07] <jepler> on the 7i74 is CR2 some sort of activity indicator?
[11:07:12] <pcw_home> if its a flat cable SI issue, recompiling with these will fix the problem
[11:08:00] <pcw_home> CR2 is the enable on channel 7 (0..6 are RS-422 only, channel 7 can be RS-485)
[11:08:38] <jepler> OK, I see that light go on only during initialization
[11:09:48] <jepler> the same for CR3 on the 7i69
[11:10:08] <jepler> rebuilding my fw now
[11:11:38] <pcw_home> yeah it failed during initialization so reverted to GPIO
[11:12:53] <jepler> whatever point it's failing at, it's not saying anything at that moment
[11:13:04] <jepler> there's nothing that looks like an error between Board hm2_7i92.0.7i69.1.7 Software Mode 4 = bidir_encoder
[11:13:08] <jepler> and hm2/hm2_7i92.0: 34 I/O Pins used:
[11:13:09] <jepler> hm2/hm2_7i92.0: IO Pin 000 (P2-01): IOPort
[11:22:37] <pcw_home> Yeah without errors should be something like:
[11:22:38] <pcw_home> hm2/hm2_7i76e.0: IO Pin 010 (P1-07): Smart Serial Interface #0, pin TxData0 (Output)
[11:22:40] <pcw_home> hm2/hm2_7i76e.0: IO Pin 011 (P1-08): Smart Serial Interface #0, pin RxData0 (Input)
[11:31:10] <jepler> OK, good to know
[11:31:17] <jepler> that's with our 2.7 branch?
[11:31:32] <jepler> I'm committing a cardinal sin, which is changing multiple things at once
[11:31:49] <jepler> I have a theory that the problem is this: I am using a 2x7i74 config
[11:32:06] <jepler> the 26-pin connector is the 2nd 7i74, with nothing on the first one
[11:32:30] <jepler> in the hal driver we have this assumption that we always use the lowest-number instances of anything we use
[11:32:38] <jepler> I think that's confusing things
[11:33:05] <pcw_home> Yeah thats probably never been tried
[11:33:14] <jepler> so I'm also changing my pinout around at the same time as I'm putting in your noise-immune vhd files
[11:35:01] <pcw_home> Yeah thats 2.7
[11:36:20] <jepler> hm2/hm2_7i92.0: IO Pin 028 (P1-08): Smart Serial Interface #0, pin RxData7 (Input)
[11:37:12] <jepler> halcmd: addf hm2_7i92.0.read-request thread1
[11:37:12] <jepler> halcmd: rtapi_app: caught signal 11 - dumping core
[11:37:14] <jepler> umm that's not good
[11:40:29] <jepler> .. unrelated though
[11:40:54] <jepler> .. if you have started your threads already, adding .read-request crashes rtapi_app
[11:41:30] <jepler> halcmd: start
[11:41:34] <jepler> hm2/hm2_7i92.0: Num Auto = 1
[11:41:34] <jepler> hm2/hm2_7i92.0: Normal Start: Writing 00000000 to 5d1c
[11:41:34] <jepler> hm2/hm2_7i92.0: Tag-All = 80
[11:41:52] <jepler> and I have a blinking green light on the 7i69
[11:41:55] <jepler> so things seem better
[11:42:25] <jepler> yep it's communicating now
[11:43:37] <maxcnc> hi what is sai for that wont let me use GET_MASHINE_UNOFFSET_X
[11:43:49] <maxcnc> uninitializied
[11:44:01] <jepler> halcmd: setp hm2_7i92.0.stepgen.00.steplen 1000
[11:44:04] <jepler> halcmd: setp hm2_7i92.0.stepgen.00.control-type 1
[11:44:04] <jepler> halcmd: setp hm2_7i92.0.stepgen.00.enable 1
[11:44:04] <jepler> halcmd: setp hm2_7i92.0.stepgen.00.velocity-cmd 1000
[11:44:08] <jepler> hm2/hm2_7i92.0: Smart serial card hm2_7i92.0.7i69.0.7 error = (13) Communication error
[11:44:21] <jepler> OK, and I think I can provoke the problem
[11:45:27] <maxcnc> jepler: we like this ->error = (13) Communication error
[12:38:43] <jepler> PCW: do I have to do some kind of register write to clear a fault bit?
[12:41:20] <pcw_home> No, but communication errors (bit 13) should be cleared every DOIT
[12:41:22] <pcw_home> and only set when a new communication error occurs
[12:43:36] <pcw_home> remote errors are ( only to be checked when bit 8 is set) are mostly fatal so should probably only be reported once
[12:50:04] <jepler> on the hal side what I think I'm seeing is that some error bits get set (e.g., 0x...09) but that same error value 0x...09 is read every time after that
[12:50:10] <jepler> cs register changed 0x00000000 -> 0x003b0000
[12:50:10] <jepler> cs register changed 0x003b0000 -> 0x00420000
[12:50:13] <jepler> halcmd: setp hm2_7i92.0.stepgen.00.enable 1
[12:50:26] <jepler> cs register changed 0x00420000 -> 0x00422009
[12:50:26] <jepler> hm2/hm2_7i92.0: [it 7311] Smart serial card hm2_7i92.0.7i69.0.7 error = (13) Communication error
[12:50:29] <jepler> hm2/hm2_7i92.0: [it 7311] Smart serial card hm2_7i92.0.7i69.0.7 error = (3) Timeout
[12:50:32] <jepler> hm2/hm2_7i92.0: Smart Serial Error: port 0 channel 7. You may see this error if the FPGA card read thread is not running. This error message will not repeat.
[12:50:35] <jepler> hm2/hm2_7i92.0: [it 7312] Smart serial card hm2_7i92.0.7i69.0.7 error = (13) Communication error
[12:50:38] <jepler> hm2/hm2_7i92.0: [it 7312] Smart serial card hm2_7i92.0.7i69.0.7 error = (3) Timeout
[13:02:40] <pcw_home> does bit 13 stay set ?
[13:08:16] <jepler> yes, it looks that way
[13:08:23] <jepler> I put a raw read on the register
[13:08:23] <jepler> setp hm2_7i92.0.raw.read_address 0x5d1c
[13:09:47] <jepler> halscope is not too useful for binary-encoded values, but I can see that it says the same thing as my debug prints: the register reads as 0x00420000 until a fault occurs, then it changes to 0x00422009 until the fault limit is hit. then it reads 0x0000C100
[13:21:01] <jepler> afk
[13:50:00] <pcw_home> AFAIK bit 13 is cleared every doit and only set if a new error occurs
[15:00:48] <jepler> *inst->command_reg_write = 0x1000 | inst->tag;
[15:01:08] <jepler> it looks like the driver is still sending a doit command as long as the limit isn't hit
[15:03:32] <pcw_home> it should ( and whether it should ever stop is somewhat questionable )
[15:07:39] <jepler> this clear of the error register is something that's happening in the embedded microcontroller's program?
[15:08:13] <pcw_home> Looking at the SSLBP code Bit13 is set on any detected error but cleared every doit
[15:08:59] <pcw_home> almost all bits but 13 are sticky
[15:13:09] <jepler> I do see your comment
[15:13:10] <jepler> ;minorrevision 22
[15:13:15] <jepler> ;chanerror is cleared at start or doit
[15:13:55] <pcw_home> if bit 13 is not behaving this way its a bug, and the workaround is to not interrogate
[15:13:56] <pcw_home> the error bits unless you get transfer failed error (a 1 bit in the data register for the affected channel)
[15:13:58] <pcw_home> I think micges said this was done in 2.6
[15:14:33] <pcw_home> its hard to tell without generating just one error
[15:14:35] <jepler> can I easily check just to make sure my firmware's minor revision is above 22?
[15:14:59] <jepler> (and that was a long time ago, these sources have you at minorrevision 42)
[15:15:02] <pcw_home> theres nothing that old floating around
[15:15:07] <jepler> OK
[15:15:42] <jepler> hm2/hm2_7i92.0: Smart Serial Firmware Version 43
[15:16:04] <jepler> this number? OK, I guess I don't have an old version then
[15:17:14] <jepler> well I'd better figure out how to capture the right packets to prove whether I'm sending a doit after the error
[15:17:17] <jepler> afk again
[15:17:37] <pcw_home> No, I think anyone updating to 2.7 will get upgraded to 43 because they will likely have
[15:17:39] <pcw_home> old remotes that need updating and only SSLBP >V35 knows how to upgrade remote firmware
[15:18:24] <pcw_home> and linuxcnc 2.7 complains about the remote version if old (<14)
[17:56:03] <JT-Shop> I wonder if I move the 7i77 out of the drive cabinet my sserial errors will go away?
[18:00:25] <pcw_home> Theres something funny about your situation since a limit switch closure triggers an error
[18:00:26] <pcw_home> ( different than say people with a Estop --> contactors dropping out causing a error )
[18:01:22] <pcw_home> did you try grounding the 24V common?
[18:05:13] <JT-Shop> I don't think I have
[18:06:47] <JT-Shop> pcw_home: did you get my email from today?
[18:07:07] <pcw_home> let me check
[18:14:58] <jepler> pcw_home: 81c2 005b 8010 0000 is writing DOIT, isn't it? in this tcpdump it looks like LinuxCNC sends DOIT at 17:25:11.114077 after error bits are set in the packet at 17:25:11.114038
[18:15:02] <jepler> http://paste.debian.net/367457/
[18:15:27] <jepler> error bits still set in the packet at 17:25:11.115039
[18:23:07] <pcw_home> Hmm thats surprising, is it possible there are more than one error generated?
[18:27:31] <pcw_home> If that is the case, the error reporting should only check errors after a transfer failure (1 in data register )
[18:27:33] <pcw_home> and I will see if I can find where bit 13 gets set without a new error
[18:37:55] <JT-Shop> I grounded the 24v power supply 0v and still get sserial error when either contacting the switch or the reversal
[18:40:25] <pcw_home> very strange
[18:40:25] <JT-Shop> I can not duplicate it just hitting the limit switch or rapid back and forth with the MPG it only happens during homing
[18:41:05] <JT-Shop> indeed strange
[18:41:09] <pcw_home> Is there a servo drive thump during homing?
[18:41:21] <JT-Shop> let me try an listen
[18:41:31] <pcw_home> ( is is homing to index? )
[18:44:29] <JT-Shop> there is a little bit of a thump listening with a stethoscope
[18:45:13] <pcw_home> thats probably not significant
[18:45:15] <pcw_home> Do you have a 6 foot DB 25 cable?
[18:46:51] <JT-Shop> I've not set home to index although I probably should
[18:47:00] <JT-Shop> yes a 6' DB25 cable
[18:48:40] <pcw_home> Not sure why you have so much trouble with this
[18:48:42] <pcw_home> dont you have a plasma system with a 7I76? I would expect this to be noisier
[18:50:39] <JT-Shop> yes the plasma is using a 7i76
[18:50:53] <JT-Shop> and I've never had a sserial error on it
[18:51:22] <pcw_home> I guess I would try moving things around ( 2.7 should get fixed so it can mask occasional errors)
[18:51:43] <JT-Shop> servos must not have the index hooked up... I need to rewire them to bring the differential out to the 7i77
[18:51:44] <pcw_home> I wonder is its a bad 5I25/7I77/cable
[18:52:09] <JT-Shop> I have stock on them now so I can swap it and see
[18:59:11] <JT-Shop> swapped DB25 cables and got sserial error on first axis homing
[19:01:44] <jepler> pcw_home: I am injecting 1000ns glitches but not sure of the frequency. I have this block in my hal:
[19:01:47] <jepler> setp hm2_7i92.0.stepgen.00.steplen 1000
[19:01:50] <jepler> setp hm2_7i92.0.stepgen.00.control-type 1
[19:01:52] <jepler> setp hm2_7i92.0.stepgen.00.velocity-cmd 1000
[19:02:46] <pcw_home> hmm not sure what the default stepgen scaling is
[19:03:51] <jepler> position-scale 1, maxaccel 1, so at full blast it would be going at 1kHz but that would take over 10 minutes. the glitch happens typically in under a minute, so it should be << 1 glitch per packet
[19:04:31] <jepler> glitch0 <= StepGenOut(0)(0);
[19:04:38] <jepler> ...
[19:04:39] <jepler> SSerialRX(conv_integer(ThePinDesc(i)(23 downto 16)))(conv_integer(ThePinDesc(i)(3 downto 0))-1) <= IOBits(i) or glitch0; -- 16 max ports
[19:04:51] <jepler> I am OR'ing the stepgen into the sserial rx value in the fpga
[19:05:30] <jepler> these communication errors don't happen (or at least not in 10s of minutes) unless I also enable that stepgen
[19:06:01] <pcw_home> OK I see thats theres an error (all the bits are sticky)
[19:06:03] <pcw_home> The code that clears bit 13 and 8 on a doit is not used
[19:06:04] <pcw_home> so basically it means you have to mask error checking with transfer failure
[19:06:56] <pcw_home> I will fix for version 44, but for now a transfer failure has to mask the error checking
[19:07:21] <pcw_home> ( which is what micges said )
[19:07:32] <jepler> if (*inst->data_reg_read & 0xff) { // indicates a failed transfer
[19:07:37] <jepler> that is this check here?
[19:07:50] <pcw_home> Yes
[19:08:59] <jepler> OK, I think I can switch the logic around to check for failed transfer first
[19:09:03] <pcw_home> and all failures need to go through the inc/dec/threshold filter (except remote faults which should only be reported once)
[19:09:42] <jepler> you want the threshold to be met before any reporting of the local communication fault
[19:10:06] <pcw_home> yes
[19:10:09] <jepler> ok
[19:10:11] <jepler> hm2/hm2_7i92.0: hm2_sserial_waitfor: Timeout (24mS) waiting for addr 5d1c &mask ff00 val 2000
[19:10:28] <jepler> one more problem I've seen, after glitching, sometimes subsequent startup is failing
[19:10:46] <jepler> I have been recovering by mesaflash --reload
[19:11:31] <pcw_home> thats an odd one
[19:12:12] <jepler> anyway I'll see if I can't track that down too
[19:12:18] <pcw_home> the sserial system can be reset
[19:12:37] <jepler> maybe should do that at startup then
[19:13:33] <pcw_home> we have found a few hangs over the years ( V44 may even fix that one )
[19:14:23] <pcw_home> ;added inc chanclrfaultcount to not stick in loop
[19:15:08] <pcw_home> I think the regmap file has the reset instructions
[19:15:56] <pcw_home> "when cooperative multitasking doesn't"
[19:18:52] <pcw_home> unfortunately I probably should have sent a 7I84 or something thats easy to generate a remote fault with
[19:22:31] <pcw_home> so faults should be counted but not reported unless they meet the inc/dec/threshold filter criteria
[19:22:32] <pcw_home> the exception being remote faults which are should only be reported once
[19:25:15] <jepler> https://emergent.unpythonic.net/files/sandbox/fault-count.png
[19:25:19] <jepler> hey now we're making some progress
[19:26:01] <jepler> a few glitches here and there, but it recovers; then I double the glitch rate and it's enough to make it fault over the next 100ms or so
[19:28:07] <pcw_home> Yay!
[19:28:09] <pcw_home> it used to work like that we ran a 8I20 with about a 10% data error rate and you could hardly tell
[19:37:00] <jepler> a remote error should immediately fault?
[19:38:24] <pcw_home> Probably just be reported and perhaps a hal flag set (but only once)
[19:40:03] <pcw_home> Not sure how much low level error handling should dictate policy
[19:40:58] <pcw_home> currently its a bit extreme (shutting off all channels even if the error is just in one channel)
[19:43:02] <pcw_home> but it may be too much work to make the error processing be per channel (and might the change hal interface as well)
[19:47:16] <jepler> do I have a good way to provoke a remote error?
[19:59:36] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes11 6119f5e 06linuxcnc 10src/emc/nml_intf/canon.hh canon.hh init rotary_unlock_for_traverse (JA) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6119f5e
[19:59:36] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes11 4a8945c 06linuxcnc 10configs/sim/axis/canterp.ini canterp.ini: make sim runnable (joints_axes) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4a8945c
[20:08:14] <pcw_home> unfortunately no (you can do it with a 7I84,7I76,7I77 by shorting an output driver or too low/too high field voltage)
[20:15:24] <jepler> > halcmd: setp hm2_7i92.0.stepgen.00.maxaccel hm2/hm2_7i92.0: Smart Serial Error: port 0 channel 7. You may see this error if the FPGA card read thread is not running. This error message will not repeat.
[20:15:28] <jepler> errr
[20:15:32] <jepler> > hm2/hm2_7i92.0: Smart Serial Error: port 0 channel 7. You may see this error if the FPGA card read thread is not running. This error message will not repeat.
[20:15:37] <jepler> I mean to call attention to this part of the error
[20:16:01] <jepler> this does get printed the first time an error occurs. should I also move it to where the eventual fault occurs, instead of where it is now?
[20:17:34] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler opened issue #31: hm2_eth: crash after addf read-request interactively 02
https://github.com/LinuxCNC/linuxcnc/issues/31
[20:17:40] <jepler> if the FPGA read function is really not running, it'll trigger very shortly anyway..
[20:17:48] <jepler> I don't understand the condition that leads to this line at all
[20:18:06] <jepler> if (*inst->data_reg_read & 0xff) { // indicates a failed transfer
[20:18:09] <jepler> f = (*inst->data_reg_read & (comm_err_flag ^ 0xFF));
[20:18:11] <jepler> if (f != 0 && f != 0xFF) {
[20:25:02] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/hm2-sserial-faults 2a9ce6f 06linuxcnc 10src/hal/drivers/mesa-hostmot2/sserial.c hostmot2: sserial: work around sticky error reporting * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2a9ce6f
[20:25:02] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/hm2-sserial-faults b65ea52 06linuxcnc 10src/hal/drivers/mesa-hostmot2/sserial.c hostmot2: sserial: add notes about interpreting fault bits * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b65ea52
[20:25:03] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/hm2-sserial-faults 1c79002 06linuxcnc 10src/hal/drivers/mesa-hostmot2/sserial.c hostmot2: sserial: fix off-by-one error in error reporting * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1c79002
[20:25:05] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/hm2-sserial-faults f5f6c14 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.h 10src/hal/drivers/mesa-hostmot2/sserial.c 10src/hal/drivers/mesa-hostmot2/sserial.h hostmot2: sserial: split error checking into local, remote * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f5f6c14
[20:25:11] <jepler> I'm stopping here for the night
[20:25:42] <jepler> JT-Shop, pcw_home: if you test with this branch, please let me know whether it's an improvement over the status quo. I'll read back.
[20:25:52] <jepler> or you can comment on
https://github.com/LinuxCNC/linuxcnc/issues/27
[20:26:05] <jepler> now time to play a video game
[21:29:36] <skunkworks> http://www.cnczone.com/forums/emco-lathe/186598-machinist-software-4.html#post1824158
[21:44:07] <jepler> :)
[21:46:34] <skunkworks> Glad it is working for him.
[21:47:22] <jepler> http://www.core77.com/posts/45416/Reverse-Engineering-From-a-Drawing-an-18th-Century-Frame-Carving-Machine
[21:57:17] <skunkworks> neat
[22:07:09] <jepler> Subject: [ANNOUNCE] 4.4-rt3
