Back
[12:25:17] <seb_kuzminsky> i wonder, if i say pcw's name will he show up?
[12:50:46] <skunkworks> normally
[12:51:00] <skunkworks> he is everywere
[13:07:43] <alex_joni> seb_kuzminsky: you need to say pcw_home :)
[13:11:37] <seb_kuzminsky> i got him on email ;-)
[14:08:00] <cradek> seb_kuzminsky: yuck. did you see if it's right in 2.5?
[14:15:29] <seb_kuzminsky> hmm?
[14:15:45] <seb_kuzminsky> what are we talking about?
[14:17:05] <seb_kuzminsky> here's my todo list for 2.6:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Todo-2.6
[14:17:11] <seb_kuzminsky> what did i miss?
[14:17:24] <seb_kuzminsky> feel free to tackle anything that seems interesting ;-)
[14:17:44] <cradek> sorry for being mysterious. I was talking about
https://sourceforge.net/p/emc/bugs/336/
[14:18:03] <seb_kuzminsky> oh, that!
[14:18:34] <seb_kuzminsky> i dont know what it does in 2.5, but i have vague memories of seeing similar things for a long time, so i think 2.5 probably has the same bug
[14:18:47] <cradek> seb_kuzminsky: yuck. did you see if it's right in 2.4?
[14:18:52] <seb_kuzminsky> haha no
[14:18:55] <seb_kuzminsky> 2.3 neither
[14:19:20] <seb_kuzminsky> the program *runs* correctly, it's just the preview that's off
[14:19:43] <cradek> I can neither run nor preview it as-is (see my response)
[14:20:32] <cradek> aside from fixing my tool table so it would load past T101, I didn't go any further
[14:20:58] <seb_kuzminsky> if you comment out the call to that o-sub file, does it run for you?
[14:21:02] <cradek> (I bet there is a more minimal program that shows the problem)
[14:21:15] <seb_kuzminsky> i bet you're right, sorry i haven't found it :-/
[14:21:19] <cradek> trying
[14:21:47] <cradek> when I comment the Ocall I get a correct preview in 2.5.3
[14:22:00] <seb_kuzminsky> aha!
[14:22:04] <cradek> I assume: -0.41 to +3.00
[14:23:37] <cradek> I'll build master to try it with the O-call commented out
[14:24:00] <seb_kuzminsky> i just attached the missing file
[14:24:16] <seb_kuzminsky> bbl
[14:25:50] <cradek> now it's missing quill-up-0.ngc
[14:27:21] <cradek> I guessed what is supposed to be in that file, and I still get a correct preview in 2.5.3
[14:30:19] <cradek> I also get a correct preview in master
[14:30:55] <cradek> i.e. v2.5.3-2309-gb21a72f
[14:41:00] <seb_kuzminsky> i just posted the quill-up program
[14:41:34] <seb_kuzminsky> and yeah, -0.4 to +3.0 sounds right
[14:47:48] <cradek> I still get a correct preview in v2.5.3 and master
[14:49:05] <seb_kuzminsky> lame
[14:49:14] <seb_kuzminsky> hmm
[14:49:24] <cradek> well I can't say whether it's totally correct, but I don't get wild Z like your screenshot has
[14:49:36] <seb_kuzminsky> yeah that's crazy innit
[14:50:18] <seb_kuzminsky> if you have the time, could you test the version of master that i observed it on? might be it got fixed when i wasnt looking
[14:50:38] <seb_kuzminsky> or maybe i have some .ini setting that breaks it for me... i'll test it when i get home tonight
[14:50:55] <cradek> ok I'll try d33b1e3
[14:52:16] <cradek> you must have tags I don't
[14:53:10] <cradek> it's called v2.5.2-2317-gd33b1e3 for me, and it also has a correct preview
[14:54:30] <seb_kuzminsky> strange that it got that name
[14:56:08] <seb_kuzminsky> i just checked out that commit and ran './scripts/get-version-from-git master' and it gave me the expected version, v2.6.0-pre0-4525-gd33b1e3
[14:57:19] <cradek> % ./scripts/get-version-from-git master
[14:57:19] <cradek> no signed tags found, falling back to unsigned tags
[14:57:19] <cradek> v2.6.0-pre0-4525-gd33b1e3
[14:57:19] <cradek> % git describe
[14:57:19] <cradek> v2.5.2-2317-gd33b1e3
[14:57:40] <seb_kuzminsky> ah, maybe you have your gpg public key in your keyring? so it preferred your signed 2.5 tag over the unsigned 2.6 tag?
[14:58:03] <cradek> I'm sure I have it
[14:58:12] <seb_kuzminsky> i wonder why it didnt pick up your 2.5.3 tag
[14:58:39] <seb_kuzminsky> i'll re-test on my machine tonight and report back, but now my dayjob calls
[14:58:43] <cradek> % git reset --hard origin/master
[14:58:44] <cradek> HEAD is now at bdb1670 Absolute Serial Encoders: Further tidying up and introduction of the HM2DPLL module to allow pre-triggering
[14:58:46] <cradek> % git describe
[14:58:48] <cradek> v2.5.3-2340-gbdb1670
[14:58:49] <seb_kuzminsky> thanks for looking at it, & sorry for the noise
[14:58:55] <cradek> I don't know how these things work :-/
[14:59:04] <cradek> sure, np, we'll nail it
[14:59:26] <seb_kuzminsky> git describe walks backwards to the first tag it finds, then prints the name of that tag, the number of commits between HEAD and that tag, and the sha of HEAD
[14:59:36] <seb_kuzminsky> this works poorly when you have a branchy history like we do
[14:59:54] <seb_kuzminsky> so i wrote the get-version-from-git script that restricts tag names based on the branch, which is what we want
[15:00:18] <cradek> well if yours and mine both say d33b1e3, we are testing the same code, right?
[15:00:25] <seb_kuzminsky> yeah
[15:00:33] <cradek> and fwiw, I can't help but see that version as "deebies"
[15:00:54] <seb_kuzminsky> if you say 'git branch --contains deebie', it'll say that master has it but 2.5 doesnt
[15:01:44] <cradek> you are right
[16:00:11] <seb_kuzminsky> andypugh: it's confusing to me that the dpll driver is in 'hm2_dpll.c' - the 'hm2_' prefix was (up until now) used for anyio drivers, not firmware module drivers
[16:00:57] <seb_kuzminsky> likewise for the module name in the manpage and the pins & stuff in hal, they don't need 'hm2' in their name imo
[16:13:46] <seb_kuzminsky> hi micges
[16:14:00] <micges> hi
[16:15:03] <micges> do you have access to mesaflash3 also?
[16:15:49] <seb_kuzminsky> yep, got it
[16:16:09] <seb_kuzminsky> why did you choose to use two separate repos, instead of two branches in a single repo? just curious
[16:17:28] <micges> each one was started from scratch, I wanted clear history
[16:17:56] <micges> it's just 'my way'
[16:18:13] <seb_kuzminsky> cool
[16:19:22] <micges> from interesting parts, mf3 will have all mesa boards support, also all remotes with flashing possibility
[16:19:59] <micges> maybe it will be possible to make some common code with hm2 driver
[16:26:02] <andypugh> seb_kuzminsky: yes, but, well, the module name is hm2dpll, to distinguish it from some other dpll. If you look in IDROMConst.vhd there are two of them. Though I see they both have the same Tag, so I can't see the other one ever being used in hm2)
[16:26:03] <seb_kuzminsky> that'd be nice, but i dont know how that would work
[16:26:22] <seb_kuzminsky> err, my comment was for micges
[16:26:53] <andypugh> I am perfectly happy to change the name, I doubt anyone has used it yet.
[16:26:53] <seb_kuzminsky> looks like mesaflash2 supports both linux userspace and windows, but hm2 is only linux kernel space, so sharing code might not be super convenient
[16:29:45] <micges> seb_kuzminsky: yes
[16:32:48] <seb_kuzminsky> andypugh: since the file is inside the hostmot2 directory, and the pins are under the hm2_$BOARD heading, i think just 'dpll' is unambiguous, no?
[16:33:21] <andypugh> Unless the "other" DPLL appears
[16:33:36] <seb_kuzminsky> micges: you're writing mesaflash for peter, right? i bet he wants it as a stand-alone tool, not as part of the linuxcnc distribution... so developing it in its own repo makes sense
[16:33:58] <seb_kuzminsky> andypugh: what's the difference between the two hostmot2 dpll modules? could they be identified in a way that highlights that difference?
[16:34:26] <seb_kuzminsky> micges: it'd be cool if mesaflash could be built into a debian package that we could put in the www.linuxcnc.org debian archive
[16:34:29] <micges> seb_kuzminsky: yes, exactly
[16:34:37] <andypugh> seb_kuzminsky: Have a look in Hostmot2.h and there is a GTAG 16 and GTAG 26. The new driver is for 26
[16:35:24] <micges> seb_kuzminsky: I could use some help or links how to do that
[16:36:13] <seb_kuzminsky> andypugh: hmm, the regmap we ship with our hm2 firmware debs only mentions one dpll, so i dont know what these two kinds are
[16:36:25] <seb_kuzminsky> micges: i'd be happy to help with that
[16:37:56] <andypugh> Pete wrote the new one during the last couple of months to trigger things for us.
[16:39:00] <andypugh> What it does is fire of an FPGA function at a fixed time before our servo thread runs, so that the data is ready for the servo-thread reads
[16:39:13] <andypugh> (This is cool)
[16:40:03] <seb_kuzminsky> wow, that's wild
[16:42:21] <micges> will be used with 7i80
[16:45:08] <andypugh> So, I too think that the hm2 in the file and pin names is silly.
[16:45:27] <andypugh> But I was just making a non-decision based on what Pete called it
[16:45:52] <andypugh> If you think that either or both should change, I will just do it, no argument from me
[16:46:44] <seb_kuzminsky> i think understand - this hm2dpll is specifically to help the hm2 firmware be better to talk to form the control pc (*cough*linuxcnc)? in that case maybe having hm2 in the name isnt so strange
[16:47:43] <seb_kuzminsky> and it's peter's baby, so since that's what he calls it i guess we should too.
[16:49:03] <andypugh> Yes, I am pretty sure it is only for LinuxCNC
[16:50:37] <seb_kuzminsky> ok, i retract my objection then
[17:18:03] <andypugh> PCW just said that he can drop the other one (even the IDROM file says it is custom and deprecated). So perhaps it makes sense to simplify at least the pin naming if not the file/function names
[17:19:18] <andypugh> But I also think that both potential users will cope with the extra typoing.
[17:39:31] <seb_kuzminsky> yay for simplification!
[17:40:32] <seb_kuzminsky> in that case i reinstate my objection and request that we remove the unused one called 'dpll' and rename the one called 'hm2dpll' to just 'dpll', including renaming the c file and the pins and the config variable and things
[17:41:52] * seb_kuzminsky 's new self portrait: https://lh3.ggpht.com/-k80v3lBFyjI/T2PVqqYh6TI/AAAAAAAACZE/ZW5I8TRPFIw/s640/020+copy.jpg
[17:42:33] <micges> haha
[17:42:42] <micges> enjoy
[17:42:57] <andypugh> seb_kuzminsky: That small berry bothers me. That fact disturbs me.
[17:43:45] <seb_kuzminsky> i'm more worried about that nice place mat - you just know the kids will drip syrup on it and make it all sticky
[17:56:15] <jepler> seb_kuzminsky: I don't really see the likeness, sorr
[17:56:15] <jepler> y
[18:00:55] <seb_kuzminsky> because i'm all waffle-y?
[18:03:24] <andypugh> Kinda square, kinda sweet?
[18:03:59] <seb_kuzminsky> maybe there's a language barrier here
[18:04:33] <cradek> ha
[18:05:26] <jepler> I thought the same thing the whole time I was around andypugh
[18:06:22] <cradek> nah, andy's not nearly as square and sweet as seb is
[18:06:25] <andypugh> Yes, I am surrounded by an almost impetrable language barrier. If it makes you feel any better my own family struggle.
[18:06:47] <cradek> ohhh
[18:08:01] <andypugh> It was ambiguous, I chose my intepretation deliberately
[18:08:14] <jepler> "I'm a linguist, so I like ambiguity more than most people"
[18:11:14] <andypugh> I sent an email to two colleagues earlier in the week mentioning a problem with engine idle speed control. For fun I used the title "Idle Osculation". Then is got forwarded widely, and now I am a little embarassed. Fortunately (and perhaps sadly) none of my colleagues have so far given any reason to believe that they know what that word means.
[18:12:43] <cradek> I had to look it up. sadly, I would have just assumed you didn't know how to spell.
[18:16:25] <andypugh> It's OK for you to be unfamiliar with the langauge, you are foreign :_)
[18:29:11] <andypugh> I think I just thought of another use for Lincurve. I think you can use it to current-limit a really simple servo drive. it could calculate a PWM correction factor based on motor speed (for any _specific_) motor. Because HAL knows everything.
[20:55:57] <KGB-linuxcnc> 03andy 05master ac64b2d 06linuxcnc 10(8 files in 3 dirs) * Rename the Hostmot2 DPLL function to be consistent with other modules.
[21:57:28] <seb_kuzminsky> thanks andy
