Back
[00:05:11] <andypugh> feature request: double clicking a line in the Show-Hal-Config should copy that pin name down to the test hal command box
[00:05:33] <andypugh> (Or just enable copy/paste from the pin list)
[00:05:51] <andypugh> (Guess who is messing about with raw mode?)
[00:18:32] <SWPadnos> NTU, in CVS (and maybe git) terminology, every branch has a HEAD, it just means "the most recent version of this branch"
[00:18:52] <SWPadnos> which is why we started calling the main development branch "TRUNK", as they also do
[00:24:17] <jepler> we'll never completely heal the scars CVS left us with..
[00:24:52] <NTU> yeah i dont like cvs, too bad RTAI uses it.
[00:25:05] <NTU> heh AT&T DSL in my area actually blocks cvs
[00:25:14] <NTU> I have to use Clear 4G WiMAX
[00:26:37] <SWPadnos> I'd drop any service provider that filtered something like that
[00:26:55] <SWPadnos> (on principle, not that I like CVS)
[00:31:12] <NTU> well you have two choices. pay 13,000 USD for comcast to drill cable in 1,000 feet, or spend a thousand bucks a month or so for T1?
[00:34:33] <NTU> comcast is literally across the street but they charge a rediculous amount to add cable to our side since the cable doesnt go through
[00:35:03] <SWPadnos> I'm in the same boat here, for DSL (got 2Mbit on this side of the street, could get 8 or 16 on the other side
[00:35:05] <SWPadnos> )
[00:37:08] <NTU> we "should" be getting 6 MBps download but it usually doesn't go over 4 megabits per second on a speed test
[01:15:20] <jepler> ooh I love me a good performance monitoring tool
http://mid.gmane.org/4CBC82BD.7050407@siemens.com
[01:20:04] <CIA-112> EMC: 03jepler 07master * r95de06ec5a45 10/src/hal/drivers/Submakefile: use correct python for building rbf firmware images
[01:20:05] <CIA-112> EMC: 03jepler 07master * r75ea5e76057b 10/tcl/bin/halshow.tcl: halshow: permit an unlimited number of levels
[01:20:06] <CIA-112> EMC: 03jepler 07master * rf814188d253c 10/src/ (Makefile modsilent modsilent.py): use correct python for modsilent
[01:27:07] <CIA-112> EMC: 03jepler 07master * r45873ceffe8c 10/src/configure.in: config: fix --as-needed vs sincos build problem
[01:27:30] <NTU> jepler thanks for pushing the patches!
[01:29:29] <andypugh> especially the halshow one.
[01:30:33] <jepler> NTU: thanks for helping me chase some of those issues
[01:31:34] <jepler> andypugh: I hope the halshow one helps you out, once you're at a spot where you can pull again
[01:31:38] <jepler> if it causes problems, let me know
[01:31:51] <NTU> no problem :) im glad you took the time fixing them, it means a lot
[01:33:21] <jepler> NTU: we aren't actively hostile to other distros .. we just look that way
[01:33:53] <NTU> well somebody in here is, forgot his nick though
[01:34:53] <jepler> unfortunately, many people who decide they prefer to use something besides ubuntu don't have the skill set to get the software built
[01:35:01] <jepler> it can be frustrating trying to help that individual
[01:35:23] <NTU> i rather not point fingers though but an argument went on in here about arch being a "not real linux distro"
[01:36:34] <NTU> btw i hope i wasnt that frusterating. i actually know what im doing but with EMC and RTAI its totally different thing which i am new too. but other things i am pretty good at
[01:37:49] <NTU> not to brag, just saying
[01:49:35] <jepler> who can resist a little linux distribution trash talking?
[01:49:36] <jepler> not me
[01:49:56] <cradek> me me
[02:05:34] <jepler> hm, something's broken
[02:05:35] <jepler> umount /media/Debian Debian\ Inst
[02:05:35] <jepler> umount: /media/Debian is not mounted (according to mtab)
[02:05:41] <jepler> er, wait, it's my commandline
[02:05:42] <jepler> * jepler hides
[02:06:05] <jepler> well, no, I'll go back to blaming the shell .. tab expansion is wrong for umount and drives with spaces(?)
[02:06:14] <jepler> bbl, trying to install debian testing..
[02:22:11] <jepler> hmph, my wireless chipset (intel)'s firmware is not on the installation image.. so I'll use a wire while installing, I guess
[02:47:55] <cradek> hm, arcs don't work very rightly at all
[02:48:05] <cradek> this is not working as well as I remember.
[02:48:23] <cradek> I ran eagle-generated gcode on it - I bet it didn't use any arcs.
[02:49:12] <jepler> probably not
[03:04:10] <cradek> whee, fixed arcs
[03:07:20] <jepler> whee, debian is on my laptop
[03:07:24] <CIA-112> EMC: 03cradek 07segmentqueue * r04b9be82e135 10/src/emc/kinematics/segmentqueue.c: fix acceleration along arcs
[03:09:28] <jepler> 'night all
[12:45:04] <skunkworks> cradek: Yay arcs :)
[12:59:23] <cradek> skunkworks: it still does silly things - my hopes aren't very high right now
[13:05:21] <skunkworks> aww.
[13:07:16] <SWPadnos> on a slightly related note, my mother recently re-read the Sonia paper, and she said that the description of the method doesn't match the equations
[13:07:20] <SWPadnos> or the other way around
[13:09:23] <cradek> to what extent? minor mistake?
[13:09:31] <skunkworks> this is probably a stupid question - what math does it use compared to the current planner?
[13:09:46] <cradek> fwiw, I had moderate luck implementing what that paper says
[13:10:01] <SWPadnos> no, something more like she describes a sine function and it's actually cosine
[13:10:15] <SWPadnos> I tend to glaze over when my mother starts talking about math :)
[13:10:21] <skunkworks> heh
[13:13:58] <skunkworks> gecko is getting back into motion....
http://cnczone.com/forums/cncbrain/72401-cncbrain_users-12.html
[13:14:13] <SWPadnos> yeah, a little PIC based thing
[13:14:15] <SWPadnos> IIRC
[13:23:45] <Jymmm> Ya think we cna talk Marris in switchng out the USB for an ethernet instead?
[13:25:30] <cradek> vaporware suppliers fight!
[13:27:06] <skunkworks> heh
[13:32:27] <Jymmm> So is the GM540 just offloading to ti's controller for motion?
[13:32:31] <Jymmm> it's
[13:37:37] <skunkworks> That is how I read it.
[13:38:13] <Jymmm> that be kinda cool. Sorta like how my laser works.
[13:38:41] <Jymmm> no dedicated computer required.
[13:38:52] <skunkworks> but not very flexable.
[13:39:24] <Jymmm> what's not flexible about cat xyz.gcode > /dev/blah ?
[13:41:30] <Jymmm> or are you talking feedback?
[13:41:41] <skunkworks> I am talking hardware wise. you are stuck with how you can hook things up and what they do
[13:42:35] <Jymmm> maybe it'll be both usb and paraport so you can use whichever you want.
[13:43:53] <skunkworks> I have been corupted by emc
[13:44:22] <skunkworks> what do you mean - I can't make this pin an input and hook my probe into it?
[13:45:33] <skunkworks> maybe I should say - I have been corrupted by emc and mesa hardware.
[13:50:48] <alex_joni> and LOTS of IO
[13:51:06] <alex_joni> Jymmm: try implementing a toolchanger like skunkworks did on such a thingie
[13:51:42] <skunkworks> Hi alex
[13:52:13] <jepler> "ti's controller"?
[13:53:09] <jepler> http://feeds.technologyreview.com/click.phdo?i=300b1e8c85e3d2a5dcc0c7687978b70f
[13:53:18] <jepler> "Physicists Discover Universal "Wet-Dog Shake" Rule
[13:53:19] <jepler> "
[13:53:44] <jepler> "[T]he universal rule for shaken fur is that the frequency increases with R^0.75." (where R is the radius of the dog)
[14:07:46] <SWPadnos> the description said RS485
[16:46:53] <CIA-112> EMC: 03cradek 07segmentqueue * rb64f0a0c1eba 10/src/emc/kinematics/segmentqueue.c: approximately fix accel violation on some arcs
[18:01:40] <skunkworks> SWPadnos: you are right :)
http://www.cnczone.com/forums/838545-post139.html
[18:17:52] <andypugh> tram_register_write wants a **. I have a single integer static value (sserial-do-your-thing) that I want to add to the tram list. Should I create a pointer and kmalloc it as a single int, or is there a way to double-& an ordinary int?
[18:19:18] <cradek> int a; int *pa; int **ppa; pa=&a; ppa=&pa;
[18:22:55] <jepler> you mean the arg 'buffer' to hm2_register_tram_write_region?
[18:22:55] <jepler> hostmot2.h:int hm2_register_tram_read_region(hostmot2_t *hm2, u16 addr, u16 size, u32 **buffer);
[18:23:13] <andypugh> Yes, the "buffer"
[18:23:50] <andypugh> I want it to write a value stored in an int to the addr.
[18:24:51] <andypugh> cradek: So, I either need to create an intermediate variable (which will go out of scope when the function exits) or initialise a pointer to an int with kmalloc?
[18:25:45] <andypugh> I have already found out what happens with u32 *ptr / *ptr = 0x1001 :-)
[18:26:00] <jepler> you want to do a read right now, once
[18:26:01] <jepler> ?
[18:26:09] <jepler> If so, I don't think hm2_register_tram_write_region is what you're looking for
[18:26:43] <andypugh> I want tram_write to write the magic code to the register every time it rns.
[18:27:12] <andypugh> ie at the end of every hm2_write
[18:27:29] <jepler> you mean, after the function where you want to call hm2_register_tram_write_region has ended?
[18:27:57] <jepler> if so, its local variables don't exist anymore, so pointers to them are no good (using them will crash, or overwrite some other memory)
[18:28:01] <andypugh> No, every servo thread
[18:28:59] <andypugh> Generally **buffer is a pointer to a kmalloc-ed array of values that need writing to the mesa card registers, vie the Translation ram.
[18:29:09] <andypugh> I want to add a value which is not an array.
[18:29:47] <andypugh> Though clearly, if necessary, it can be kmalloc-ed like a single-member array.
[18:30:01] <jepler> if you pass &somelocalvariable to hm2_register_tram_{read,write}_region, it'll blow chunks
[18:30:07] <jepler> obviously or unobviously, I'm not sure
[18:30:27] <andypugh> It's not a local variable, it lives inside an element of the hostmot2_t struct
[18:30:28] <jepler> if it's a single value then just use more *s to get it, instead of array notation []
[18:31:08] <andypugh> My problem is the inverse, pointing **buffer at my int.
[18:31:43] <andypugh> typcally you have a *ptr to your data-to-be-written, and pass it to tram_register as &ptr.
[18:31:56] <jepler> yes. you should follow that pattern.
[18:32:16] <jepler> but later when you want to talk about the (one) value, use *ptr instead of ptr[i]
[18:32:22] <andypugh> but if I have just some_data then &&some_data does not work (for fairly evident reasons)
[18:33:01] <andypugh> But i have to kmalloc it, yes?
[18:33:35] <andypugh> Otherwise it is an uninitialised pointer pointing to a random place in memory?
[18:34:17] <cradek> andypugh: you can point it to something, like I showed above
[18:34:36] <jepler> cradek: to satisfy the function's prototype, yes. to get a working program, no.
[18:34:53] <cradek> oh should I have read more? hmm.
[18:34:59] <andypugh> cradek: But your two-layer thing used an intermediate pointer. Is that not a problem if that goes out of scope when the function exits?
[18:35:02] <cradek> static int a?
[18:35:18] <cradek> listen to jepler, not me
[18:35:39] <jepler> for that thing that you pass into hm2_register_tram_read_region (or write) as the buffer argument, buffer has to point at valid memory until hal exits
[18:36:18] <jepler> so if you pass &some_local_variable to it, it's bad (because buffer will point to nothing when that function exits)
[18:36:22] <andypugh> So, kmalloc it is then? That was what I had concluded, but was worried that proper programmers would laugh at me.
[18:36:54] <skunkworks> I always worry about that.
[18:38:29] <andypugh> hm2->sserial.instance[i].command_reg_val = kmalloc(sizeof(u32), GPF_KERNEL); ?
[18:38:53] <andypugh> then *hm2->sserial.instance[i].command_reg_val = 0x1001;
[18:39:14] <andypugh> and ...tram_register_write.....&hm2->sserial.instance[i].command_reg_val
[18:39:58] <jepler> well, that's not going to work out either
[18:40:04] <andypugh> Oh
[18:41:01] <jepler> sserial_instance[i] is kmalloc'd
[18:41:06] <jepler> (I'm assuming)
[18:41:46] <jepler> when you call tram_register_write_region(..., &foo), the value of foo doesn't matter
[18:42:35] <jepler> later, in hm2_ajkllocate_tram_regions, foo gets modified to point within the translation ram buffers hm2->tram_(read|write)_buffer
[18:42:36] <andypugh> No, I have hal_mallocced sserial.instance[i].hal and kmallocced sserial.instance.[i].tram as two equal sized arrays.
[18:43:10] <jepler> so if you assign the result of kmalloc to command_reg_val and then call hm2_tram_register_write_region, then you'll just leak the pointer
[18:43:36] <andypugh> sserial.instance[i].command_reg_val has been left behind, so to speak, as there is only one of it.
[18:43:36] <jepler> and the 0x1001 value you assigned to the kmalloc'd region will have no relation to the value written during tram read
[18:43:55] <jepler> er, "written during tram write"
[18:44:43] <andypugh> Bear with me, I might be confusing matters horribly by using the wrong function names.
[18:45:17] <andypugh> (need to boot the PC)
[18:47:07] <jepler> r = hm2_register_tram_write_region(hm2, hm2->stepgen.step_rate_addr, (hm2->stepgen.num_instances * sizeof(u32)), &hm2->stepgen.step_rate_reg);
[18:47:09] <andypugh> Surely all I am doing in the bit of code I showed above is a single-element version of the method that is used for arrays? (In fact, in situations of only one stepgen, for example, it is exactly the same?)
[18:47:18] <jepler> here's a use of register_tram_write_region where there are a variable number of things
[18:47:21] <jepler> ^^
[18:47:42] <jepler> you want something that you write every cycle, but there's 1 instead of num_instances of them, correct?
[18:47:55] <andypugh> Yes
[18:48:02] <jepler> in that case, you'd just make the number of items be 1
[18:48:28] <andypugh> I think my elipsis earlier was confusing. the ... included the words "register" and "region"
[18:48:30] <jepler> r = hm2_register_tram_write_region(hm2, hm2->....my_single_register_addr, 1, &hm2->....my_single_register_reg);
[18:49:14] <andypugh> That was what I was meaning, yes.
[18:49:16] <jepler> now as for the prepare_tram_write code .. when there are num_instances of them, the use of it looks something like
[18:49:19] <jepler> hm2->stepgen.step_rate_reg[i] = steps_per_sec_cmd * (4294967296.0 / (double)hm2->stepgen.clock_frequency);
[18:49:39] <jepler> but in your case it'll be: (*hm2->...my_single_register_reg) = 0x1001;
[18:49:56] <andypugh> I just left out nearly all of the code as I couldn't remember the argument order
[18:50:13] <andypugh> Yes, that is exactly what I was proposing.
[18:51:10] <jepler> and there's no my_single_register_reg = kmalloc(...)
[18:51:27] <jepler> and even if the value is fixed, you can't assign it until the tram_write
[18:53:01] <andypugh> Huh?
[18:54:03] <jepler> if the value is constant (really always 0x1001) you can't do this until your tram_write function: (*hm2->...my_single_register_reg) = 0x1001;
[18:54:09] <andypugh> So, I can't kmalloc it, and I cant assign a value to it?
[18:55:13] <jepler> in your tram_write function (your equivalent of hm2_stepgen_prepare_tram_write) you can assign to it
[18:55:37] <jepler> but not in your equivalent of hm2_stepgen_parse_md
[18:55:38] <andypugh> Why there, and not in a bit of run-once setup code?
[18:56:42] <jepler> because it's not actually hm2_register_tram_write_region that makes my_single_register_reg point at appropriate memory
[18:56:44] <andypugh> (Rats! Charcoal for dinner)
[18:57:33] <jepler> it's later in the function called hm2_allocate_tram_regions which is called somewhere after all the xxx_parse_md functions and before hal threads can start
[18:58:36] <jepler> you could do it in hm2_force_write, the tram region is allocated by then
[18:58:56] <andypugh> Oh, the addresses of the items in the tram list get moved later?
[18:59:10] <andypugh> But don't drag their contents with them?
[18:59:35] <jepler> yes
[18:59:59] <jepler> actually, the assumption is that my_single_register_reg isn't initialized at all before the call to hm2_register_tram_write_region
[19:00:44] <andypugh> Really?
[19:01:14] <andypugh> When you say "initialised" do you mean "given a value" or "given an address in memory"?
[19:01:20] <jepler> I mean "given a value"
[19:02:06] <andypugh> OK, that I can live with. The other option would have left me with a lot of head--scratching as ...parse_md is full of kmallocs
[19:04:00] <andypugh> It is a little unfortunate that it is not always 0x1001, it changes depending on the layout and type of attached devices, it just never changes after setup.
[19:04:11] <jepler> hmmmm one correction
[19:04:35] <jepler> you'll want to call hm2_register_tram_write_region(hm2, hm2->...my_single_register_addr, sizeof(u32), &m2->...my_single_register_reg))
[19:04:43] <jepler> sizeof(u32) instead of the 1 I said earlier
[19:05:06] <andypugh> So I am going to have to use a placeholder in the structure to store the value, because "force_write" and "prepare_tram_write" don't know the magic number.
[19:07:19] <andypugh> (dinner Mk2 in the oven, if this one goes the same way it is Pizza tonight)
[19:07:53] <andypugh> Just a moment.
[19:10:56] <andypugh> Ah, it all makes a little more sense now.
[19:11:50] <andypugh> I have just noticed that in the competently-written modules, there is no kmalloc for the tram-registered variables.
[19:14:28] <andypugh> So my problem isn't entirely what I thought it was. Writing to the uninitialised pointer is wrong, but the solution is not to initialise it, as tram_register_regions does that. The solution is not to write to it until later. (which is what you said, I just didn't understand what you were saying when you said it)
[19:14:47] <jepler> yay
[19:14:56] <jepler> I am not the best explainer, that's for sure
[19:19:34] <andypugh> I think this also means that I need to delete my kmalloc of my hm2_8i20_tram structure
[19:19:59] <andypugh> Gah!
[19:20:10] <andypugh> That is not going to be an easy fix.
[19:20:43] <jepler> yuck, sorry to hear that
[19:21:44] <andypugh> I have an array of num_8i20 elements of sserial_tram_t called 8i20_tram[n] and the same for 7i43_tram[n]
[19:23:45] <andypugh> But I think that r = hm2_register_tram_write_region(hm2, addr, sizeof(u32), &hm2->sserial.instance[i].hm2_8i20_tram[n].reg_0_write)
[19:24:47] <andypugh> can't work
[19:25:51] <andypugh> Currently I malloc the 8i20_tram to be the right number of entries. But if tram_register wants unallocated pointers, and to move them around at will, that's a problem?
[19:27:21] <jepler> hm2_8i20_tram should point at allocated memory, otherwise the expression hm2->sserial.instance[i].hm2_8i20_tram[n].reg_0_write is referring to unallocated memory
[19:27:41] <jepler> ....reg_0_write = kmalloc(...) is the kmalloc you shouldn't do
[19:27:54] <jepler> ...hm2_8i20_tram = kmalloc(...) is a kmalloc I think you do need to do
[19:29:23] <andypugh> I do that malloc, but then doesn't that fix in memory the addesses of the elements of hm2_8i20_tram?
[19:30:48] <andypugh> I guess it is easy enoigh to try it and see what happens.
[19:30:49] <jepler> reg_0_write is a pointer. it's what reg_0_write points at that is getting set after you call to hm2_register_tram_write_region
[19:31:30] <andypugh> Ah, OK.
[19:32:15] <andypugh> I spent much of today reading articles in C pointers, and it still troubles me. Please tell me that the Hostmot2 driver is a particular baroque structure?
[19:34:49] <jepler> it's not uncomplicated.
[19:35:04] <jepler> it's also almost entirely undocumented..
[19:49:15] <andypugh> I have written something probably more complicated in structure in VBA (interfacing between Data in an excel table, two entirely different ECU programming applications and a Dyno and it was altogether rather easy in an OO / call-by-reference language.
[19:49:54] <andypugh> Just an object wrapper to make the two software interfaces look the same.
[19:50:27] <jepler> yeah, when you don't yet have experience built up it's very tough to follow languages with pointers and explicit memory management
[19:50:46] <jepler> and even worse when some parts of the API are trying to hide the memory management from you
[21:19:24] <CIA-112> EMC: 03cradek 07segmentqueue * r45cd93ca10ae 10/src/emc/ (4 files in 2 dirs): match APIs some more, and use the vel/acc from task
[21:43:14] <andypugh> The current input to the driver is -1 to 1. That scales between the firmware-programmed peak current and minus the same limit.
[21:44:14] <andypugh> I can't decide whether to leave it that way, to have a "scale" parameter, or to try to read the max current from the firmware and use that as the scale so that the hal-pin reads in engineering units.
[21:44:20] <andypugh> Any thoughts?
[21:50:10] <jepler> I'd go for the simplest one, and add one of the others later if it ended up looking useful
[21:54:03] <andypugh> -1 to 1 suits a PID input better, I suspect.
[21:54:15] <andypugh> And is already coded :-)
[22:19:34] <skunkworks> cradek: I am cheering you on... (I really don't know why but I like it when people work on the trajectory planner...)
[22:21:39] <andypugh> What is the segment queue about?
[22:25:51] <jepler> andypugh: it's a different trajectory planner which was an optional part of emc1
[22:26:13] <jepler> andypugh: it is claimed to have some good properties (jerk limiting, plans more than 2 segments at a time)
[22:26:25] <jepler> but it has limitations and bugs as well
[22:26:49] <jepler> for example, it's limited to 3 axes and does not support spindle-synch motion
[22:27:31] <andypugh> can it back-up to the previous section? (Something I have always thought would be useful for wire-edm, basically negative adaptive feed
[22:27:35] <jepler> I doubt it
[22:28:24] <jepler> but I don't know the internals .. I just know vaguely what it is supposed to promise
[22:30:00] <skunkworks> heh
[22:52:59] <andypugh> rtapi_math.h includes floor(), so why do I get a compiler warning any time I use it? (bldc_sine for example?)
[22:54:33] <jepler> "WARNING: ... undefined!" printed near the end of the build?
[23:27:13] <andypugh> Indeed
[23:27:20] <andypugh> Oh, and
http://www.youtube.com/watch?v=1LvdrHvGxJ8
[23:28:22] <cradek> cool! what feedback does that use?
[23:29:16] <andypugh> None at all at the moment :-)
[23:29:45] <andypugh> It is just roatating the field and hoping that the rotor follows
[23:29:56] <cradek> ah I see
[23:30:21] <andypugh> axis.0.motor-pos-cmd => hm2_5i23.0.sserial.0.port.0.8i20.angle
[23:31:05] <andypugh> I will set it up with a servo config tomorrow, probably. But that will need me to hook up my Arduino resolver-encoder converter.
[23:31:36] <cradek> oh this is the serial one - slick - I didn't get that at first
[23:32:58] <andypugh> I can't help thinking that the shape of this sserial drive is an awful lot like an SPI driver could look.
[23:33:16] <cradek> yep sure seems like
[23:42:47] <tom3p> andypugh, wedm needs to move backwards thru the path, but, sink edm needs to run to a safe place ( much simpler ) and hole edm just needs to go where it began ( also simple )
[23:44:18] <andypugh> I am talking about keeping the spark gap. As the work distorts you sometimes need to back away through the segment breaks..
[23:46:23] <tom3p> ah, lookup 'gap-control' ( emc is feed control )
[23:47:06] <tom3p> yes, an edm doesnt move towards its destination, it cha-cha's :)