Back
[09:57:56] <kwallace> Has anyone had any issues with using a sound card and latency. We were trying to use pcspkr, but I recall a latency issue and it turns out we can't hear it anyway.
[10:07:18] <jepler> I've never tried to run audio on a machine that was doing realtime
[10:08:02] <jepler> some people have reported that the console beep would cause realtime latency, because accessing the speaker's I/O port causes a SMI (it's emulated by smbios)
[10:09:22] <jepler> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?TroubleShooting#PC_speaker_module_pcspkr
[10:13:39] <kwallace> In the early days, I got used to disabling pcspkr, but it looks like this became part of the normal install. maybe?
[10:13:55] <jepler> not to my knowledge
[10:13:56] <pcw_home> Ive seen that (backspacing into the left margin generate a console beep)
[10:14:36] <pcw_home> And I think its just pcspkr not sound cards
[10:15:21] <kwallace> We are looking into having a beep when a pendant action occurs.
[10:15:25] <pcw_home> so probably only on old MBs without built in sound
[10:16:17] <cradek> consider putting the beeper in the pendant? machines are very unreliable at having beepers at all today.
[10:16:34] <cradek> I had to add them to the last batch of machines I put together - there is no beeper on the motherboard, but there is a connector for it
[10:19:03] <kwallace2> Crud, my ISP reboots just before 8:00.
[10:23:54] <cradek> tool length probing on my collet-based machine is really nice
[10:25:06] <kwallace2> This is the pendant:
http://www.tormach.com/uploads/images/Gallery/products/milling_accessories/controllers_and_cables/30616_Shuttle_Jog_Controller_lg.jpg , so my options are limited.
[10:28:07] <kwallace2> cradek, do you have a link for your tool probing setup?
[10:31:47] <cradek> nope, it's just a switch mounted to the table
[10:41:19] <seb_kuzminsky> kwallace2:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=rss;f=configs/sim/axis/remap/manual-toolchange-with-tool-length-switch
[10:44:18] <kwallace2> I had a hell of a time getting manual (dowel pin), probe and tool setter touch-off coordinated. Some bits are in machine units, others in workspace. I ended up losing the task.
[10:46:28] <seb_kuzminsky> there's definitely plenty of room for confusion in the interaction of setting all the different kinds of offsets
[10:47:10] <kwallace2> BTW, I got my pcDuino and Raspberry Pi a couple of days ago.
[10:47:50] <kwallace2> They are sooo trendy.
[10:55:44] <jepler> I'm waiting to hear whether hm2_eth works with the cubieboard. if so I might pick up one of those.
[10:56:27] <PetefromTn_> cradek Did you make your table mounted tool length probe or buy it?
[10:56:33] <cradek> oh I made it
[10:56:39] <PetefromTn_> nice
[10:57:06] <cradek> it's an engraving spindle so all the tools are about the same length and they're generally fairly pointy
[10:57:08] <PetefromTn_> I am working on a design for my Cincinatti using a short length of linear shaft and a linear bearing. Might I inquire as to how yours is setup
[10:57:12] <cradek> so it's very simple to poke a switch
[10:57:29] <PetefromTn_> oh then this is not on your VMC....
[10:57:37] <cradek> heh my setup is as simple as possible
[10:57:37] <cradek> no
[10:57:49] <PetefromTn_> thats good I like simple.
[10:58:26] <cradek> aha I do have a picture of it,
http://timeguy.com/cradek-files/emc/tool-length-sensor.jpg
[10:58:34] <cradek> don't laugh
[10:58:37] <cradek> it works *great*
[10:58:54] * archivist giggles
[10:58:58] <cradek> heyyyy
[10:59:26] <PetefromTn_> WOW now that is next gen there hehe
[10:59:26] <archivist> some microswitches have specifications some dont
[10:59:42] <PetefromTn_> ;)
[10:59:53] <cradek> it's more repeatable than you'd expect
[11:00:01] <PetefromTn_> I don't doubt that.
[11:00:21] <PetefromTn_> do you have some sort of probing routine that you have programmed to touch off
[11:00:25] <cradek> it probes fast and then slow
[11:00:32] <cradek> happens automatically on m6
[11:00:46] <PetefromTn_> so is this in remap?
[11:00:48] <cradek> yes
[11:00:51] <PetefromTn_> nice
[11:01:10] <PetefromTn_> how do you handle your tool length in the code?
[11:01:11] <cradek> goes up, waits for you to hit ok on the manual tool change dialog, then probes and writes the length to the tool table
[11:01:27] <cradek> uses plain old g43 like normal
[11:01:42] <PetefromTn_> wow thats cool
[11:01:55] <PetefromTn_> is this on your five axis little maxnc?
[11:02:03] <cradek> yeah
[11:02:13] <cradek> I'm usually using it in 3 axis mode lately
[11:02:29] <PetefromTn_> that must be the most state of the art tiny homebuilt mill in the galaxy
[11:02:53] <cradek> the delrin antibacklash nuts are very good
[11:03:03] <cradek> it's a surprisingly useful machine for one you can carry around yourself
[11:03:06] <PetefromTn_> seriously..
[11:03:12] <PetefromTn_> delrin nuts?
[11:03:32] <cradek> yeah, on acme leadscrews
[11:03:59] <kwallace2> I have had my probe fail to re-conduct or make after break a few times. It comes to mind that some contacts need to have enough current going through them to keep them clean.
[11:04:04] <PetefromTn_> how did you cut the nuts?
[11:04:15] <cradek> I didn't, I bought them
[11:04:21] <jepler> fwiw omron D2FS-FL-N (microswitch with hinge lever) gives its operating point as +-1.2mm, which is obviously a much looser tolerance than cradek depends on for his TLS
[11:04:37] <jepler> I think these are the delrin ntus:
http://www.dumpstercnc.com/
[11:05:05] <kwallace2> Nut forming by blow torch and bench vise?
[11:05:16] <cradek> jepler: that doesn't seem like the right measurement at all. sounds like that's among many switches
[11:05:26] <jepler> cradek: yes
[11:05:35] <jepler> cradek: I think you hit the nail on the head
[11:05:37] <cradek> kwallace2: no, they were surely cut and they have springs
[11:05:48] <PetefromTn_> I am working on a design that uses a housing that the linear bearing bolts on top of.
[11:06:14] <PetefromTn_> then the linear shaft will have a collar with a flange on it screwed to the bottom
[11:06:26] <cradek> yes they are something like this:
http://www.dumpstercnc.com/images/1_2-8_2_Start_ACME.jpg
[11:06:28] <PetefromTn_> The shaft will be spring loaded upwards with gentle pressure.
[11:06:56] <PetefromTn_> in the base there will be a metal plate with the ground contact on it isolated on top of some kinda plastic isolators
[11:06:58] <kwallace2> Sorry, I wasn't referring to the link, but recalling a thread a while back.
[11:09:48] <cradek> http://timeguy.com/cradek-files/emc/M-x-doctor.png
[11:09:54] <cradek> I wonder what caused this to happen
[11:10:02] <PetefromTn_> http://i.imgur.com/2nupbPb.jpg something like this..
[11:10:45] <cradek> fancy
[11:10:51] <PetefromTn_> not really.
[11:11:02] <cradek> well, compared to mine...
[11:11:28] <PetefromTn_> It is just a base with a spring, a short length of linear shaft, a linear bearing and a tophat to keep shit out of the linear bearing probably made from delrin or something.
[11:11:58] <archivist> I is the FEATURES =n in a release yet?
[11:11:59] <PetefromTn_> I have the bearing and shafting here already just got sidetracked on machining the base.
[11:12:32] <PetefromTn_> not entirely sure how best to isolate the ground plate from the body of the base and hold it securely.
[11:13:04] <PetefromTn_> was considering machining the base from phenolic plastic but it is pretty expensive.
[11:13:17] <PetefromTn_> not even entirely sure the damn thing will work really.
[11:13:52] <PetefromTn_> was it difficult to setup the auto probing routine that kinda stuff is NOT my strong suit.
[11:14:08] <cradek> there's a sample
[11:14:14] <cradek> iirc, I simplified it a lot
[11:14:28] <cradek> the example seemed overcomplicated
[11:14:41] <PetefromTn_> I saw your video with the VMC and touch screen and probing etc. etc. That setup is the cats ass man. Well done.
[11:14:56] <cradek> yeah that's the retrofit I'm most proud of
[11:15:02] <cradek> it's really quite good
[11:15:21] <PetefromTn_> I don't have a touch screen interface but I would really enjoy auto tool touch off and probing at some point in the future.
[11:15:43] <PetefromTn_> do you have the auto tool touch off on that VMC too?
[11:16:52] <cradek> nope
[11:17:23] <PetefromTn_> The HAAS machines I ran had the auto tool length probing and spindle remote probing and damn that is nice stuff. All renishaw of course but makes setups a breeze and just insert tool and hit go for the most parrtt
[11:17:24] <cradek> manually measured to a 123 block sitting on the table
[11:17:32] <PetefromTn_> that is exactly how I do it now.
[11:17:47] <cradek> it's quite easy and fast
[11:18:07] <PetefromTn_> I have the G59.3 location at the back rear corner of the table and just MDI that and then load tool and touch off with MPG
[11:18:08] <cradek> I come down past a dowel diameter and use the wheel to move up until the dowel rolls under it
[11:18:17] <cradek> yep
[11:18:24] <cradek> touch off to fixture works nice for that
[11:18:39] <PetefromTn_> is that what you use.
[11:18:41] <cradek> fwiw,
http://timeguy.com/cradek-files/emc/manual_change.ngc
[11:19:05] <cradek> then the ini has: REMAP=M6 modalgroup=6 ngc=manual_change
[11:19:12] <cradek> it's so simple
[11:19:59] <cradek> G30 is over the switch of course
[11:20:16] <PetefromTn_> G38.2 must be the probe callout then
[11:20:26] <cradek> yep
[11:20:40] <cradek> #5063 is the Z value of the probed position
[11:20:48] <cradek> #5400 is the loaded tool
[11:20:49] <Connor> So, How do you determine the OFFSET length of your touch off switch?
[11:21:14] <cradek> by setting the G59.3 coordinate system's origin in the right place
[11:21:18] <PetefromTn_> you can measure from the table top I guess
[11:21:23] <cradek> (but it doesn't really matter much)
[11:21:43] <PetefromTn_> as long as they are all referenced to the same point it does not I guess
[11:21:49] <cradek> yeah
[11:22:01] <PetefromTn_> whichever tool you touch off with to the part will reference the rest
[11:22:04] <cradek> I like tool lengths to be as small as possible, and ideally negative
[11:22:46] <Connor> I'll have to play with them..
[11:22:54] <Connor> What about when you touch off to stock?
[11:23:01] <Connor> do you use the probe for that too ?
[11:23:04] <cradek> looking at the tool table, they tend to be 0.1 - 0.2
[11:23:08] <PetefromTn_> probably uses a round dowel pin like I do.
[11:23:38] <PetefromTn_> unless you have a spindle probe carefully setup.
[11:23:43] <cradek> on my vmc I use the probe. on max I use the shank of whatever 1/8 engraving tool is handy
[11:23:43] <Connor> I use the sheet of paper trick when doing V bits..
[11:24:02] <cradek> try rolling a known diameter under it while moving up
[11:24:09] <cradek> it's MUCH better than moving down to touch something
[11:24:18] <PetefromTn_> yes exactly
[11:24:22] <cradek> much much much
[11:24:30] <PetefromTn_> I use a .625 ground dowel pin
[11:24:40] <cradek> you can feel the rolling thing accelerate as it gets closer to rolling under, because of the round shape
[11:25:02] <PetefromTn_> jog down in .01 until it does not go under and then switch to .0001 until it just slides under
[11:25:44] <cradek> yep you don't even have to see closely to do it, it's a good thing to do by feel
[11:26:04] <PetefromTn_> yes agreed.
[11:26:17] <PetefromTn_> altho a spindle probe would be beauty
[11:26:39] <PetefromTn_> you have a renishaw?
[11:31:26] <cradek> yes on the vmc
[11:31:36] <cradek> it's great
[11:31:53] <cradek> but the battery is always dead if you use it infrequently
[12:21:30] <Connor> anyone looked into that remap bug that guy found the other day? Were when using remap, if you STOP a program.. it'll jump down into the g-code file somewhere and run a few lines before stopping ?
[12:21:46] <Connor> could cause a major problem for someone.
[12:24:39] <seb_kuzminsky> yeah that sounds really bad :-(
[12:24:49] <seb_kuzminsky> and no, i havent tried to debug it :-(
[12:25:15] <seb_kuzminsky> https://sourceforge.net/p/emc/bugs/394/
[12:25:38] <Connor> Yea.. for some reason the STOP isn't purging the path queue when remap is involved..
[12:26:55] <Connor> seb_kuzminsky: I replicated the issue in a 2.7 master release as well.
[12:27:09] <Connor> with stock rack-toolchange sim and a custom one I wrote.. both do it.
[12:28:11] <seb_kuzminsky> yeah, sounds like a bug deep in the remap code
[12:28:17] <seb_kuzminsky> can't say i'm totally surprised
[12:28:27] <seb_kuzminsky> (remap is the same in 2.6 and master)
[12:34:26] <Connor> seb_kuzminsky: Looks like he "included" a fix.. but.. broke the ability for the on_abort..
[12:36:07] <seb_kuzminsky> i dont understand that statement
[12:37:32] <Connor> In the bug.. the reporter commented out some lines.. that fixed the behavior.. but, now the on_abort is no longer executed.. (the cleanup scripts for remap)
[12:41:56] <seb_kuzminsky> oh, i see
[12:42:24] <seb_kuzminsky> yes, right, that's certainly the wrong fix, but it helps narrow down where the bug and the proper fix belong
[13:42:23] <skunkworks> logger[psha],
[13:42:23] <logger[psha]> skunkworks: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-10-02.html
[14:24:42] <PCW> 3KHz for ~20 hours so far with G3258 (5 stepgens)
[14:28:18] <PCW> So if you have to go through lots of code to do I/O
[14:28:19] <PCW> ( Preemt-RT full network stack ) _lack_ of speed kills :-)
[14:30:34] <skunkworks> neat!
[14:32:37] <jepler> oh if you've set it up right it only enters estop
[14:32:48] <jepler> saying "kills" is being a bit hyperbolic
[14:37:59] <jepler> not at all the message we want our users to hear either
[15:02:16] <PCW> Sorry, got a bit excited...
[15:04:48] <PCW> the bad parts is that now a size-able portion of the time is in the 7I80 code so I need to see if I can improve it some
[15:21:26] <micges-dev> current output form limited jerk jogging:
http://ibin.co/1cNZjVN8wTtu
[15:24:02] <PetefromTn_> https://www.youtube.com/watch?v=uYnBKLXCG6A
[15:29:50] <PCW> 4 KHz seem to run OK but sometimes has RT errors at startup
[15:36:51] <PCW> micges-dev: thats impressive even with the little glitch, has to be a lot gentler on hardware
[15:51:51] <jepler> PCW: when you say 'in the 7i80 code', do you mean in the d16 code?
[15:52:11] <jepler> PCW: or you mean in the hal realtime thread?
[15:52:21] <brianmorel99> When you guys say 4KHz that means you are running 0.25 milli-second base thread? Am I doing the math / terminology right? ( 2KHz = 0.5 ms , 3KHz = 0.33 ms )
[15:52:33] <jepler> brianmorel99: yes
[15:52:57] <jepler> brianmorel99: though these systems have just one thread, not two threads like with software step generation
[15:54:10] <brianmorel99> Is there any benefit of running a faster thread than say 1ms for a simple 3 axis step machine (hardware stepping) ? I assume this is more of a stress testing situation?
[15:56:37] <jepler> street cred?
[16:02:59] <jepler> right now, the pulse rate of a stepper output changes instantaneously from the old speed to the new speed (no acceleration between servo cycles). pushing the servo cycle faster means that these velocity jumps become smaller.
[16:03:15] <jepler> though pcw has also rumbed about adding acceleration within the hostmot2 stepgen itself
[16:04:29] <PCW> higher rates are mainly useful for closing the loop on torque mode servo drives
[16:05:30] <PCW> 1KHz is fine for most step/dir systems unless you have very high accel rates
[16:06:28] <PCW> (or requirement for very high accuracy at high accel rates)
[16:06:47] <micges-dev> PCW: indeed it is WAY more gentle at much higher accels
[16:07:31] <PCW> should make servo tuning/performance better also
[16:10:24] <PCW> brianmorel99: I really want to be sure there's enough margin even at 1 KHz
[16:10:37] <PCW> really really
[16:13:42] <PCW> jepler: I need to 'scope my 7I80 debug pins to see where the time is going
[16:13:43] <PCW> looks like now there's about a 100 usec + jitter readtime (send request/get response)
[16:14:31] <PCW> need to see how much of that is 7I80 parse time vs wire time
[16:14:45] <PCW> (and linux network stack time)
[16:15:34] <brianmorel99> Well, I think it's great that your fulley testing it. I just put the last coat of paint on the new workbench, so the mill and lathe are getting mounted tonight. Hopefully some steppers will go on by the weekend.
[16:15:54] <PCW> thats for 5 stepgens, encoder 6 analog outs on 7I83 7I76 DIO
[17:17:51] <jepler> oh linuxcncrsh
[17:17:53] <jepler> who will debug you?
[17:29:46] <skunkworks> so.. I am setting up m19 for spindle orient. (was using m100/m101) It doesn't really say but it seems R is a required word. (no error - just doesn't do anything)
[17:30:53] <skunkworks> I would think that R should be required - the docs say it defaults to 0.
[17:31:01] <skunkworks> *shouldn't
[17:31:20] <skunkworks> which is fine if you are just using it for a mechanical lock.
[17:33:13] <skunkworks> but M19R0 does seem to work. which is still nicer than M100/M101 as m3,4,5 disable it now. (that is cool)
[18:22:43] <PCW> skunkworks 1 hour at 4 KHz
[18:23:53] <PCW> w/youtube playing
[18:33:53] <skunkworks> PCW, Awesome!
[18:34:27] <skunkworks> so - ethernet should work well with non velocity mode amps.,.,
[18:35:26] <skunkworks> with the right computer hardware :)*
[18:36:25] <PCW> Yeah fast
[18:37:31] <PCW> at 4 KHz I do get real time delays sometimes at startup but not never when running (so far)
[19:06:55] <jepler> it would be nice to do something about that
[19:07:07] <jepler> I wonder if the first N periods should just not have realtime delays reported
[19:07:13] <jepler> where N is << 1 second of time
[19:16:10] <skunkworks> does it keep reporting them in dmesg?
[19:17:18] <skunkworks> the j1900 has been running 2khz for a while now
[19:17:26] <jepler> skunkworks: yes, but what I took pcw to mean is that they show up at the start or not at all
[19:21:32] <skunkworks> right - I was just wondering when linuxcnc says it only reports it once.. if it keeps sending subsequent ones to dmesg
[19:24:58] <jepler> it's uspace, so nothing goes in dmesg at the moment
[19:26:21] <skunkworks> oh - so how does he know he isn't getting anymore delays?
[19:26:50] <PCW> Sometime its starts without error
[19:27:01] <jepler> skunkworks: the terminal
[19:27:05] <skunkworks> oh
[19:27:07] <skunkworks> ok
[19:27:34] <skunkworks> I have never really paid attention to that.
[19:27:37] <KGB-linuxcnc> 05jepler/proposed-2.6 62ca1b4 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=62ca1b4
[19:27:45] <PCW> but... i still get occasional errors at 4 KHz running youtube so thats right at the limit
[19:28:08] <PCW> haven't tried idle=poll
[19:29:15] <PCW> actually I did not get a real time error when running, but rather a sserial error
[19:30:06] <PCW> which likely means the write was late enough that the sserial transaction was not done by the the next read time
[19:31:26] <PCW> anyway 3KHz seems quite stable on a fast machine and 1 KHz seem to work on just about anything
[19:40:40] <KGB-linuxcnc> 03Jeff Epler 05master bf9ee2d 06linuxcnc 03docs/man/man3/rtapi_byteorder.3rtapi documentation: add manpage for rtapi_byteorder * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bf9ee2d
[21:31:15] <KGB-linuxcnc> 03Michael Geszkiewicz 05micges/scurve-test1 b0ddf85 06linuxcnc 10(13 files in 6 dirs) WIP * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b0ddf85
[21:40:50] <linuxcnc-build> build #293 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/293 blamelist: dummy, Michael Geszkiewicz <micges@wp.pl>
[21:41:30] <linuxcnc-build> build #1680 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/1680 blamelist: dummy, Michael Geszkiewicz <micges@wp.pl>
[21:41:55] <linuxcnc-build> build #2479 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2479 blamelist: dummy, Michael Geszkiewicz <micges@wp.pl>
[21:43:52] <jepler> micges: I guess you don't care yet that your WIP branch doesn't build for rtai?
[21:44:04] <linuxcnc-build> build #2478 of 1900.clang-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1900.clang-lucid-rtai-i386/builds/2478 blamelist: dummy, Michael Geszkiewicz <micges@wp.pl>
[21:50:04] <linuxcnc-build> build #636 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/636 blamelist: dummy, Michael Geszkiewicz <micges@wp.pl>
[21:51:23] <linuxcnc-build> build #636 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/636 blamelist: dummy, Michael Geszkiewicz <micges@wp.pl>
[22:04:02] <linuxcnc-build> build #2480 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/2480 blamelist: dummy, Michael Geszkiewicz <micges@wp.pl>
[22:04:12] <linuxcnc-build> build #2478 of 1300.rip-precise-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/2478 blamelist: dummy, Michael Geszkiewicz <micges@wp.pl>
[22:04:47] <linuxcnc-build> build #2479 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/2479 blamelist: dummy, Michael Geszkiewicz <micges@wp.pl>
[22:06:11] <linuxcnc-build> build #2479 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/2479 blamelist: dummy, Michael Geszkiewicz <micges@wp.pl>
[22:06:12] <linuxcnc-build> build #2487 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2487 blamelist: dummy, Michael Geszkiewicz <micges@wp.pl>
[23:56:03] <KGB-linuxcnc> 03Chris Morley 05master de97b29 06linuxcnc 10src/emc/usr_intf/pncconf/s_motor.glade pncconf -fix spindle near scale/range and filter settings * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=de97b29
[23:56:03] <KGB-linuxcnc> 03Chris Morley 05master 0d1510f 06linuxcnc 10src/emc/usr_intf/pncconf/pages.py pncconf -fix wrong spindle help page showing * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0d1510f
[23:56:03] <KGB-linuxcnc> 03Chris Morley 05master 79cb463 06linuxcnc 10src/emc/usr_intf/pncconf/build_HAL.py pncconf -fix double spindle enable signal HAL line * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=79cb463
