Back
[00:00:46] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master c828daa 06linuxcnc 10src/emc/motion/command.c 10src/emc/motion/control.c motion: remove check_stuff(), dead code * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c828daa
[01:03:04] <KGB-linuxcnc> 03Sebastian Kuzminsky 05ja13-teleop-after-homing c90f617 06linuxcnc 10tests/halui/jogging/postgui.hal 10tests/halui/jogging/test-ui.py halui/jogging test: enforce free-mode joint jogging * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c90f617
[01:03:04] <KGB-linuxcnc> 03Sebastian Kuzminsky 05ja13-teleop-after-homing e42c71b 06linuxcnc 10tests/lathe/test-ui.py lathe test: remove some broken debugging code * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e42c71b
[01:03:04] <KGB-linuxcnc> 03Sebastian Kuzminsky 05ja13-teleop-after-homing 09f1785 06linuxcnc 10tests/lathe/test-ui.py lathe test: do the jogging tests in axis mode, not joint * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=09f1785
[09:38:25] <skunkworks> there probably should be a live image with rt_preempt so people can test computers at the store..
[09:44:13] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/trt_doc_test_v2 bc21905 06linuxcnc 10docs/src/motion/5-axis-kinematics.txt 5-axis-kinematics.txt try {x,y,z,1}~T~ JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bc21905
[09:45:17] <KGB-linuxcnc> 05dgarr/sync_home_final c3cf776 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c3cf776
[09:47:29] <jepler> I tried to make a live image of a jessie preempt kernel but ran into trouble. it was missing a required kernel module to boot (aufs?). and then the debian live project melted down when a project called "debian live ng" was announced by somebody in a way that ended up alienating a number of main debian live contributors
[09:47:37] <jepler> so I'm not even sure of the state of things right now
[09:48:02] <cradek> argh, it just never ends, does it
[09:48:43] <cradek> every time I've made an install/live image it's been totally different. I guess it's reinvented from scratch every few years.
[09:59:02] <seb_kuzminsky> :-(
[09:59:37] <seb_kuzminsky> i wonder if there's ever been a cohesive, cooperative group of humans, ever, anywhere
[10:00:51] <archivist> what bothers me, is yes to that last question but the attention span is getting shorter and shorter
[10:54:00] <seb_kuzminsky> "The stage is too big for the drama." -- Richard Feynman
[12:17:22] <KGB-linuxcnc> 03Norbert Schechner 05EU_Surplus_FastSeal 0e8e678 06linuxcnc 10src/emc/usr_intf/FastSeal/FastSeal.py EU_Surplus_FastSeal - code clearance * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0e8e678
[12:17:22] <KGB-linuxcnc> 03Norbert Schechner 05EU_Surplus_FastSeal 9325bea 06linuxcnc 10src/emc/usr_intf/FastSeal/FastSeal.py Merge branch 'EU_Surplus_FastSeal' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git into EU_Surplus_FastSeal * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9325bea
[12:17:22] <KGB-linuxcnc> 03Norbert Schechner 05EU_Surplus_FastSeal 937da53 06linuxcnc 10(9 files in 3 dirs) EU-Surplus_FastSeal - solved bug in Image Handling * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=937da53
[13:34:12] <linuxcnc-build> build #3299 of 4007.deb-precise-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4007.deb-precise-i386/builds/3299 blamelist: Norbert Schechner <nieson@web.de>
[13:35:56] <linuxcnc-build> build #3299 of 4008.deb-precise-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/3299 blamelist: Norbert Schechner <nieson@web.de>
[13:37:30] <linuxcnc-build> build #2127 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/2127 blamelist: Norbert Schechner <nieson@web.de>
[13:38:47] <linuxcnc-build> build #1870 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/1870 blamelist: Norbert Schechner <nieson@web.de>
[13:42:34] <linuxcnc-build> build #1171 of 4014.deb-wheezy-rtpreempt-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4014.deb-wheezy-rtpreempt-i386/builds/1171 blamelist: Norbert Schechner <nieson@web.de>
[13:45:55] <linuxcnc-build> build #1867 of 4016.deb-wheezy-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-i386/builds/1867 blamelist: Norbert Schechner <nieson@web.de>
[13:47:25] <linuxcnc-build> build #1207 of 4015.deb-wheezy-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4015.deb-wheezy-rtpreempt-amd64/builds/1207 blamelist: Norbert Schechner <nieson@web.de>
[13:48:58] <linuxcnc-build> build #289 of 4017.5.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.5.deb-wheezy-armhf/builds/289 blamelist: Norbert Schechner <nieson@web.de>
[14:13:42] <linuxcnc-build> build #541 of 4022.deb-jessie-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4022.deb-jessie-amd64/builds/541 blamelist: Norbert Schechner <nieson@web.de>
[14:14:31] <linuxcnc-build> build #476 of 4019.deb-jessie-rtpreempt-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4019.deb-jessie-rtpreempt-i386/builds/476 blamelist: Norbert Schechner <nieson@web.de>
[14:15:43] <seb_kuzminsky> this branch failed because lots of new files get installed by "make DESTDIR=foo install", but not added to the debian package
[14:16:42] <linuxcnc-build> build #542 of 4021.deb-jessie-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4021.deb-jessie-i386/builds/542 blamelist: Norbert Schechner <nieson@web.de>
[14:20:17] <linuxcnc-build> build #1559 of 4018.deb-wheezy-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4018.deb-wheezy-rtai-i386/builds/1559 blamelist: Norbert Schechner <nieson@web.de>
[14:20:23] <linuxcnc-build> build #475 of 4020.deb-jessie-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4020.deb-jessie-rtpreempt-amd64/builds/475 blamelist: Norbert Schechner <nieson@web.de>
[18:48:10] <seb_kuzminsky> huh, we already have EMC_TASK_PLAN_SYNCH, which calls interp.synch(), which writes out the vars file
[18:48:40] <seb_kuzminsky> this might be easier than i thought
[19:13:26] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/interp-var-sync 619e466 06linuxcnc 10src/emc/usr_intf/axis/extensions/emcmodule.cc emcmodule: add task_plan_synch() function * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=619e466
[19:13:26] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/interp-var-sync 5fb0e81 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis: call linuxcnc.task_plan_synch() to force a var file write * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5fb0e81
[19:13:26] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/interp-var-sync 699438b 06linuxcnc 10src/emc/task/emctaskmain.cc Task: allow EMC_TASK_PLAN_SYNCH in all modes and states * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=699438b
[19:13:36] <seb_kuzminsky> comments welcome
[20:25:42] <pink_vampire> seb_kuzminsky: hi
[20:26:30] <pink_vampire> my BF is here and he want to ask you something about configuration of the probe.
[20:28:24] <pink_vampire> Hi, Installed 'Probe Screen' but getting this error when trying to test the probe:
[20:29:01] <pink_vampire> "probe trip during non-probe MDI command"
[20:32:52] <andypugh> Are you using a probe routine with non-probe moves in it?
[20:34:21] <andypugh> If it’s (for example) the Verser Python routines, those send the G-code moves one at a time through the MDI interface.
[20:38:21] <skunkworks> getting there
[20:38:23] <skunkworks> http://electronicsam.com/images/matsuura/20160506_175211.jpg
[20:39:56] <andypugh> I made little brackets with tubes for where my cable loops crossed the hinge. I am not sure if that was overkill.
[20:40:36] <skunkworks> andypugh, if you wanted to advance the carousel componant manually - how would you do it?
[20:41:25] <andypugh> Hmm, good question. Mux tool+1 into it?
[20:41:49] <skunkworks> ok - that was the nebulous thought..
[20:42:13] <andypugh> You think it needs jog inputs?
[20:42:28] <andypugh> I can see that being needed for tool loading
[20:43:00] <skunkworks> yes..
[20:45:20] <skunkworks> the matsuura has a Geneva mech that runs a tool chain
[20:45:47] <skunkworks> https://www.youtube.com/watch?v=kwnIIWTb7U8
[20:47:37] <andypugh> Putting tools in that does look like you need to be able to move it, yes.
[20:48:27] <andypugh> Am am going to be very bored in a hotel in Detroit most evenings next week, I can add that to the list.
[20:49:22] <Tom_itx> don't venture far from home in that town
[20:49:45] <andypugh> Well, I am actually staying in Dearborn
[20:50:34] <andypugh> And I do wonder how much worse than Pitsea Detroit really is. Except for the guns thing.
[20:50:56] <Tom_itx> i've never been there and really don't plan to
[20:51:55] <Tom_itx> nice job on the lathe btw
[20:58:05] <skunkworks> andypugh, that would be awesome!
[20:59:14] <andypugh> skunkworks: Remind me next week :-)
[20:59:26] <skunkworks> :)
[21:01:03] <skunkworks> the advance has a brake that is turned on while the advance motor is on. So a little ladder is required
[21:04:37] <andypugh> You mean off while the motor is on?
[21:04:51] <skunkworks> ye
[21:04:54] <skunkworks> yes -
[21:05:29] <andypugh> My Holbrook lathe spindle has a brake. It’s strange to see the spindle stop so fast. I can’t decide whether to use it.
[21:06:15] <skunkworks> run the forward motor -> stop by turning on the 'brake' relay witch still requires the forward relay to be one. So I need a time delay that when the forward pin goes low - the brake is turned on for a time - then the motor and brake relay get shut off
[21:07:06] <andypugh> skunkworks: It’s an easy extra output to add. But really the brake doesn’t need ladder, it is just “NOT (motor-fwd OR motor-rev)”
[21:07:42] <andypugh> We are talking out of synch, clearly.
[21:08:49] <andypugh> You can do what you describe in HAL or in Ladder, I think it comes down to where you are comfortable.
[21:09:52] <skunkworks> right
[21:10:13] <skunkworks> no - if the forward relay isn't on - the brake doesn't work
[21:10:52] <andypugh> That’s silly.
[21:11:13] <andypugh> Probably made sense without HAL.
[21:11:27] <skunkworks> yes - it could be the forward or reverse relay is always on - with the brake relay activated.. I don't know
[21:11:42] <andypugh> Like the 555 timer in my millng machine PSU made sense, until I realised HAL could do it for free.
[21:11:49] <skunkworks> heh
[21:11:59] <skunkworks> hal/classic ladder is pretty aweome
[21:12:02] <skunkworks> awesome
[21:12:16] <andypugh> I found a fun trick with LUT5.
[21:12:24] <skunkworks> the K&T gear shift was done in hal/comp. the tool changer was done in ladder
[21:12:45] <andypugh> If you feed the output to one of the inputs then LUT5 becomes “stateful”
[21:12:56] <pink_vampire> my BF working on wire some stuff in the panel.
[21:13:58] <andypugh> pink_vampire: You are slipping too easily into gender roles, tell him too cook dinner while you do the wiring.
[21:14:38] <pink_vampire> andypugh: I can't pull the wires.
[21:15:16] <andypugh> You might break your fingernails? I know _exactly_ what you mean :-)
[21:15:31] <pink_vampire> also that.
[21:15:49] <pink_vampire> but I can't close the screws tight.
[21:16:00] <andypugh> (I have always had longer fingernails than my girlfriends)
[21:17:01] <pink_vampire> she bite them?
[21:18:23] <andypugh> skunkworks:
http://codepad.org/zupMW54p
[21:19:41] <andypugh> pink_vampire: I started to keep them long as a kif to use them as srewdrivers for my favourite toy, Meccano.
[21:20:12] <pink_vampire> omg!!!!!!!!
[21:20:20] <pink_vampire> I love the gyro.
[21:20:30] <pink_vampire> the best thing ever!!
[21:20:48] <andypugh> (kid, not kif. I couldn’t be less Kif, they are obligate carnivores from the Chanur series by Cherryh)
[21:21:02] <andypugh> pink_vampire: Cickspring?
[21:21:19] <pink_vampire> noo
[21:21:34] <pink_vampire> one sec I will give you a link
[21:22:53] <pink_vampire> http://www.sears.com/4-v-max-gyro-8482-screwdriver/p-00938462000P?sid=IDx01192011x000001&gclid=CKikl5ruxswCFYMehgod1KkPHg&gclsrc=aw.ds
[21:24:34] <pink_vampire> andypugh: ^
[21:25:03] <pink_vampire> there is a video in the page that show how it work.
[21:25:44] <andypugh> Ah, right.
[21:27:15] <andypugh> pink_vampire: Look at the Bosch Ixo too, been out for about 10 years, while you were (I assume) asleep. :-)
[21:28:33] <pink_vampire> the coolest thing about the gyro is there is no right and left switch
[21:28:58] <andypugh> Ah,
[21:29:22] <pink_vampire> the way you tilt it is't how it rotate
[21:30:42] <andypugh> Right, clever. Pointless and unnecessary, but clever.
[21:31:35] <andypugh> It lets you twist the wrong way because you are in an unusual place relative to the driver just like the real thing. :-)
[21:41:13] <pink_vampire> Hi, Pink`s BF here.
[21:42:34] <pink_vampire> Just finished wiring some stuff, we tested the probe and for some odd reason the Z axis moves when you probe the X or Y axis
[21:43:09] <pink_vampire> Besides that, we are getting an error: "user probe error".
[21:43:51] <pink_vampire> The same setup works perfectly in Mach 3...
[21:45:01] <pink_vampire> andypugh: any thoughts?
[21:45:53] <andypugh> None at all. That’s just inexplicable.
[21:46:13] <andypugh> What G-code is being run?
[21:47:53] <pink_vampire> andypugh: I'm not running any G code, I simply click the buttons in the Probe Screen interface.
[21:48:33] <andypugh> That will be running some G-code “under the hood”
[21:48:48] <andypugh> Is this the Verser Probe-screen?
[21:49:36] <pink_vampire> andypugh: Yes, it came from his github page.
[21:49:46] <andypugh> Link?
[21:50:46] <andypugh> Got it
[21:50:53] <pink_vampire> http://i.imgur.com/V0fxqcM.png
[21:51:19] <pink_vampire> andypugh: See the error we are getting at the bottom of the screen.
[21:51:42] <pink_vampire> https://github.com/verser-git/probe_screen
[21:52:12] <pink_vampire> ^^ That`s where I have downloaded and installed for her.
[21:52:16] <andypugh> There are G-cdoe routines included here:
https://github.com/verser-git/probe_screen/tree/master/macros
[21:52:46] <pink_vampire> andypugh: These .NGC files are in there.
[21:53:29] <andypugh> I suspect if you put a (MESSAGE, I be running G-code, I be) in each one of those .ngc files you will see them being run.
[21:54:01] <pink_vampire> down.ngc xminus.ngc xplus.ngc yminus.ngc yplus.ngc
[21:54:58] <pink_vampire> Also how come there are only 5 .ngc files, but 22 buttons?
[21:56:20] <andypugh> I think the Python calls them in various different ways
[21:56:50] <pink_vampire> Look for an example at yplus.ngc, there is no Z in the file, but the Z axis moves down during the probing process, (and never goes back up).
[21:59:31] <pink_vampire> Is there any documentation for Probe Screen?
[21:59:49] <andypugh> Maybe it also calls G-code directly? Lots if G90 etc in
https://github.com/verser-git/probe_screen/blob/master/python/probe_screen.py (I have not found the definitions)
[22:00:23] <andypugh> Apart from:
https://github.com/verser-git/probe_screen/blob/master/README.md ?
[22:00:39] <andypugh> It appears not
[22:01:45] <pink_vampire> Read that, used it to do the install of Probe Screen.
[22:02:20] <pink_vampire> No one here uses that?
[22:03:13] <andypugh> Not yet, I keep meaning to install it
[22:03:38] <pink_vampire> It`s easy enough, I can probably do that for you.
[22:04:35] <pink_vampire> andypugh: ^
[22:07:18] <andypugh> It’s a matter of getting round to it, and needing it.
[22:07:35] <pink_vampire> andypugh: All I need you to do is to copy the 'Macro' and 'Python' folders under your 'mymill' and send me your .ini file, so I can edit it.
[22:07:58] <andypugh> So far I have got by by just typing G38.2 a lot in the MDI window
[22:08:39] <pink_vampire> andypugh: If this works properly, you will save lots of time when you do a set-up.
[22:09:14] <andypugh> pink_vampire: is this pink_vampire or the BF? I do know how to edit INI files, I am one of the devs :-)
[22:10:36] <skunksleep> I have been using cradeks probing routines. Been meaning to try that screen though
[22:10:42] <pink_vampire> BF here... sorry, didn`t mean to offend you or anything, I have no clue in this field, and I'm no programmer, just trying to help her out.
[22:12:05] <pink_vampire> This thing not working right, drives her bananas.
[22:13:56] <pink_vampire> andypugh: She is like a cute little ballistic missile ready to explode...
[22:16:06] <andypugh> It _sounds_ like noise on the probe signal is triggering warnings on non-probe moves. The routines have to do some non-probe moves to position the probe.
[22:17:29] <andypugh> You might want to look at whether vibrations trigger the probe, and possibly look at passing the probe input through a software debounce. 3mS delay isn’t a huge loss of spatial accuracy.,
[22:20:01] <pink_vampire> andypugh: If there was a noise or vibration problem, than Mach 3 shouldn't have worked either...
[22:21:07] <andypugh> Unless the Mach config had a debounce. Or perhaps Mach just doesn’t care if the probe input changes state when not probing.
[22:21:07] <pink_vampire> andypugh: How do you do a software debounce?
[22:21:50] <andypugh> http://linuxcnc.org/docs/2.7/html/man/man9/debounce.9.html
[22:24:22] <andypugh> Is that enough, or do you need more?
[22:25:02] <andypugh> That tells you the function name and the loadrt syntax.
[22:25:16] <pink_vampire> andypugh: I see that it uses the loadrt command, so I assume it goes in the .hal file, right?
[22:26:11] <andypugh> Yes, then you need to addf the function to a thread. (possibly base-thread for probing)
[22:27:20] <andypugh> example:
https://forum.linuxcnc.org/forum/38-general-linuxcnc-questions/12062-joint-0-limit-error-setting-up-debounce?start=6#12083
[22:28:10] <andypugh> You would be using the probe pin, and probably don’t need the delsig, I gave that example as something that would go in a custom HAL
[22:29:42] <pink_vampire> So I need: loadrt debounce cfg=1 for only one channel, the probe, right?
[22:29:51] <andypugh> Yes
[22:31:00] <pink_vampire> And how will the code figure out that my channel or pin number is 11?
[22:31:15] <andypugh> You need to tell it.
[22:32:18] <andypugh> something like net probe-raw parport.0.pin-11-in => debounce.0.0.in
[22:32:32] <pink_vampire> Ok, let`s see if I can figure it out.
[22:32:56] <andypugh> and net probe-filtered debounce.0.0.out => motion.probe
[22:33:44] <andypugh> Don’t forget to set the debonce length and do the addf to make it actually run in a thread.
[22:34:25] <andypugh> I guessed the name of the motion pin for probe input.
[22:40:09] <pcw_home> motion.probe-input
[22:40:22] <andypugh> Thanks
[22:40:46] <andypugh> It’s 4am. too late to think. In fact i think it’s time to log off.
[22:41:11] <pcw_home> 'nite
[22:41:39] <pink_vampire> andypugh: Give me a minute, almost done with the modification
[22:42:47] <andypugh> If I type a lot of random characters it means I have fallen asleep with my forehead on the keyboard.
[22:43:45] <pink_vampire> andypugh:
http://pastebin.com/746yzuQj
[22:46:13] <andypugh> Yo need to net the debounce.0.0.out to the same signal/net as motion.probe-input
[22:46:43] <andypugh> And I don’t see the debonce in the addf list
[22:48:45] <pink_vampire> Hmm...
[22:49:20] <pink_vampire> Is that base-thread ?
[22:50:32] <andypugh> I think that the base-thread is more appropriate. But given that I think that motion only looks at the probe-input every 1mS you should probaby set the debounce to be about half a millisecond.
[22:50:54] <pink_vampire> andypugh: This way: addf debounce.0.0 base-thread
[22:50:57] <pink_vampire> ?
[22:51:06] <andypugh> So 20 for a 25uS base-thread
[22:51:56] <pink_vampire> andypugh: Not sure how this work
[22:52:10] <andypugh> debounce is confusing. It’s addf debounce.0 for every channel in debounce.0 (all one of them)
[22:52:23] <pink_vampire> andypugh: 20 debounces per 25 MicroSeconds?
[22:52:47] <andypugh> 20 samples at base-thread frequency
[22:53:31] <pink_vampire> Ok, so simply: addf debounce.0 base-thread ?
[22:53:38] <andypugh> Yes
[22:54:42] <andypugh> That would run debounce.0.0, debounce.0.1, debounce.0.N at base-thread frequency all with the same debounce count
[22:55:17] <andypugh> I think that debounce is the only component that works like that
[22:55:55] <andypugh> I remember being baffled by it several years ago when I firs started.
[22:56:58] <pink_vampire> andypugh:
http://pastebin.com/B7ugEyHA <-That`s all together now, am I missing anything?
[22:58:23] <andypugh> I still don’t see debounce.0.0.out going anywhere
[22:59:29] <pink_vampire> andypugh: So in my case: net probe-raw parport.0.pin-11-in => debounce.0.in
[22:59:34] <pink_vampire> and
[23:00:53] <andypugh> net pinkys-special-debounced-probe-signal deboince.0.0.out motion.probe-input
[23:01:06] <pink_vampire> :-)
[23:01:16] <andypugh> (just to stress that signal names have _no_ special significance
[23:03:12] <pink_vampire> So: net probe1 deboince.0.0.out motion.probe-input ??
[23:04:14] <andypugh> Well, you would want to spell “debounce” correctly, like I failed to.
[23:05:06] <pink_vampire> net probe1 debounce.0.0.out motion.probe-input
[23:05:53] <pink_vampire> So I don't need: net probe-raw parport.0.pin-11-in => debounce.0.in ?
[23:06:10] <pink_vampire> Or do I need both?
[23:06:12] <andypugh> yes, you do
[23:06:19] <pink_vampire> Ok
[23:07:01] <andypugh> The signal passes from the parport to the debounce,in then from the deboince.out to the motion probe input
[23:09:24] <andypugh> Right, I really need to sleep now.
