Back
[07:19:06] <skunkworks> so.... Is the 20 tooth gt2 pully right on the shaft?
[07:19:51] <skunkworks> doesn't that equate to about .004 per half step?
[07:20:01] <skunkworks> .004"
[07:29:27] <skunkworks> 40mm per rev - 400step/rev/40mm = .1mm per step or .003937"
[07:30:05] <skunkworks> rostock claims Positioning accuracy of .02mm
[07:30:37] <skunkworks> they must be touting microsteps in that calculation.
[07:45:33] <KGB-linuxcnc> 03git 05v2.5-lxrt-OPT-O0-breakage f27301c 06linuxcnc * branch created
[07:46:22] <mhaberler> cradek: v2.5_branch breaks with OPT=-O0 (since a few months btw; I only made the -O0 connection today)
[08:02:25] <cradek> mhaberler: do you know why? my understanding is it's not too uncommon that -O0 breaks code.
[08:02:46] <mhaberler> yes, it's mysterious inlining in rtai_shm.h
[08:02:54] <mhaberler> filing a bug now with more details
[08:03:30] <mhaberler> I'd think 'no optimization' should never break - any others you know of?
[08:04:07] <cradek> well like I said it's not too uncommon. are you filing a bug against rtai?
[08:04:09] <mhaberler> the only way to debug with gdb and not go nuts over code being moved around by the optimizer
[08:04:31] <cradek> sure, I understand why you want it
[08:04:37] <mhaberler> no, for linuxcnc for now
[08:04:59] <mhaberler> not sure we get any result for 2.6.32-122-rtai
[08:05:08] <mhaberler> but it looks theres a workaround
[08:05:22] <cradek> be aware you can build just the files you want to debug as -O0
[08:05:49] <mhaberler> sure
[08:06:39] <mhaberler> anyway the cause is liblxrt and libpthread should be linked into liblinuxcnchal.so and milltask (unfortunately rtai-config --lxrt-ldflags is broken and useless)
[08:06:48] <mhaberler> that makes it build and runtest
[08:14:47] <mhaberler> does one nowadays have to kick the buildbot explicitly ?
[08:14:53] <cradek> nope
[08:16:31] <cradek> latest is on the right:
http://buildbot.linuxcnc.org/buildbot/grid
[08:19:27] <mhaberler> where do you see it's picked up my push? the last I see is master
[08:21:38] <cradek> I see a new branch but I don't think you pushed a change at all?
[08:21:53] <cradek> commit f27301c823067f831713fad78455993b7093f6ef (origin/v2.5-lxrt-OPT-O0-breakage, origin/bug315-2-fix)
[08:21:56] <cradek> Author: Michael Haberler <git@mah.priv.at>
[08:21:58] <cradek> Date: Tue Jul 9 10:53:28 2013 +0200
[08:22:25] <mhaberler> My assumption was: you push any branch, the bb picks it up. wrong?
[08:23:03] <cradek> I'm saying I don't think you pushed what you intended
[08:23:06] <mhaberler> oh - I see. sorry
[08:23:11] <cradek> your -O0 related changes are not there
[08:25:44] <jepler> skunkworks_: the BOM I have says 15 tooth gt2 pulley, while the configuration file says 20. The drives are capable of 1/16 microstepping, and the configuration reflects that as well. That gives a joint positioning precision of .0125mm, but how that translates into axis positioning precision or accuracy is unclear for a number of reasons.
[08:29:15] <KGB-linuxcnc> 03TODO: deletor 05v2.5-lxrt-OPT-O0-breakage f27301c 06linuxcnc 04. * branch deleted
[08:30:05] <KGB-linuxcnc> 03git 05v2.5-lxrt-OPT-O0-breakage 5372e5a 06linuxcnc 10src/ 10Makefile 10emc/task/Submakefile 10hal/Submakefile * 'make OPT=-OO0' build failure: explicitly link in lxrt.a and libpthread
[08:33:27] <linuxcnc-build> build #389 of precise-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/389 blamelist: Michael Haberler <git@mah.priv.at>
[08:36:00] <linuxcnc-build> build #1188 of lucid-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1188 blamelist: Michael Haberler <git@mah.priv.at>
[08:36:13] <linuxcnc-build> build #1189 of precise-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/1189 blamelist: Michael Haberler <git@mah.priv.at>
[08:36:51] <linuxcnc-build> build #1191 of precise-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/1191 blamelist: Michael Haberler <git@mah.priv.at>
[08:38:42] <linuxcnc-build> build #987 of precise-amd64-sim-clang is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim-clang/builds/987 blamelist: Michael Haberler <git@mah.priv.at>
[08:39:01] <linuxcnc-build> build #1192 of hardy-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1192 blamelist: Michael Haberler <git@mah.priv.at>
[08:39:11] <linuxcnc-build> build #1191 of lucid-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1191 blamelist: Michael Haberler <git@mah.priv.at>
[08:39:23] <linuxcnc-build> build #1188 of hardy-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1188 blamelist: Michael Haberler <git@mah.priv.at>
[08:39:39] <linuxcnc-build> build #1190 of hardy-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1190 blamelist: Michael Haberler <git@mah.priv.at>
[09:08:52] <KGB-linuxcnc> 03git 05v2.5-lxrt-OPT-O0-breakage de6b60a 06linuxcnc 10src/ 10emc/task/Submakefile 10hal/Submakefile * back out extra libs to trigger build error
[09:12:36] <linuxcnc-build> build #1186 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1186 blamelist: Michael Haberler <git@mah.priv.at>
[09:16:23] <linuxcnc-build> build #390 of precise-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/390 blamelist: Michael Haberler <git@mah.priv.at>
[09:17:32] <jepler> this is an upstream (rtai) bug that they haven't cared about for 5 years
http://mail.rtai.org/pipermail/rtai/2007-April/017140.html
[09:17:36] <linuxcnc-build> build #1192 of lucid-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1192 blamelist: Michael Haberler <git@mah.priv.at>
[09:18:17] <linuxcnc-build> build #1188 of lucid-rtai-i386-clang is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-rtai-i386-clang/builds/1188 blamelist: Michael Haberler <git@mah.priv.at>
[09:18:29] <jepler> If someone offers a ./configure-time check for the bug and a workaround it sure might make sense to incorporate it
[09:19:08] <jepler> meanwhile you might look at whether some set of flags gives a working link without enabling everything that's in the normal(?) -O2, such as -O0 -finline-functions
[09:19:51] <cradek> seems we're using -Os by default
[09:20:34] <mhaberler> bingo: there it is:
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1192/steps/compile/logs/stdio
[09:21:15] <cradek> the buildbot sure finishes faster when the compiles fail!
[09:25:28] <mhaberler> I dont think this should be fixed in configure; assume the result of the test is to leave out lxrt because you compiled with -Os, then as soon as you rebuild with -O0 you'll get thr error again
[09:27:27] <jepler> if there's a proposed fix I will review it.
[09:27:43] <mhaberler> hm, -fkeep-inline-functions might be worth a try
[09:30:24] <mhaberler> well, -fkeep-inline-functions gets us deeper into the morass: /usr/realtime-2.6.32-122-rtai/include/asm/rtai_hal.h:211: error: PIC register â%ebxâ clobbered in âasmâ
[09:32:39] <mhaberler> no change for -O0 -finline-functions
[09:36:00] <mhaberler> well this was bugging several people, but once you know what it is one can deal with it if needed; I dont think it is that important to fix, at least its documented in the tracker now; and I'm really chasing other wonders right now
[09:54:22] <linuxcnc-build> build #1191 of hardy-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1191 blamelist: Michael Haberler <git@mah.priv.at>
[09:55:33] <linuxcnc-build> build #1189 of hardy-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1189 blamelist: Michael Haberler <git@mah.priv.at>
[09:55:34] <linuxcnc-build> build #1187 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1187 blamelist: Michael Haberler <git@mah.priv.at>
[10:40:40] <KimK> Just glancing back quickly (attracted by the color highlights?), I'm guessing poster "git" is mhaberler? Poster "TODO: deletor" too?
[10:41:21] <mhaberler> what are you referring to?
[10:48:21] <KimK> Well, when KGB reports, it's color highlighted, so I look at it. I was guessing that you are (in green highlights) poster "git"? Maybe you are poster "TODO: Deletor" too? Image at
http://imagebin.org/264829
[10:50:24] <KimK> I'm off to the shop for a bit, I'll check back later.
[10:57:56] <seb_kuzminsky> KimK: in that imgbin picture, the poster is "KGB-linuxcnc", and the messages report changes to our git repo on linuxcnc.org
[10:58:19] <seb_kuzminsky> the messages intend to be descriptive of what the change was, but are maybe confusing
[10:58:38] <seb_kuzminsky> the first one, "TODO: deletor" reports that a branch was removed
[10:59:32] <seb_kuzminsky> then the two "git" ones report that commits were pushed to the branch v2.5-lxrt-OPT-O0-breakage
[11:16:20] <mhaberler> yes, git was an unfortunate choice for a git userid
[11:23:23] <seb_kuzminsky> mhaberler: good thing you can rewrite it before merging
[11:23:53] <mhaberler> the userid?
[11:27:28] <seb_kuzminsky> yea
[11:28:28] <seb_kuzminsky> git rebase, mark the commit as 'edit', then use 'git commit --amend --reset-author'
[11:34:48] <seb_kuzminsky> the thing about git is: anything you want to do, you probably can do, if you can just figure out how to say it in the git way
[11:36:27] <skunkworks_> hypothecially... how could you run 2 stepgens off of the same position command...? Would you not worry about the feedback from one? would you sum them?
[11:37:12] <skunkworks_> would you ask the question why would you do that?
[11:38:11] <skunkworks_> I suppose 'kins' would be the answer... but for a 2 axis lathe - I think that is overkill
[11:39:31] <skunkworks_> This is the experiment. I want to run 2 stepgens - one scaled and running full step - the other scaleced and running half step. I want to switch the output to the printer port between them at a velocity threshold...
[11:40:11] <skunkworks_> The phase patterns (I think) will stay matched up.. (as they both start at 0)
[11:41:03] <skunkworks_> wow - I don't know If I thought this out all the way...
[11:43:09] <skunkworks_> it seems like it would be better to have a stepgen with this feature..
[11:48:37] <seb_kuzminsky> isn't microstepping a feature more of the stepper amp than of the step pulse generator?
[11:51:06] <pcw_home> yes for > 1/2 step but full step vs 1/2 step are just different patterns
[11:51:30] <seb_kuzminsky> ah
[11:53:14] <seb_kuzminsky> in that case i think it'd be easy to have two stepgen components, one running the 1/2-step pattern and one running the full-step pattern, both fed from the same pos-cmd net, and have a velocity comparator select one of the stepgen outputs to be sent to the stepper amp (via a mux)
[11:53:56] <seb_kuzminsky> i'm not sure if that would work well if you switch between the two stepgen outputs while the 1/2-stepping one is in the middle of a half-step (ie, not on a full-step boundary)
[11:54:03] <pcw_home> that is 1/2 and full step drives typically put full current in the motor coils,
[11:54:04] <pcw_home> 1/2 step gets in between steps by driving two windings at once
[11:54:08] <seb_kuzminsky> you might lose half a step in that situation?
[11:54:47] <seb_kuzminsky> maybe you could comp up a special comparator that only switches the output mux on a full-step boundary
[11:55:11] <seb_kuzminsky> or maybe skunkworks is right, and this should be an option in the stepgen component
[11:55:33] <seb_kuzminsky> bbl
[11:56:09] <pcw_home> Not clear on what the advantage would be
[11:58:22] <archivist> is skunkworks_ trying to gear the generator like mariss does at speed but in linuxcnc
[12:16:24] <skunkworks_> pcw_home, it isn't really a big deal I think. Those little emco lathes I think the original control did this. half stepping up to 19ipm - then switching to full step. The only advantage I see is .00026 per step vs .00052 or so. and maybe resonence help (although I have not seen it yet running full step all the time)
[12:17:56] <pcw_home> That may be just because they could not generate 1/2 stepping at 40 IPM with their original PC/software
[12:18:21] <skunkworks_> no - the control will not halfstep much higher than 19ipm sounds like crap
[12:18:27] <skunkworks_> don't know why
[12:18:41] <pcw_home> Oh a driver issue
[12:18:51] <skunkworks_> but full stepping sounds great past 40ipm
[12:19:07] <skunkworks_> 0 to 40ipm (actually 45 is usable)
[12:19:14] <skunkworks_> yes
[12:19:38] <skunkworks_> more just a - I wonder if it could be done..
[12:20:42] <skunkworks_> seb_kuzminsky, what would you do with the feedback? just hook 1 up?
[12:21:05] <skunkworks_> (they both should be tracking the same I assume)
[12:21:14] <pcw_home> seem like you just want to dynamically change the pattern without changing any scaling
[12:21:49] <skunkworks_> right - that would be a stepgen feature then I assume..
[12:22:29] <skunkworks_> What I was planning was 2 stepgens - one running halfstep and 2Xscalling and one running full step at scalling
[12:22:44] <skunkworks_> *scaling
[12:23:24] <skunkworks_> so over the same distance - the patterns would stay matched up
[12:25:57] <pcw_home> Its probably possible to avoid scaling changes (imagine just changing the (8 deep) pattern table from
[12:25:59] <pcw_home> 1/2 to full step (both 8 table entries per full phase rotation so scaling is unchanged)
[12:26:27] <pcw_home> (the full step table has repeated entries)
[12:27:33] <skunkworks_> so the 8 deep pattern for full stepping would be patterna,patterna,patternb,patternb and so on?
[12:28:31] <pcw_home> Yes
[12:29:26] <skunkworks_> so you would just have to hack stepgen to look at it's velocity and switch bettwen the 2 patterns at a threshold...
[12:29:48] <skunkworks_> that seems almost easy ;)
[12:30:11] <pcw_home> probably i would put the threshold logic in HAL
[12:32:12] <pcw_home> you might also want some hysteresis in the threshold
[12:32:26] <skunkworks_> right
[13:25:44] <skunkworks_> well - (what I had started already) 2 stepgens seem to track out to 100 inches perfectly...
[13:26:15] <skunkworks_> (with 2 different phase patterns and scalings...)
[13:26:35] <kwallace1> BTW, the Bandit controller on my Shizuoka mill had a half/full step feature. This allowed for faster rapids.
http://www.wallacecompany.com/machine_shop/Shizuoka/Shizuoka_Step_Drv-1a.png
[13:27:55] <skunkworks_> did you impliment it?
[13:28:39] <kwallace1> No, I can run at 70% of rapid without it, so I didn't bother.
[13:29:12] <skunkworks_> is there a mux that works in the base thread? (non floating point?) I guess I could use a bunch of and gate...
[13:29:19] <skunkworks_> gates
[13:30:13] <skunkworks_> bit wise mux
[13:30:39] <kwallace1> I seem to recall the Bandit used gates, but it has been a few years since I looked at it.
[13:31:31] <skunkworks_> This is how the emco lathe works as-is.. (linuxcnc is cool)
[13:31:32] <skunkworks_> http://electronicsam.com/images/emco/Waveform.svg
[13:32:08] <kwallace1> The Inhibit signal pulses, in the linked diagram, would shrunk as the step speed got higher.
[13:32:21] <skunkworks_> yikes
[13:33:35] <seb_kuzminsky> that's a nice diagram skunkworks_, what tool made it?
[13:33:48] <skunkworks_> http://wavedrom.googlecode.com/svn/trunk/editor.html
[13:33:56] <skunkworks_> found it last night...
[13:33:57] <skunkworks_> :)
[13:34:10] <seb_kuzminsky> cool :-)
[13:34:49] <skunkworks_> looks like you can do quite a bit with it. and isn't too hard to figure out'
[13:36:16] <seb_kuzminsky> yeah
[13:36:40] <seb_kuzminsky> too bad it really wants to run in a web browser instead of as part of a scripted build system :-/
[13:37:02] <seb_kuzminsky> there's a cli, but it requires a bunch of web emulation stuff set up around the tool
[13:37:50] <micges> hi guys
[13:37:56] <skunkworks_> micges, He
[13:37:58] <skunkworks_> hi
[13:38:16] <micges> my customer just reported that every start of linuxcnc var file is cleared
[13:38:38] <micges> I was thinking we fixed this these bugs
[13:38:42] <seb_kuzminsky> hi micges
[13:38:48] <skunkworks_> kinda looks like you would want to offset one of the stepgens by about 1 step so they sync better
[13:39:30] <seb_kuzminsky> i wouldn't be surprised if there are still ingering bugs in var file handling :-(
[13:40:14] <micges> when I use lcnc I hit this bug once a week, he have it everytime
[13:40:41] <micges> well I'll do some lurking
[13:41:15] <seb_kuzminsky> i've not run in to this bug myself
[13:42:09] <micges> that;s why he is still lurking there ;)
[13:42:18] <seb_kuzminsky> heh yep
[13:42:57] <cradek> I have never ever seen that bug
[13:43:03] <cradek> I don't believe it exists
[13:43:33] <cradek> when I've heard people talk about it, they've always been doing something destructive, like editing the file manually with an editor
[13:43:49] <seb_kuzminsky> i vaguely recall some problem where a corrupted var file caused the entire var file to be removed?
[13:43:52] <cradek> do you have evidence to convince me otherwise?
[13:44:43] <micges> cradek: good point
[13:45:02] <skunkworks_> have him do a smart test on the drive
[13:45:06] <cradek> I bet we don't write it atomically (write to a new file, then mv) which would be slightly safer
[13:45:26] <cradek> micges: it is a curse that the var file is human readable
[13:45:48] <cradek> micges: if you have information about this being an actual bug, please share because I'm interested
[13:46:33] <cradek> if you really have someone getting it EVERY time, it should be investigated
[13:46:40] <cradek> they are obviously doing something unusual
[13:46:59] <micges> sure
[13:47:14] <micges> it's hard to check what are they doing by phone
[13:47:22] <cradek> yeah
[13:47:47] <cradek> besides, you can only yell WHAT ARE YOU DOING THAT'S WEIRD AND WRONG? so many times
[13:48:34] <micges> I can but they rarely listen
[13:49:47] <cradek> > I could point you to some tutorials for rank beginners but I'm turned off by your comments and attitude.
[13:49:54] <cradek> ^ haha
[13:50:02] <archivist> are they shutting down nicely or just turning power off
[13:50:32] <micges> haha
[13:50:38] <micges> archivist: nicely
[13:53:55] <skunkworks_> I actually had this issue - but the hardrive failed pretty quickly after the incident.. (didn't gene have the same problem?)
[13:55:43] <jepler> cradek: ja3 seemed to be in pretty decent shape when you played with your rotary delta kinematics?
[13:55:50] <jepler> I suppose I should rebase my linear delta kinematics onto ja3
[13:56:30] <cradek> jepler: I noticed a few minor weirdnesses but in general it works
[13:56:41] <cradek> I wish I had kept more careful track. but anyway I will keep experimenting.
[14:00:02] <cradek> once I had world limits that kept me in nice valid joint space, it started feeling stable. but even then, gcode will run you right outside those limits without complaining (and homing that leaves you outside those limits also does not error as it should)
[14:00:25] <cradek> but jogging works well once you're inside valid world space
[14:00:31] <cradek> I can't wait to try wheel mode
[14:02:47] <cradek> jepler: but yeah, you should definitely be on ja3 if for no other reason than to get incremental jog
[14:08:07] <jepler> I wonder if we should push our kins modules to ja3, or just wait for the ja4 that seb has promised
[14:09:43] <cradek> I didn't want to add to work he's already in the middle of
[14:10:39] <cradek> once he's done and happy his ja4 results are right, he might want to merge ja3 into ja4 (-s ours) to make a new merge base for us
[14:10:50] <cradek> then we'd have trivial merges
[14:10:52] <jepler> we can trivially rebase our stuff
[14:11:11] <cradek> there are also other branches based off ja3 that we might eventually want to be able to merge
[14:11:15] <jepler> his goal (the purpose of the rebase) is to get a better history, and merging ja3 gets you the worse history again
[14:11:26] <jepler> they would also have to be rebased
[14:12:00] <cradek> oh ok
[14:12:08] <cradek> shows what I know
[14:12:41] <seb_kuzminsky> you guys can safely base your work on ja3
[14:12:58] <jepler> seb_kuzminsky: but should we push it to ja3 on git.l.o?
[14:13:12] <jepler> or should we wait a bit and it'll be better for everyone?
[14:13:14] <seb_kuzminsky> when i push ja4 you'll be able to easily rebase your branch from ja3 to ja4 with "git rebase --onto ja4 mybranch ja3"
[14:13:22] <seb_kuzminsky> it's ok if you push to the tip of ja3
[14:13:53] <seb_kuzminsky> i've got an old snapshot of ja3 that i'm doing my work on, when i catch up to that branch head it should be easy to cherrypick any additional commits from the new ja3 head onto my ja4 head
[14:14:04] <jepler> HD189733b is blue!
[14:14:14] <seb_kuzminsky> when i get to that point i'll ask folks to stop pushing to ja3, and instead wait for my ja4 and pus their stuff there
[14:14:32] <seb_kuzminsky> i think jepler finally snapped
[14:14:46] <seb_kuzminsky> bbl meeting :-(
[14:14:57] <jepler> http://en.wikipedia.org/wiki/HD189733b
[14:15:23] <jepler> nah, no more snapped than usual. just misty eyed over astrology or whatever they're calling it these days.
[14:15:48] <seb_kuzminsky> ooohh! it's blue!
[14:16:03] <cradek> coool
[14:16:30] <jepler> seb probably cares more about how we can accuraely know the time at HD189733b
[14:22:51] <skunkworks_> with a slight offset between the 2 stepgens - the phases fall in line better.
[14:23:08] <jepler> skunkworks_: ??
[14:23:11] <jepler> you lost me
[14:23:27] <skunkworks_> sorry - talking to myself - earlier conversation..
[14:23:48] <jepler> I must have missed it
[14:23:54] <jepler> still thinking about your lathes?
[14:23:54] <skunkworks_> (setting up 2 stepgens and switching between them at different velocities.)
[14:23:58] <skunkworks_> yes
[14:24:40] <skunkworks_> one stepgen fullstep and 'scale'.. one stepgen halfstep and 'scale*2'
[14:25:14] <skunkworks_> so at about 15ipm I would switch from halfstep -> full step
[14:25:51] <jepler> is there a select line for half vs full step?
[14:26:22] <skunkworks_> at around 20ipm halfstep starts stalling
[14:26:49] <jepler> and full step doesn't?
[14:26:54] <skunkworks_> correct
[14:27:58] <skunkworks_> it is actually running full step just fine.. But I thought it would be neat to see if I could emulate the origninal control.
[14:28:55] <skunkworks_> plus it gets me a whole .00025 vs .0005 (ish) resolution.
[14:29:11] <skunkworks_> (at cutting speeds)
[14:43:08] <skunkworks_> I thought there was a comparator that did a historisis...
[14:43:59] <jepler> comp - Two input comparator with hysteresis
[14:44:23] <skunkworks_> ah - I thought comp was for building comps.. heh
[14:44:50] <cradek> funny that
[14:45:21] <jepler> yeah that's why the build at some step executes comp --compile comp.comp
[14:46:05] <skunkworks_> so - is there a binary mux? or do I either have to make a componant or use a bunch of and gates.
[14:46:14] <skunkworks_> ?
[14:46:25] <jepler> oh are the existing muxes for floats? I dunno about that
[14:46:38] <skunkworks_> everyone I read show floats.
[14:46:52] <cradek> how can you have hysteresis for bits?
[14:47:13] <cradek> oh you're talking about something else now
[14:47:15] <jepler> comp output is to the sel of mux
[14:47:16] <skunkworks_> I am using axis velocity to tell when to switch between the two step gens
[14:47:22] <jepler> stepgen outputs are to the inputs of mux?
[14:47:38] <skunkworks_> the outputs of the stepgens will get swtched to the printer port
[14:48:00] <skunkworks_> right
[14:48:25] <cradek> can't you make a binary mux with two ands and an or, or 'logic' or whatever we call it?
[14:48:46] <skunkworks_> 2 ands and an invert..
[14:49:39] <jepler> you could do a 2-input mux with lut5 if you could just figure out the proper .function
[14:49:57] <cradek> aren't you going to lose position when you do this?
[14:49:57] <cradek> seems like you'll sometimes lose partial steps when you switch modes
[14:49:57] <skunkworks_> crap - invert is also a flaot heh
[14:50:09] <cradek> not
[14:50:15] <skunkworks_> there we go
[14:50:37] <cradek> invert should've been called reciprocal
[14:51:04] <skunkworks_> cradek, I don't know... It will switch within +/- step I would think...
[14:51:11] <skunkworks_> I think it is a fun experiment anyway...
[14:51:27] <cradek> yeah whether the loss is cumulative is the question
[14:51:42] <cradek> I'm guessing it will be and you'll have to hack stepgen instead
[14:51:59] <skunkworks_> well - the stepgens ar absolute... - so It would have to lose a whole cycle
[14:52:14] <jepler> I think that lut5 with function 202 will act as a bool mux
[14:52:33] <jepler> in0 and in1 are the two inputs and in2 is the mux select
[14:52:49] <skunkworks_> ooh - that would be cool. Thanks!
[14:52:56] <skunkworks_> I will play with it.
[14:55:22] <jepler> if lut5 doesn't seem to work for that purpose, or if you're curious, I can walk you through the process that I used to find the number 202
[14:56:02] <skunkworks_> ok - I will try it.
[15:06:01] <skunkworks_> heh - I just assumed motion had a velocity for each axis.
[15:06:26] <skunkworks_> so ddt it is
[15:19:31] <cradek> pretty sure it does
[15:46:34] <jepler> skunkworks_: it is interesting to contemplate what if stepgen counts were a pin so you could control it with the same signal you use to select half vs full steps
[15:52:55] <jepler> then you might be able to use one stepgen in position mode
[15:58:48] <jepler> there would still be some details because hal can't make an adequate guarantee about the fast thread seeing the "switch to full step mode" and the updated internal "dds counts per fast thread" value at the same time
[15:59:17] <jepler> which points towards enhancing stepgen with two(?) different scales and a select bit as an *output*
[18:18:23] <skunkworks> jepler - manually testing - lut2 202 works as predicted
[18:20:45] <skunkworks> cradek: I don't see an per axis velocity - am I missing something?
[23:47:16] <memleak> gabewillen, hello
[23:47:29] <memleak> gabewillen, you know, for linuxcnc dev chat we dont need to be in PM
[23:48:02] <memleak> if we're talking about ducati vs suzuki racing bikes, thats one thing though.
