Back
[08:49:07] <fuzzy7k> seb_kuzminsky: I'm liking your willingness to support gentoo ebuild's. They are far more easily written by software maintainers than some yahoo, who knows nothing of the build features, or third party software packages required to build and run the software.
[08:50:54] <fuzzy7k> I will say though, that EBo has taken the right approach on implementing this, even if it is lagging behind. For two reasons:
[08:51:20] <fuzzy7k> 1, ebuilds need to be in the portage tree to be used by portage
[08:52:29] <fuzzy7k> 2, since the ebuild contains the source URL, ideally one wants the ebuild before the source is ever fetched.
[08:56:00] <fuzzy7k> Here's some more food for thought...
[08:58:40] <fuzzy7k> Once the ebuild has been written, maintaining it is stupid simple. As long as no dependency or feature changes have been made to the source, a version bump is as simple as renaming the ebuild file with the new version. with one catch...
[08:59:50] <fuzzy7k> In order for portage to accept the ebuild, it must have a manifest, which is a hash of the source files and ebuild.
[09:00:49] <fuzzy7k> This allows portage to do automatic file integrity check before extracting, compiling, etc.
[09:03:44] <fuzzy7k> One could probably do this in a third party os, but it is usually something done within gentoo (e.g. ebuild linuxcnc-2.6.ebuild digest)
[09:06:18] <seb_kuzm1nsky> fuzzy7k: thanks for the education!
[09:06:25] <seb_kuzm1nsky> we do something similar with debian packaging
[09:06:53] <fuzzy7k> So, there are a couple levels on which one could support ebuilds, from generating versioned ebuild inside the linuxcnc source that the user could extract and digest himself, to providing an overlay with the digests already complete.
[09:07:07] <seb_kuzm1nsky> we have some of the debian packaging metadata in the repo, and we have a script that generates the rest of it as needed
[09:07:43] <seb_kuzm1nsky> this script get run on the buildbot each time anyone commits, and the buildbot generates all the debian packaging files and builds debs
[09:07:57] <seb_kuzm1nsky> ideally i'd like the ebuilds handled the same way, if possible
[09:08:53] <seb_kuzm1nsky> fuzzy7k: here's a log of the most recent 2.6 build on the buildbot making debian packages:
http://buildbot.linuxcnc.org/buildbot/builders/3003.dsc-wheezy/builds/729
[09:09:43] <seb_kuzm1nsky> mayb someone who knows ebuild could cook up a similar set of steps for generating ebuild files from stuff in the repo
[09:10:10] <seb_kuzm1nsky> ... and also volunteer to run a gentoo buildslave to do the work
[09:10:26] <seb_kuzminsky> then i'll do the buildmaster side of things
[09:10:52] <fuzzy7k> cool, actually, generating ebuilds would be simpler.
[09:24:53] <fuzzy7k> seb_kuzminsky, are you Bari on the ml?
[09:26:16] <cradek> seb is not bari
[09:27:09] <seb_kuzminsky> naw i'm seb ;-)
[09:27:17] * seb_kuzminsky <-- seb
[09:27:32] <cradek> I've seen them in the same room, so I know they are distinct
[09:28:15] <seb_kuzminsky> fuzzy7k: who are you on the mailing list?
[09:28:23] <fuzzy7k> heh, cool. So we have two distinct, real people who want to support this. Great!
[09:28:57] <fuzzy7k> uhh, Kyle. kvans32@g
[09:29:00] <seb_kuzminsky> aha
[09:29:44] <seb_kuzminsky> i dont personally care about gentoo, but i want to support you folks who do
[09:30:27] <seb_kuzminsky> what kernels are available on gentoo? is there an rtai kernel or an rt-preempt kernel?
[09:30:55] <seb_kuzminsky> does gentoo have distinct releases, or is it continuous rolling updates?
[09:31:06] <seb_kuzminsky> i'm the jon snow of gentoo
[09:31:20] <fuzzy7k> yes, rt-sources is in the main portage tree, and trai is something ebo has in gentoocnc
[09:31:25] <fuzzy7k> rolling
[09:44:11] <fuzzy7k> That brings up a question I was having. I'm trying to decide what kernel to use. Was thinking rt- since I'm familiar with it, but 3.x versions have not been unmasked for x86. Since the machine this will be running on is stepper based, and has no feedback (except my brother standing by watching it), rt is not even a necessity. Will linuxcnc run on a recent vanilla PREEMPT kernel, or will it give me an I'm stupid warning?
[09:48:23] <CaptHindsight> fuzzy7k: premmpt_rt or RTAI works, xenomai is only supported in that dev branch that was forked off to become machinekit
[09:49:08] <seb_kuzminsky> fuzzy7k: are you using software step generation or do you have a mesa or pico board generating steps for you?
[09:49:39] <seb_kuzminsky> if you use software stepgen you need the best possible latency, because that will be the limiting factor on your step rate (and hence machine travel speed)
[09:49:54] <seb_kuzminsky> so in that case you should measure latency with all the kernels and pick the best one
[09:54:53] <fuzzy7k> Ok, understood. it is software step. Does linuxcnc buffer the output step generation, or is the speed limit a result of being able to feed the buffer to the paraport fast enough. I would have thought the paraport ran at a fixed requency.
[09:56:12] <CaptHindsight> not buffered
[09:57:27] <fuzzy7k> ok, i'm gonna look into why rt-preempt has not been unmasked on x86
[09:59:13] <fuzzy7k> It's bari!
[11:04:21] <skunkworks> is int(round( a valid way to convert a float to an int in python?
[11:05:24] <skunkworks> not worried about negative numbers.
[11:12:13] <jepler> skunkworks: [describing how int(x) works] If x is a number, it can be a plain integer, a long integer, or a floating point number. If x is floating point, the conversion truncates towards zero.
https://docs.python.org/2/library/functions.html#int
[11:15:00] <jepler> so yes, as long as the rounding done by round() is appropriate to your requirements, that's a perfectly legitimate way to get an integer when what you started with was a float
[11:18:23] <skunkworks> Thanks - the circle finder returns a float - I then want to draw the circle which takes ints..
[11:18:32] <jepler> ah I see
[11:24:55] <jepler> >>> nf = 1e300 * 1e300
[11:24:55] <jepler> >>> na = nf-nf
[11:25:03] <jepler> these numbers nf and na don't convert to integers with int(round(x))
[11:25:08] <jepler> but I doubt you care about that
[11:25:33] <skunkworks> that would be one hell of a high resolution camera...
[11:50:01] <jepler> I feel andy's pain
[11:50:01] <jepler> > Why will nobody believe me when I say that my experiment was rubbish?
[11:50:32] <KGB-linuxcnc> 03Norbert Schechner 052.6 a9b06b4 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_3_4 - virtual keyboard "bug" not initialized settings correct * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a9b06b4
[11:51:27] <KGB-linuxcnc> 03Norbert Schechner 052.7 f888c6d 06linuxcnc Merge branch '2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f888c6d
[11:51:33] <cradek> I believe him
[11:52:30] <KGB-linuxcnc> 03Norbert Schechner 05master f67038f 06linuxcnc Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f67038f
[11:52:56] <CaptHindsight> because it's a *duino, they have special powers
[11:53:07] <cradek> well done norbert!
[12:12:59] <pcw_home> customer issue:
[12:13:00] <pcw_home> "If I run as a standard user I get permission denied on RTAPI_APP"
[12:13:02] <pcw_home> Is this a sign of not running the sudo make setuid step?
[13:27:54] <cradek> pcw_home: too bad you didn't get the real error message
[13:30:29] <skunkworks> zlog
[13:30:45] <pcw_home> Yeah, I'll try and get the actual error
[13:31:04] <cradek> more important I bet: what he did and what he's trying to run
[13:31:17] <cradek> it could just be built wrong like you suspect
[13:31:59] <cradek> andypugh: I believe you that your arduino experiment was rubbish.
[13:32:54] <skunkworks> Me too.. :)
[13:33:02] <andypugh> It is frustrating when people insist on me sending them boards even after I have told them that I abandoned the idea.
[13:33:07] <skunkworks> (I acutally played with one..)
[13:34:04] <skunkworks> andypugh: how is the ner-a-car?
[13:34:07] <andypugh> I think it is a perfectly usable way to get Hall sensor signals out of a Resolver, but otherwise it is nothing like as effective as the Mesa card, which is great.
[13:34:50] <andypugh> I trusted it enough to go to work on it today. A mis-placed trust. Luckily I work for a company that makes vans and I pnly had to push it 2 miles.
[13:35:05] <cradek> oh my
[13:35:25] <cradek> how bad a failure?
[13:35:26] <skunkworks> The 1000 ppr is a bit low for motion control..
[13:36:28] <cradek> I pushed my bike two blocks once and it was not a fun experience. I can't imagine two miles.
[13:36:59] <andypugh> I was extremely damp when I arrived at work.
[13:37:17] <jepler> oh if there's anything cradek hates, it's being damp.
[13:37:42] <andypugh> And it’s a really trivial failure, the cable that engages the friction wheel broke at the nipple.
[13:38:06] <andypugh> (I was dressed in riding-a-bike-in-November gear)
[13:38:40] <seb_kuzminsky> wtf did i just email to the list
[13:39:38] <jepler> seb_kuzminsky: I dunno, gpg offers to decrypt it and then fails
[13:40:00] <seb_kuzminsky> wow i'm a moron
[13:40:06] <seb_kuzminsky> someone revoke my internet access
[13:41:20] <jepler> gpg: encrypted with ELG-E key, ID 62929378
[13:41:20] <jepler> gpg: encrypted with RSA key, ID DD181228
[13:41:20] <jepler> gpg: decryption failed: secret key not available
[13:42:15] <seb_kuzminsky> maybe i updated or restarted my icedove, and it updated its enigmail plugin, and that changed my default settings to encrypt everything (with the wrong key)?
[13:42:19] <seb_kuzminsky> let me try again...
[13:47:35] <jepler> luckily I don't have any resolvers, or I'd see if the teensy 3.1 makes a better resolver converter (72MHz ARM, 2 independent 13-bit analog converters)
[13:49:09] <cradek> I could loan you a resolver
[13:49:22] <skunkworks> heh
[13:50:24] <jepler> nooo
[13:50:38] <andypugh> I _really_ like resolvers.
[13:51:29] <jepler> nasty icky analog technology
[13:51:37] <jepler> give me two beautiful square waves, 90 degrees apart...
[13:52:16] <andypugh> Ah, but those swuare waves are analog and less square when in the wires.
[13:52:35] <jepler> now you're just trying to make me cry
[13:52:41] <andypugh> And if they get corrupted then you are not where you think you are for the rest of the day.
[13:53:04] <andypugh> Whereas a glitch in a Resolver is corrected immediately.
[13:53:46] <jepler> up to a half revolution or so
[13:54:18] <andypugh> Yes, granted.
[13:58:48] <jepler> so decoding the angle of a resolver is just theta = atan2(vs, vc) ?
[14:02:29] <andypugh> Yes
[14:02:47] <andypugh> But ideally sampled at the voltage peak.
[14:03:30] <andypugh> (I have wondered if you could rectify the signals to get an easier measurement, an Op-Amp can be an ideal rectifier)
[14:06:44] <jepler> rectify, so that you only deal with one quadrant instead of 4 in atan?
[14:06:53] <jepler> or some other meaning of rectify?
[14:10:08] <andypugh> My board offsets the resolver output to make it unipolar anyway, so there would still be 4 quadrants. Maybe I mean peak-hold, but I am sure I decided it needed an ideal rectifier too.
[14:11:59] <PCW> Most resolver converters are velocity locked loops
[14:12:33] <PCW> and dont do Arctan at all
[14:13:35] <andypugh> Maybe I should have tried diffferent algorithms, but the 1kHz excitation and low-resolution analog was enough to put me off.
[14:13:55] <andypugh> (Especially when I had a 7i49 doing nothing…)
[14:14:15] <PCW> Analog devices has some nice papers
[14:16:08] <jepler> it should have occurred to me that there were dedicated resolver-to-digital chips out there
[14:16:19] <jepler> now reading ad2s1210 datasheet
[14:16:53] <jepler> The maximum tracking rate is 3125 rps.
[14:17:46] <PCW> high velocity is easy, accel is the noise/tracking rate compromise
[14:32:13] <andypugh> So, if I re-has the lincurve docs, which bracnh should I do it in?
[14:33:29] <jepler> andypugh: 2.6.
[14:34:50] <andypugh> OK, that was my guess as docs can’t break anything
[14:35:12] <jepler> "can't" is a bit strong, but it stands a higher chance of being safe than a lot of things
[15:17:19] <PCW> hmm 7i90.ini in hm2-servosample files has the card name wrong (7I90 should be 7i90)
[15:24:33] <jepler> oops
[15:25:27] <jepler> [HOSTMOT2]
[15:25:27] <jepler> DRIVER=hm2_7i90
[15:25:27] <jepler> BOARD=7i90
[15:25:54] <jepler> am I looking in the wrong place?
[15:25:55] <jepler> linuxcnc/configs/by_interface/mesa/hm2-servo
[15:26:31] <PCW> Its probably my fault, this is much worked over
[15:28:26] <PCW> not sure what ISO version it started as
[17:28:06] <andypugh> If the lincurve X and Y point definition inputs were pins not paramters then they could be the outputs of other lincurves, for almost infinite complexity and confusion.
[17:30:16] <PCW> you could also connect them in a loop to solve equations
[17:31:24] <PCW> and re-invent the diode function generator part of the analog computer
[17:38:05] <andypugh> Maybe I should make the change in Master
[18:10:55] <KGB-linuxcnc> 03andy pugh 052.6 6c60c36 06linuxcnc 10src/hal/components/lincurve.comp Signed-off-by: andy pugh <andy@bodgesoc.org> * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6c60c36
[18:11:37] <andypugh> Oh, I forgot the commit message, it has been so long. Bother
[18:53:55] <seb_kuzminsky> andypugh: thanks, that's much better
[19:17:37] <PCW> seb_kuzminsky: did you have a chance to update wheezys mesaflash? the distributed one seems to be broken
[20:48:07] <seb_kuzm1nsky> PCW: i tried but there was a problem with the mesaflash 3.1 branch.
[20:48:21] <seb_kuzm1nsky> i told micges about it, he said he'd fix it and let me know
[20:48:34] <seb_kuzm1nsky> once he does it should be pretty quick to build & push to the wlo debian archive
[22:47:20] <seb_kuzminsky> zlog:
[23:51:39] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 8a0bd68 06linuxcnc 10docs/src/Submakefile docs: support top-level html file * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8a0bd68
[23:51:39] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 c518d77 06linuxcnc Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c518d77