Back
[00:12:28] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.5-hm2-encoder-rawcounts-fix f4adcab 06linuxcnc 10src/hal/drivers/mesa-hostmot2/encoder.c 10src/hal/drivers/mesa-hostmot2/hostmot2.h fixup * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f4adcab
[01:22:03] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.5-hm2-encoder-rawcounts-fix 343c428 06linuxcnc 10src/hal/drivers/mesa-hostmot2/encoder.c fixup - simplify driver initialization * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=343c428
[01:23:43] <seb_kuzminsky> ok check this out
[01:24:16] <seb_kuzminsky> with the current tip of the v2.5_branch, 52dc6f18:
http://pastebin.ca/2762044
[01:24:54] <seb_kuzminsky> when you connect a net to the hm2 encoder .rawcounts pin, the pin takes on the value of the net, and position jumps
[01:25:13] <seb_kuzminsky> (when you disconnect rawcounts from the net, it reverts to its previous value)
[01:28:23] <seb_kuzminsky> with the 2.5-hm2-encoder-rawcounts-fix branch, 343c428:
http://pastebin.ca/2762051
[01:28:50] <seb_kuzminsky> when you connect the net to .rawcounts, the *net* takes on the value of the *pin*, as it should, and there's no position jump
[01:37:14] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.5-hm2-encoder-rawcounts-fix 7b0c303 06linuxcnc 10src/hal/drivers/mesa-hostmot2/encoder.c 10src/hal/drivers/mesa-hostmot2/hostmot2.h hm2: make encoder.rawcounts an Out pin, as claimed * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7b0c303
[01:38:24] <seb_kuzminsky> kgb doesn't make it clear, but that was a force-push of the encoder-fix branch, with the two fixup commits squashed
[01:38:52] <seb_kuzminsky> cradek: i think that should go in 2.5
[01:39:50] <seb_kuzminsky> and we should probably audit the drivers and make sure they all use Out pins only as the destinations of assignments
[01:40:22] <seb_kuzminsky> sounds like a job for a static analyser, but i dont know how to tell clang to look for that
[01:40:53] <seb_kuzminsky> one of my work mates is a clang developer, i'll ask him tomorrow
[09:20:28] <cradek> looks like you already can't get beaglebones
[09:28:21] <seb_kuzminsky> they're making a new rev (rev C, more on-board flash storage) and the production line burped
[09:29:20] <seb_kuzminsky> https://www.sparkfun.com/products/12857
[09:31:11] <CaptHindsight> allwinner soc's are available now in the RPi and duino format, so you can use the shields/capes/sarapes/cloaks/expansion boards
[09:31:21] <cradek> seb_kuzminsky: I think lots of components read from their out pins, but only after setting them. I'm struggling to understand what's right and wrong behavior of a component.
[09:32:04] <cradek> (and I didn't verify that)
[09:33:24] <archivist> would that be for previous state
[09:33:33] <seb_kuzminsky> it may or may not be previous state
[09:34:26] <seb_kuzminsky> if you create a net, set the value of the net with 'halcmd sets', then connect the output pin to the net, then the comp reads the pin, it'll see the net's value, not the previous thing the comp wrote to the pin
[09:34:43] <seb_kuzminsky> i'm pretty sure that's the root cause of bug #374
[09:35:29] <cradek> is that fixed by the first blob of
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blobdiff;f=src/hal/hal_lib.c;h=847e584f852b0092f8d05835b5e98eb93651be4e;hp=bf05ec2fb224b4414796b9c7386cd1dc473a544a;hb=7220cb7846fafdcb26c2ebcf919032553f87d99f;hpb=39cf1690cbe86ac0f7f7da2859d28ec5adbb7914
[09:35:39] <seb_kuzminsky> i *think* the correct behavior is to never read Out pins - they should never be rvalues
[09:36:09] <cradek> can you sets an unconnected signal?
[09:36:13] <seb_kuzminsky> yeah
[09:36:19] <cradek> huh
[09:36:26] * seb_kuzminsky blinks at that commit
[09:36:54] <seb_kuzminsky> brb
[09:36:56] <cradek> the log message on that commit is good
[09:38:12] <seb_kuzminsky> oh, i see
[09:38:21] <seb_kuzminsky> that commit is in 2.6 and master, but not in 2.5 where i was doing my testing
[09:38:26] <cradek> yes
[09:38:33] <cradek> I'm wondering if it should be
[09:39:23] <seb_kuzminsky> hmm
[09:39:48] <seb_kuzminsky> i dont have time to try it out right now, but it seems like it maybe should be? it seems strictly better than the behavior before
[09:39:51] <seb_kuzminsky> brb
[09:40:44] <cradek> it would be interesting to know if it would have avoided the hm2 bug, which I still don't quite understand (surely nobody's config was sets-ing an unconnected signal?)
[09:41:19] <cradek> if it nukes a whole class of bugs (that we don't have a good way of finding) then it is clearly a good idea to incorporate it
[09:46:32] <seb_kuzminsky> pncconf accidentally(?) sets-s hm2 encoder.rawcounts to an otherwise unconnected signal
[09:47:07] <cradek> you mean links?
[09:47:34] <cradek> but unwritten signals start at zero
[09:47:41] <cradek> I don't see why it would break
[09:48:27] <seb_kuzminsky> http://www.linuxcnc.org/index.php/english/forum/49-basic-configuration/26982-dro-values-not-zero-on-startup?start=16
[09:49:24] <seb_kuzminsky> the bug affects 5i25 and 6i25, which don't get flashed with firmware on linuxcnc start, so if they were running before the encoder count register will be non-zero at startup
[09:49:38] <cradek> ohhhhhh
[09:49:45] <cradek> and this steps it to 0
[09:50:02] <cradek> which is a huge and random change
[09:50:08] <seb_kuzminsky> right
[09:50:27] <cradek> I get it now, thanks
[10:05:36] <cradek> seb_kuzminsky: did you see the bug happen in 2.6, even with the dummysig/link change?
[10:06:22] <cradek> or did you just find and fix the code problem
[10:15:29] <seb_kuzminsky> nope, didn't look at 2.6 at all
[10:15:34] <seb_kuzminsky> just fixed hm2 in 2.5
[10:15:54] <seb_kuzminsky> the general fix is probably better
[12:17:51] <KGB-linuxcnc> 03Michael Haberler 05v2.5_branch 51a0afc 06linuxcnc 10src/hal/hal_lib.c hal/link/unlink: revise semantics of hal_link()/hal_unlink(): * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=51a0afc
[12:19:31] <seb_kuzminsky> cmorley: that commit ^^^^ cherrypicked by cradek from 2.6 into 2.5 should fix the "crazy dro when you link hm2 encoder rawcounts to a net" bug you pointed out last night
[14:34:35] <PCW> seb_kuzminsky: it does look like mhaberlers patch fixes the rawcounts bug (master as of a week or so ago is OK)
[14:35:10] <PCW> (just tested with 5i25/7i77)
[14:59:59] <seb_kuzminsky> PCW: thanks for checking
[15:01:05] <seb_kuzminsky> could you test v2.5.4-15-g51a0afc? it should work too
[15:01:36] <PCW> if i pull master will I get that?
[15:01:47] <PCW> oh 2.54
[15:01:52] <seb_kuzminsky> if you pull from git.linuxcnc.org you'll get all updated branches, including 2.5 and master
[15:02:20] <PCW> git pull
[15:02:22] <PCW> git checkout 2.5.4?
[15:02:22] <seb_kuzminsky> then you'll have to check out v2.5_branch ('git checkout v2.5_branch') and build it
[15:02:25] <Connor> Speaking of that.. I updated the other day and got a 2.7
[15:02:36] <Connor> I want to stick with 2.6..
[15:02:58] <seb_kuzminsky> Connor: you probably got 2.7.0~pre0, which is what the master branch is called now
[15:03:10] <seb_kuzminsky> that's what the 2.7 branch will be made from, at some point in the future
[15:03:25] <seb_kuzminsky> Connor: wait, do you mean 'git fetch' or 'apt-get update'?
[15:03:43] <Connor> apt-get update
[15:03:54] <Connor> I thought there was a 2.6 branch..
[15:04:12] <seb_kuzminsky> i see
[15:04:25] <seb_kuzminsky> yes, there are 2.6 debs available, you have to change your apt sources
[15:04:29] <seb_kuzminsky> just a sec
[15:04:45] <seb_kuzminsky> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?UpdatingTo2.6
[15:05:10] <Connor> okay. Cool
[15:05:35] <seb_kuzminsky> i guess since you got 2.7~pre debs you're using the 'master' component from the buildbot deb archive, switch to the 2.6 component and you should be good
[15:05:38] <seb_kuzminsky> brb
[15:05:52] <Connor> I am.
[15:26:13] <seb_kuzminsky> Connor: apt won't automatically downgrade from 2.7.anything to 2.6.anything, but you can tell it to do it
[15:26:23] <seb_kuzminsky> switch your apt source from master to 2.6 & update
[15:26:54] <seb_kuzminsky> then 'apt-cache policy linuxcnc' will show the available versions (a couple of 2.6.something varieties) and the installed version (2.7.something)
[15:27:23] <PCW> latest 2.5 fixes rawcounts issue
[15:27:38] <seb_kuzminsky> yay!
[15:28:18] <seb_kuzminsky> Connor: then you can force a downgrade with "apt-get install linuxcnc=1:2.6.0~pre2.something.gsomething"
[15:28:45] <seb_kuzminsky> there must be ways to do it with the other apt managers too, but i dont know off the top of my head how to select a specific version with them
[15:29:21] <Connor> Cool. Thanks.
[15:29:25] <seb_kuzminsky> sure :-)
[15:30:29] <PCW> Sorry I didnt file a bug report the problem was worked-around and I promptly forgot about it
[15:35:17] <seb_kuzminsky> i'm glad we found out about it eventually and could fix it for everyone
[15:35:49] <seb_kuzminsky> iirc you have to make an account on sourceforge and log in before you can open a bug report, i wonder if that's an obstacle for people to report bugs
[15:42:00] <PCW> another reason to do it later
[15:42:22] <seb_kuzminsky> yeah, that's a bummer
[15:42:36] <seb_kuzminsky> reporting bugs should be as easy as possible
[15:43:07] <seb_kuzminsky> i wonder if we can relax the 'must be logged in' requirement, and if that would cause the spambots to swarm
[15:44:03] <PCW> not sure what excites them
[15:50:50] <seb_kuzminsky> PCW: does the connector-name typo in the 5i24 manual mean that we need to change the connector names reported by the hm2_pci driver for the 5i24?
[15:54:02] <PCW> probably... sigh
[15:55:38] <seb_kuzminsky> i guess the silkscreen on the pcb is the gold standard
[15:55:59] <seb_kuzminsky> everyone's configs will become broken....
[15:56:33] <PCW> the IDROM should have this stuff in it...
[15:58:28] <PCW> Luckily there wasn't enough room on the card silkscreen or I might have got that wrong also
[15:58:37] <seb_kuzminsky> haha
[16:20:00] <cradek> fwiw (not much), I've never heard someone comment that signing up on sf is an obstacle to reporting a bug
[16:20:13] <cradek> usually I think they don't even think of reporting it on the tracker
[16:20:51] <seb_kuzminsky> the set of people who won't bother to make an sf account to report a bug probably also won't bother to send an email reporting that fact
[16:21:29] <seb_kuzminsky> btu i agree with your second statement, that it's just not how "those people" operate
[16:21:59] <seb_kuzminsky> which is why folks like cmorley and andypugh are so awesome, for talking to them in the way they want to talk (ie on the forum)
[16:22:12] <cradek> yes
[16:22:56] <seb_kuzminsky> (err, and pcw and anyone else who talks on the forum, but i dont know who they are because i never talk on the forum)
[16:23:32] <cradek> noticing when a thing that goes by is a bug report (among all the other things that aren't bug reports) takes very special skill
[16:24:47] <cradek> I found a thing that I think would let anyone create a bug report
[16:26:01] <cradek> if I knew turning it on was a good idea, I'd turn it on
[16:26:37] <cradek> although this must be wrong, because it says only the 11 administrators can create bugs, and I know that's wrong
[16:26:52] <seb_kuzminsky> does it also put some kind of captcha between the interwebs and our precious pile of bugs?
[16:26:59] <seb_kuzminsky> if so i'd say turn it on
[16:29:04] <cradek> nope
[16:30:42] <seb_kuzminsky> lol @ #376
[16:31:03] <cradek> I deleted it
[16:32:11] <cradek> there is such a thing as moderated comments
[16:32:31] <seb_kuzminsky> maybe we won't need it? maybe i'm naive?
[16:32:50] <seb_kuzminsky> why did i phrase those statements as questions?
[16:32:53] <cradek> well we can apparently just delete the noisy ones
[16:33:09] <seb_kuzminsky> thanks for making that change
[16:33:15] <cradek> we'll surely, uh, get lower-quality bug reports
[16:33:27] <cradek> well I changed it back
[16:33:36] <cradek> I just wanted to see how it worked
[16:34:13] <cradek> I think I'm against the change
[16:34:25] <seb_kuzminsky> ok
[16:34:35] <cradek> a bug report without being able to communicate with the reporter is much less useful
[16:35:04] <seb_kuzminsky> as an anonymous bug reporter you dont have to type in your email?
[16:35:05] <cradek> signing up on sf links to your email, so we can have some communication
[16:35:08] <cradek> nope
[16:35:12] <seb_kuzminsky> ah :-/
[16:36:11] <cradek> I'm not pretending I have the final word, but I'm on the "nah" side of the fence right now
[16:39:10] <seb_kuzminsky> since these anonymous bug reports are not tied to the reporter's email, i'm opposed as well
[17:33:38] <andypugh> Oh dear. Aram is using version 2.2 and the hal_m5i20 driver. With no velocity output pin. Watch him blame me for makig him buy the wrong hardware…
[17:35:16] <seb_kuzminsky> you should fix 2.2 so it works for him, and write better docs while you're at it
[17:35:32] <andypugh> But only for 2.2, of course.
[17:36:49] <andypugh> “I am not an electrical engineer or programmer and I am not prepared to learn anything, but demand to be able to use LinuxCNC” is a bit like saying “I want to take up swimming, but I refuse to get wet”
[17:37:27] <seb_kuzminsky> if you'd just write a better description of how to swim, then i could learn without getting wet
[17:37:32] <PCW> well d/dt of position will work(assuming 2.2 has D/DT comp)
[17:37:48] <seb_kuzminsky> seriously your docs are terrible and that makes you a terrible person
[17:38:06] <andypugh> He is going to live the ddt docs:
http://www.linuxcnc.org/docs/2.2/html/man/man9/ddt.9.html
[17:38:23] <andypugh> (love)
[17:38:30] <seb_kuzminsky> haha
[17:38:34] <PCW> not a lot of wasted verbiage
[17:39:00] <andypugh> Even I think that is a little too terse.
[17:39:29] <seb_kuzminsky> what's the next kind of alien more alien than martians? that's who the 2.2 ddt docs are for
[17:40:50] <andypugh> The new version is worse, it uses the [ | ] [,]] sort of rubrik with no explanation.
[17:41:40] <andypugh> | for “or” and {} for optional really _is_ programmer-speak.
[17:41:54] <seb_kuzminsky> i can see how the new syntax is off-putting to people not used to reading manpages
[17:43:40] <andypugh> Three or four separate valid loadrt command examples might be clearer.
[17:43:58] <seb_kuzminsky> and let people extrapolate the rules from the examples? maybe.
[17:44:00] <seb_kuzminsky> maybe both?
[17:44:12] <seb_kuzminsky> maybe we could add an EXAMPLES section to the manpages?
[17:44:39] <andypugh> The auto-generated pages emerge from comp don’t they? It might not even be so hard.
[17:45:02] <seb_kuzminsky> but i'm opposed to removing the part that unambiguously explains how it works to people who understand the (very standard) manpage syntax
[17:45:03] <PCW> I think both is better (formal syntax + example)
[17:45:29] <seb_kuzminsky> examples go a long way to making things clearer for novices
[17:45:53] <PCW> (example at bottom including loadrt and addf)
[17:46:12] <seb_kuzminsky> andypugh: yes, comp(1) makes the manpages from the *.comp input files
[17:46:27] <andypugh> In other news, the 12V supply on my mill burst into flames (briefly) this evening.
[17:46:36] <PCW> its a lot of redundant information but less bewildering
[17:47:18] <PCW> thats not good...
[17:47:31] <seb_kuzminsky> i wonder if there's a programmatic way to generate example .hal snippets from a .comp file
[17:47:45] <seb_kuzminsky> that's both correct and helpful
[17:49:01] <seb_kuzminsky> and i'm afraid that if we do, it still won't get Aram past his hurdles :-/
[17:49:28] <andypugh> Does it make me a bad person that I want him to switch to Mach?
[17:50:58] <PCW> Right now on my desk I have a SD94 (servo Dynamics) to 7I33 PCB
[17:51:00] <PCW> that I made specifically to end wiring questions...
[17:59:17] <andypugh> Examples could be readily inserted in comp.g around line 763.
[17:59:22] <andypugh> But not by me, tonight.
[19:21:20] <agwn> running preempt_rt kernel and trying to "loadrt threads name1=fast period1=1000000"
[19:21:24] <agwn> am getting the error rt HAL_LIB: ERROR: clock period to long: 4000000
[19:24:17] <agwn> running latency-test has same result...
[19:26:07] <agwn> doesnt seem to care what period i set. always gives same error?
[19:39:53] <skunkworks> logger[psha]:
[19:39:53] <logger[psha]> skunkworks: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-05-21.html
[19:48:03] <skunkworks> aram told me my laptop was defective because it didn't run the tuning software for his drives from the cd... (the cd only had docs on it)
[20:21:46] <KGB-linuxcnc> 03Michael Geszkiewicz 052.6 34a0807 06linuxcnc 10src/hal/drivers/mesa-hostmot2/encoder.c 10src/hal/drivers/mesa-hostmot2/hostmot2.h hm2: Bring out A, B and INDEX inputs to hal pins. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=34a0807
[20:21:46] <KGB-linuxcnc> 03Michael Geszkiewicz 052.6 bf1c842 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_pci.c hm2: fix typo in 5i24 connector numbers * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bf1c842
[20:23:34] <micges> seb_kuzminsky: ^^ first change is simply forward 3 bits from encoder status reg to hal pins
[20:50:51] <skunkworks> micges: have you beat the new driver into submission?
[20:52:15] <micges> working on it atm
[21:27:20] <cmorley> good news seb_kuzminsky. Thanks for fixing it.
[21:28:48] <kwallace2> Does anyone remember someone that had a really thorough write up on a Shizuoka mill with tool changer, maybe Karl Cunningham?
[21:31:07] <kwallace> Darn, got bumped off.
[21:33:25] <seb_kuzminsky> looks good micges
[21:37:37] <KGB-linuxcnc> 052.5-hm2-encoder-rawcounts-fix 7b0c303 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7b0c303
[21:39:13] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 5221646 06linuxcnc Merge remote-tracking branch 'origin/v2.5_branch' into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5221646
[21:40:04] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master bea2b51 06linuxcnc Merge remote-tracking branch 'origin/2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bea2b51
[21:57:13] <seb_kuzminsky> cmorley: thanks for taking #375
[21:57:33] <cmorley> no problem