Back
[07:35:19] <KGB-linuxcnc> 03John Thornton 052.7 bf092f1 06linuxcnc 10docs/src/index.tmpl 10docs/src/index_es.tmpl Docs: fix links * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bf092f1
[07:35:19] <KGB-linuxcnc> 03John Thornton 052.7 c41b99e 06linuxcnc 10docs/src/user/user-intro.txt Docs: fix list using wrong markup * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c41b99e
[07:35:19] <KGB-linuxcnc> 03John Thornton 052.7 1380d4e 06linuxcnc 10docs/src/lathe/lathe-user.txt Docs: fix images * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1380d4e
[07:54:19] <skunkworks> halui: updatestatuss: status buffer is not valid
[07:56:34] <skunkworks> I think I may have confused it - swiching from one version to another it didn't close smoothly
[07:56:50] <skunkworks> cradek, is your 2.6 branch based on 2.7.7?
[07:56:57] <skunkworks> *2.6.7?
[08:02:29] <skunkworks> I think I am right - git describe is 9eeb266
[08:05:16] <skunkworks_> this is 2.7 with your first patch
[08:05:18] <skunkworks_> http://i.imgur.com/w7QkCJG.png
[08:05:59] <skunkworks_> ship it!
[08:06:02] <skunkworks_> ;)
[08:08:08] <skunkworks> that is around 1% overage.
[08:26:47] <cradek> skunkworks: unless I screwed up, my branch is on top of 2.6.9
[08:27:27] <cradek> yay for the 2.7 test improving
[08:30:35] <skunkworks> hmm
[08:37:07] <skunkworks_> skunkworks@skunkworks-Studio-XPS-1645:~/linuxcnc-2.6/src$ git describe
[08:37:08] <skunkworks_> v2.6.9-2-g9eeb266
[08:37:10] <skunkworks_> skunkworks@skunkworks-Studio-XPS-1645:~/linuxcnc-2.6/src$ git branch
[08:37:11] <skunkworks_> 2.6
[08:37:13] <skunkworks_> * cradek/2.6/bug430-fix
[08:37:14] <skunkworks_> master
[08:37:16] <skunkworks_> skunkworks@skunkworks-Studio-XPS-1645:~/linuxcnc-2.6/src$ linuxcnc
[08:37:17] <skunkworks_> LINUXCNC - 2.6.7
[08:37:28] <skunkworks_> I am saying this because I got a violation instantly...
[08:37:57] <skunkworks> *pretty instantly
[08:38:01] <skunkworks> bbl
[08:38:02] <cradek> I think you have to run configure again or something
[08:40:07] <cradek> are you sure you cleaned and rebuilt? it says 2.6.9 when I run it here.
[08:41:10] <cradek> 2.6 may give violations for other reasons :-/
[09:35:39] <skunkworks_> ok
[09:44:41] <skunkworks> ./autogen ./configure worked - now it says 2.9
[09:45:02] <skunkworks> 2.6.9..
[09:47:03] <cradek> yay
[10:25:13] <skunkworks> cradek, do you want to look at more violations in 2.6?
[10:26:15] <cradek> welllll
[10:26:33] <skunkworks> that was my thought.
[10:26:37] <cradek> I don't think there's much point
[10:26:46] <cradek> how bad is it?
[10:26:59] <skunkworks> 35.7 - should be 30
[10:27:13] <cradek> it was 38 before this change, right?
[10:27:19] <skunkworks> quite a few... no rotation
[10:27:40] <cradek> oh even without rotation? so this change doesn't matter.
[10:27:41] <skunkworks> that specific violation seems to be fixed
[10:28:06] <skunkworks> I was just running the whole gcode in 2.6.
[10:28:14] <cradek> ok, if it's an improvement I'll merge it and then whistle innocently about the rest of whatever you found
[10:28:22] <skunkworks> sounds good
[10:28:31] <cradek> "good"
[10:28:36] <cradek> thank you for testing
[10:28:41] <cradek> I appreciate all you do
[10:28:58] <skunkworks> no problem - again - I do what I can (and enjoy)
[10:30:12] <KGB-linuxcnc> 03Chris Radek 052.6 9eeb266 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9eeb266
[10:31:31] <skunkworks> I think that should be in 2.7 also..
[10:31:43] <cradek> yeah I'm pondering how to do that tricky merge
[10:31:52] <cradek> because the code's totally different
[10:32:15] <skunkworks> whole new commit? or does that screw things up?
[10:32:55] <cradek> yeah, it's that patch that's already written, I just have to trick git into knowing the "merge" is done
[10:33:04] <skunkworks> ah
[10:35:58] <cradek> hm docs conflicts too
[10:36:02] * cradek squints
[11:07:24] <jepler> that may be the doc conflict that made seb tableflip after the 2.6.9 release
[11:10:36] <seb_kuzminsky> that docs merge conflict was 2.7 -> master
[11:10:47] <jepler> h
[11:11:32] <cradek> I think I got it
[11:12:32] <cradek> it wasn't too bad, but merge conflict markers look just like asciidoc markup
[11:13:52] <KGB-linuxcnc> 03Chris Radek 052.7 72996a3 06linuxcnc 10src/emc/task/emccanon.cc fix constraints on rotated g18/g19 arcs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=72996a3
[11:13:52] <KGB-linuxcnc> 03Chris Radek 052.7 102dbf6 06linuxcnc 03docs/src/gcode/g-code.txt Merge branch '2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=102dbf6
[11:18:43] <seb_kuzminsky> thanks
[11:18:58] <seb_kuzminsky> i think that means we're ready for 2.7.0~pre7
[11:19:17] <seb_kuzminsky> and 2.7.0 a week or two later if we dont find any new show-stoppers
[11:21:31] <JT-Shop> I'm reading the docs from front to back looking for any obvious things that jump out at me
[11:23:58] <cradek> +|<<gcode:g92.3,G92.3>> |Restore G92 Offsets
[11:24:19] <cradek> JT-Shop: I noticed in this table's first column, the first g is little and the rest are big
[11:24:32] <JT-Shop> that is the link
[11:24:48] <JT-Shop> after the comma is the text that is displayed
[11:24:59] <cradek> ahhhh
[11:25:14] <cradek> thanks, I understand now
[11:32:33] <skunkworks_> damn impresssive speed increase..
http://i.imgur.com/nraQV26.png
[11:32:53] <skunkworks_> http://i.imgur.com/iQ2sYGC.png
[11:33:31] <skunkworks_> (taken at about the same point in time)
[11:33:51] <jepler> inifile z accel is 400 in both cases?
[11:34:23] <skunkworks_> yes
[11:34:31] <skunkworks_> 40,30,400
[11:34:32] <cradek> whee!
[11:34:56] <skunkworks_> even cheating - (higher acc)
[11:35:00] <skunkworks_> ;)
[11:38:03] <cradek> why oh why would you use a stepper motor for a spindle
[11:39:33] <jepler> cost, I assume
[11:40:53] <jepler> I'm confident somebody could write a component to interface between motion and a stepper spindle to get .index-enable and maybe orient
[11:40:57] <cradek> probably more like mistaken assumptions
[11:41:26] <jepler> but I have just about no interest in doing that, nor owning a test rig for it
[11:42:17] <jepler> > Position the watch hands to noon and put in the center of pizza
[11:43:14] <cradek> ha
[11:43:28] <cradek> I can spot a geektrap in one sentence
[11:43:38] <jepler> can you guess the question though?
[11:44:10] <jepler> (hm the question doesn't specify how to locate the watch in the right location... sub-problem ahoy)
[11:44:11] <cradek> how long until the hands describe three equal pizza portions?
[11:44:28] <jepler> actually this particular puzzle is to cut the pizza in 11 pieces
[11:44:37] <cradek> good grief
[11:44:57] <cradek> why noon and not midnight, I wonder
[11:45:18] <jepler> hmm it should say "12" and not "noon", shouldn't it
[11:45:34] <jepler> otherwise you'd have an uncommon watch marked in 24 hours and you'll end up with 23 pieces instead of 11
[11:45:40] <cradek> yes assuming it has a 12 hour display and that's what they mean
[11:58:41] * archivist stirs the stepper mud :)
[12:00:14] <archivist> I have never understood why some take the wrong path and doggedly stick to it
[12:00:16] <cradek> I hate these threads that are "I've already chosen all the hardware I want to buy, perhaps based on mistaken assumptions, and I won't say what I want this machine to actually do, but I want you to all validate my urges now"
[12:00:25] <cradek> yeah what he said
[12:06:19] <lerman> Are there any problems using manual toolchanger with MDI?
[12:07:09] <lerman> I do a T375 M6 and axis seems to hang. I don't see the tool change pop up. (2.6-pre).
[12:12:15] <linuxcnc-build> build #3343 of 1300.rip-precise-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/3343 blamelist: Chris Radek <chris@timeguy.com>, John Thornton <bjt128@gmail.com>
[12:12:26] <cradek> no problem that I know of
[12:12:40] <cradek> try 2.6.9
[12:12:41] <skunkworks> lerman, I don't know of any - but I cannot test at the moment - running a few hour long program
[12:13:10] <lerman> Thanks. I'll stare at my configuration some more.
[12:13:23] <linuxcnc-build> build #3345 of 1306.rip-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/3345 blamelist: Chris Radek <chris@timeguy.com>, John Thornton <bjt128@gmail.com>
[12:14:48] <seb_kuzminsky> *** warning: bad links found in English docs!
[12:16:29] <lerman> Found it --- axix_manualtoolchange.hal != axis_manualtoolchange.hal
[12:18:42] <seb_kuzminsky> heh
[12:20:26] <skunkworks> how did that even launch?
[12:38:41] <JT-Shop> seb_kuzminsky, is it ok to add this pin to the thc in 2.7?
[12:38:42] <JT-Shop> pin out float offset_value "The Current Offset";
[12:39:04] <JT-Shop> I thought I did a long time ago but you know how my memory is lol
[12:41:04] <JT-Shop> I've had that in my local copy for so long I forgot about it
[12:41:23] <JT-Shop> bbl
[12:41:27] <seb_kuzminsky> JT-Shop: probably, yeah
[12:41:28] <seb_kuzminsky> post the patch
[12:52:01] <linuxcnc-build> build #3354 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3354 blamelist: Chris Radek <chris@timeguy.com>, John Thornton <bjt128@gmail.com>
[13:00:41] <cradek> argh, did I mismerge?
[13:01:34] <skunkworks> come back from lunch to this!
[13:03:43] <cradek> -in G code use either <<sec:G10-L2_,G10 L2>> or <<sec:G10-L20,G10 L20>>.
[13:03:43] <cradek> +in G code use either <<sec:g10-l2,G10 L2>> or <<sec:g10-l20,G10 L20>>.
[13:03:45] <seb_kuzminsky> it's jt's G92 [NOTE]
[13:03:48] <cradek> is it this?
[13:03:52] <seb_kuzminsky> yeah
[13:04:00] <cradek> I'll fix it
[13:04:02] <seb_kuzminsky> did you see the docs build output?
[13:04:03] <seb_kuzminsky> thanks...
[13:04:26] <cradek> so I guess I did mismerge it
[13:04:34] <seb_kuzminsky> it's near the bottom of the build output and pinpoints the broken link
[13:05:26] <KGB-linuxcnc> 03Chris Radek 052.7 2f8493c 06linuxcnc 10docs/src/gcode/g-code.txt fix links broken by inattentive merger * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2f8493c
[13:05:42] <cradek> I guess I need to test-build docs if I touch them
[13:06:42] <jepler> linuxcnc-build: dance!
[13:06:42] <linuxcnc-build> What you say!
[13:06:45] <jepler> linuxcnc-build: dance
[13:06:46] <linuxcnc-build> <(^.^<)
[13:06:47] <linuxcnc-build> <(^.^)>
[13:06:48] <linuxcnc-build> (>^.^)>
[13:06:49] <linuxcnc-build> (7^.^)7
[13:06:50] <linuxcnc-build> (>^.^<)
[13:07:35] <seb_kuzminsky> cradek: eh, or let the buildbot do it for you
[13:18:49] <linuxcnc-build> build #3346 of 1306.rip-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/3346 blamelist: Chris Radek <chris@timeguy.com>
[13:19:50] <cradek> Chris Radek <chris> is complete: Failure
[13:19:59] <Roguish> hey all. question? lots of comments and questions lately about tool changes and carousels lately. Can't most all of that be done with Classic Ladder?
[13:20:08] <cradek> yep
[13:20:14] <linuxcnc-build> build #3344 of 1300.rip-precise-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/3344 blamelist: Chris Radek <chris@timeguy.com>
[13:20:20] <cradek> now ask me a harder one
[13:21:30] <Roguish> cradek: ok, thanks for confirming that. just wondering as I'm pretty sure that's how the regular machine manufacturers do it.
[13:22:37] <cradek> Roguish: there's a middle ground where it's too much trouble to learn ladder, instead of using just a bit more hal, and "a bit more" is iterative
[13:26:20] <Roguish> ladder is not hard, i would rather do that then go thru all the hal and comp and remap stuff. personal preference i guess.
[13:26:57] <cradek> yeah, the thing you know is easier than the thing you don't know, haha
[13:27:42] <Roguish> ok enough of that. what is the easiest way to get a pre-empt installed? i want to do it in a vm.
[13:28:15] <cradek> you can install from our cd and then just change the kernel
[13:28:23] <linuxcnc-build> build #1505 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1505 blamelist: Chris Radek <chris@timeguy.com>
[13:28:28] <cradek> linuxcnc-build: oh shhh
[13:30:27] <Roguish> now how the hell does one 'change a kernel'?????
[13:31:05] <cradek> why do you want this in a VM? it's going to be useless
[13:31:48] <Roguish> just to get used to the installation
[13:32:10] <mozmck> you generally install a kernel the same way you do any other package.
[13:32:13] <Roguish> and maybe do some sim work. and gui work
[13:32:40] <mozmck> But you don't need the preempt-rt kernel to do sim and gui work.
[13:33:19] <Roguish> yeah I know, but I'm going toward the ethernet boards.
[13:33:32] <mozmck> Just configure --with-realtime=uspace
[13:34:32] <cradek> we build wheezy/2.7-uspace packages
[13:34:36] <cradek> oughta use those
[13:35:03] <mozmck> ah, yes, even better
[13:35:20] <cradek> looks like they depend on the right kernel automatically
[13:36:04] <jepler> hm that's a bit weird if so
[13:36:21] <jepler> uspace should be usable in sim mode without requiring any particular kernel
[13:36:36] <mozmck> I do that all the time - so I know it works
[13:37:19] <cradek> oh it's a recommend
[13:37:36] <jepler> ah yes I see it now
[13:37:36] <jepler> EXTRA_RECOMMENDS="$EXTRA_RECOMMENDS, linux-image-rt-amd64 [linux-amd64], linux-image-rt-686-pae [linux-i386]"
[13:37:41] <cradek> Recommends: linuxcnc-doc-en | linuxcnc-doc, hostmot2-firmware-all, linux-image-rt-amd64
[13:42:30] <linuxcnc-build> build #3355 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3355 blamelist: Chris Radek <chris@timeguy.com>
[13:47:20] <jepler> this is the official documentation from us on how to install wheezy with the preempt-rt kernel
[13:47:23] <jepler> http://linuxcnc.org/docs/2.7/html/getting-started/getting-linuxcnc.html#_installing_on_debian_wheezy_with_preempt_rt_kernel
[13:48:13] <cradek> ok, from the basic debian cd
[13:48:16] <cradek> that's a fine way to do it
[13:48:20] <jepler> yes
[13:48:48] <jepler> I don't think there's a reason you *couldn't* start with our install media, but that may add a step of manually removing the rtai-targeted linuxcnc packages before you can install the uspace ones
[13:49:31] <seb_kuzminsky> if you specifically ask for linuxcnc-uspace, it'll automatically uninstall linuxcnc(-rtai) for you
[13:49:56] <Roguish> jepler: that's it. I had confidence it was doc'd somewhere. thanks.
[14:29:33] <skunkworks> ugh
http://www.cnczone.com/forums/controller-amp-computer-solutions/278780-software.html#post1744852
[14:49:35] <cradek> do people just not remember the password they type when it asks?
[14:49:47] <cradek> I have seen that before too and I don't understand it
[14:55:40] <skunkworks> I know going from ubuntu to wheezy - I didn't notice it was asking for my usename first.. :)
[14:56:03] <cradek> I prefer the login windows that show both username and password (dots) simultaneously
[14:56:12] <cradek> I don't understand why that's less popular today
[15:34:09] <seb_kuzminsky> task: 110 cycles, min=0.000010, max=7.342813, avg=0.145318, 3 latency excursions (> 10x expected cycle time of 0.001000s)
[15:34:12] <seb_kuzminsky> halui: emcCommandSend: no echo from Task after 5.000 seconds
[15:34:26] <seb_kuzminsky> what should we do about the buildbot sucking so much?
[15:34:38] <seb_kuzminsky> i could increase the halui echo timeout to 1 minute
[15:34:51] <seb_kuzminsky> i could add hardware to the buildbot & buildslaves
[15:35:01] <seb_kuzminsky> i could try to debug it and figure out why it sucks so much
[15:36:06] <seb_kuzminsky> linuxcnc-build: force build --branch=2.7 0000.checkin
[15:36:07] <linuxcnc-build> build forced [ETA 1h01m07s]
[15:36:07] <linuxcnc-build> I'll give a shout when the build finishes
[15:42:12] <seb_kuzminsky> the hypervisor seems fine, not running out of cpus or memory, not swapping
[15:49:48] <linuxcnc-build> build #3345 of 1300.rip-precise-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/3345
[15:51:33] <linuxcnc-build> build #3347 of 1306.rip-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/3347
[16:05:56] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 4d3ca5e 06linuxcnc 10docs/src/gcode/g-code.txt docs: fix links broken by inattentive ammender * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4d3ca5e
[16:21:31] <cradek> are you serious
[16:21:35] <cradek> that's amazing
[16:21:46] <seb_kuzminsky> ;-)
[16:21:59] <seb_kuzminsky> glad it's not just me
[16:22:18] <cradek> my mom always says it's the thought that counts
[16:24:14] <seb_kuzminsky> that's making me think of a line from the novel Troika, goes something like this: "Iron turns to rust when it decays, meat turns to maggots, and thoughts turn to words."
[16:25:02] <cradek> I should've asked for review ... oh wait I did :-)
[16:27:19] <cradek> when changing thoughts to words, we have to make our thoughts concrete and stable, which probably helps them become useful. on the other hand, we can only do this for thoughts we have the language to express, limiting us and making us vulnerable to those who can control the language. so you win some and lose some. I'm not sure it's simply decay.
[16:29:38] <linuxcnc-build> build #1506 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1506
[16:32:39] <seb_kuzminsky> that one failed because: task: 3905 cycles, min=0.000010, max=16.075283, avg=0.007337, 3 latency excursions (> 10x expected cycle time of 0.001000s)
[16:32:55] <cradek> wow 16 seconds is a long time
[16:33:15] <seb_kuzminsky> it's a gentle reminder not to run machine controllers in virtual machines, i guess
[16:33:23] <cradek> or anything
[16:33:54] <seb_kuzminsky> oh, also, the machine that's running that VM is currently trying to build linux 3.16+rtai (for jessie), with a huge -j
[16:33:55] <cradek> is a very long timeout a problem?
[16:34:23] <seb_kuzminsky> only when actually running a machine, i think, with a real human in front of it
[16:34:38] <cradek> why?
[16:34:42] <seb_kuzminsky> i think a long timeout would be fine for the tests
[16:34:57] <cradek> yeah I'm sure of that - I'm just wondering if it's bad for a user for some reason
[16:35:04] <seb_kuzminsky> i mean, if task goes out to lunch for 16 seconds while i'm using it to drive my bridgeport, it would be bad
[16:35:11] <cradek> but that's not my question
[16:35:24] <cradek> is a *timeout* of 5 vs 60 going to make any difference
[16:35:34] <seb_kuzminsky> if task stays well-behaved, long timeouts should never triger and never hurt users
[16:35:57] <cradek> sure
[16:36:02] <seb_kuzminsky> the delay-on-file-reload-while-in-estop problem (or whatever it was) might be waiting for one of those timeouts, i'm not sure
[16:36:07] <cradek> but but but
[16:36:18] <seb_kuzminsky> if so, having it take a minute or two would be much more annoying than 5s
[16:36:29] <cradek> oh I see
[16:36:33] <cradek> that is an answer to my question
[16:36:45] <seb_kuzminsky> oh good
[16:36:55] <cradek> if there's a bug in waiting/sending/whatever a short timeout might give you response back sooner
[16:37:31] <seb_kuzminsky> if there's a bug that makes it so axis has to wait for a timeout, making that timeout more annoying might provoke us into fixing the underlying bug so we dont have to wait so long
[16:37:35] <cradek> crap, gotta run
[16:37:40] <seb_kuzminsky> seeya
[16:37:42] <cradek> (true too)
[16:37:43] <cradek> bbl
[16:37:56] <linuxcnc-build> build #3356 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3356
[17:01:14] <linuxcnc-build> build #1507 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1507 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[17:14:54] <linuxcnc-build> build #3357 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3357 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[18:49:18] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 8781f62 06linuxcnc 10src/hal/user_comps/huanyang-vfd/hy_comm.c hy-vfd: better communication debug logging * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8781f62
[18:49:18] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 4a1b32c 06linuxcnc 10src/hal/user_comps/huanyang-vfd/hy_comm.c hy-vfd: fix bug with partial reads from VFD * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4a1b32c
[19:39:39] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 6b21783 06linuxcnc 10docs/man/man1/hy_vfd.1 hy-vfd: reflow manpage to not look like roff markup * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6b21783
[20:15:45] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 0b996db 06linuxcnc 10src/hal/user_comps/huanyang-vfd/hy_comm.c hy-vfd: remove a dead store * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0b996db
