Back
[00:20:36] <andypugh> I am struggling with one aspect of the coding style guide
[00:21:14] <andypugh> 80 character width does not go far when you have variables like:
[00:21:15] <andypugh> &hm2->sserial.instance[i].hm2_conf_tram[n].reg_cs_read
[00:38:45] <andypugh> does it make sense to create temporary variable to work with?
[00:38:45] <andypugh> *tram = hm2->sserial.instance[i].hm2_conf_tram[n]
[00:38:45] <andypugh> for example? That seems likely to be slower once compiled.
[00:38:57] <andypugh> I suppose I could just use shorter variable names.
[01:04:37] <jepler> I think assigning &hm2->sserial.instance[i].hm2_conf_tram[n] to a local is a very good idea, particularly if you refer to that expression repeatedly
[01:04:44] <jepler> I would not assume that it would lead to worse code, either.
[01:10:44] <jepler> in fact, in this trivial code, gcc realizes that the two forms are equivalent:
http://pastebin.ca/1981173
[01:12:30] <jepler> as it does in a slightly more complicated example where the unsimplified expression is ss->s[i].i1 = 1
[01:23:55] <jepler> in this case, when you deliberately reduce the level of optimization, the version with the local variable is fewer instructions.
http://pastebin.ca/1981182
[01:24:42] <jepler> the instruction in f1 at address 0x1a has no corresponding instruction in f2. in f1, that is the instruction that corresponds to the second dereferencing of ss
[01:25:46] <jepler> because of the way the optimizer has scheduled the code, this actually introduces the need for an extra temporary register (%esi), so there's an extra push and pop too
[01:50:47] <jepler> whoops, I forgot to set the git commiter info on my new virtual machine!
[01:50:48] <jepler> commit 34074e07faddf6e8aa9cb9bc7d6e2d8defa1ca7e
[01:50:48] <jepler> Author: jepler <jepler@ubuntu-lucid-virtual-i386.unpy.net>
[01:50:52] <jepler> how embarassing
[01:53:43] <CIA-2> EMC: 03jepler 07master * rce8de3d45ed9 10/src/ (Makefile Makefile.modinc.in): build: tame the stack size warnings
[05:36:36] <CIA-2> EMC: 03jmelson 07master * r6258c17cc8f0 10/src/hal/drivers/hal_ppmc.c: add velocity estimation from encoder timestamp, currently only for new UPC
[05:36:48] <CIA-2> EMC: 03jmelson 07master * r68462e54b2ea 10/ (94 files in 47 dirs): Merge branch 'master' of ssh://jmelson@git.linuxcnc.org/git/emc2
[11:21:19] <psha> what is correct way to implement fixed step jogging?
[11:21:46] <psha> after i issue jog command i have to block somehow until it's finished
[11:46:15] <CIA-2> EMC: 03micges 07joints_axes3 * rc44fdf6d481f 10/ (236 files in 81 dirs): Merge branch 'master' into joints_axes3
[11:55:38] <alex_joni> micges: yay
[12:25:23] <micges> jepler: pid with D works better here at 50m/min
[12:29:26] <micges> old pid:
http://imagebin.ca/view/8yb7StT.html
[12:29:58] <micges> new:
http://imagebin.ca/view/7nMRIE.html
[12:51:34] <jepler> comparing pid.1.error and pid.0.error?
[12:51:39] <jepler> if so, that's an incredible difference
[12:51:51] <micges> pid.2
[12:52:10] <jepler> oh. :/
[12:52:22] <jepler> so it's a modest difference
[12:52:45] <micges> it hears difference
[12:53:15] <jepler> You mean the sound of the machine is different? yes, that's what jon elson and I have also observed
[12:53:32] <micges> yes thats it
[12:54:16] <jepler> thanks for testing and I'm glad the results were positive for you.
[12:55:49] <micges> I'm hope that there will not be any other hostmot encoder velocity estimation bug :D
[12:56:11] <jepler> indeed
[12:57:29] <CIA-2> EMC: 03jepler 07master * r925174111aa3 10/src/rtapi/vsnprintf.h: support %zd, %zu in rtapi_vsnprintf
[12:57:30] <CIA-2> EMC: 03jepler 07master * r19641cca60b5 10/src/libnml/ (5 files in 3 dirs): fix printf-format warnings
[12:57:32] <CIA-2> EMC: 03jepler 07master * rf6571d423683 10/src/rtapi/ (rtai_ulapi.c rtapi_rtai_shm_wrap.h): silence warnings in rtapi_shm.h
[12:57:33] <CIA-2> EMC: 03jepler 07master * rb7bdc93f401a 10/.gitignore: ignore generated files
[12:57:58] <jepler> micges: are those two traces with the same tuning parameters, or did you re-tune (see if you could increase D) for the second?
[12:58:02] <jepler> bbl, time to drive to the office
[13:00:04] <micges> same parameters
[13:09:50] <cradek> micges: I have been using hostmot2 velocity as a fake tach signal for a velocity mode servo amp. I have not seen/heard any problems. I have had it that way for a few months.
[13:11:38] <JT-Hardinge> is it possible to add the tool diameter to the touch off window when you pick the tool table from the drop down list?
[13:12:05] <JT-Hardinge> sure would save some time when changing tools
[13:12:07] <cradek> well, that's not really like diameter at all
[13:12:13] <micges> cradek: cool
[13:12:25] <cradek> er, maybe I don't understand what you mean
[13:12:36] <JT-Hardinge> I mean add another text box for tool diameter
[13:13:00] <cradek> you mean you would give a diameter and it would write it in the tool table?
[13:13:09] <JT-Hardinge> yes
[13:13:21] <JT-Hardinge> diameter and offset all at once
[13:14:04] <cradek> I think G10 L20 R... is not allowed
[13:14:05] <JT-Hardinge> my Discovery 308 does it like that and it is hard to forget to edit the tool table that way
[13:14:10] <cradek> er L10
[13:14:43] <JT-Hardinge> oh it is using G10 L10 to write the tool table?
[13:14:50] <cradek> yes
[13:15:28] <JT-Hardinge> the manual shows G10 L10 R X Z Q
[13:16:31] <cradek> you are right - it is allowed
[13:16:51] <JT-Hardinge> hmm G10 uses radius but the tool table uses diameter...
[13:16:59] <cradek> yep
[13:17:00] <JT-Hardinge> at least the manual says so
[13:18:19] <JT-Hardinge> anyway it made sense to me to have that after doing it on the mill yesterday when changing tools
[13:19:10] <JT-Hardinge> bbl, gotta run to the other shop for a while
[13:27:01] <skunkworks> logger_dev: bookmark
[13:27:01] <skunkworks> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-11-04.txt
[16:08:32] <jepler> some nebulous "improve (tool) touch off" is on my medium-length list of things to change about axis..
[18:13:36] <ries_> ries_ is now known as ries
[18:42:30] <JT-Hardinge> I just had a thought on the way back that it might be better to have a tool table button and work offset button where the tool table touch off would give you the ability to set all the parameters in the tool table
[19:06:17] <micges> if anyone interesed: video of my fast ja3 gantry machine:
http://micges.wrzuta.pl/film/6YYFMP4tx4E/pb040188
[19:09:07] <JT-Hardinge> pretty cool, is that first move to a sensor to see if the block actually got picked up?
[19:11:11] <cradek> micges: neat!
[19:15:28] <skunkworks> micges: neat!
[19:16:19] <JT-Hardinge> was there any issues with G64 Pn.n not working well in 2.3?
[19:16:25] <JT-Hardinge> http://www.linuxcnc.org/component/option,com_kunena/Itemid,20/func,view/catid,38/id,2476/limit,6/limitstart,6/lang,english/#5081
[19:16:36] <micges> it is only 52m/min
[19:17:09] <micges> JT-Hardinge: first move is to some part of machine that soesn't exist yet
[19:17:19] <micges> sensor is on handle
[19:17:45] <micges> when I left work I could do 65m/min but with 5mm ferror
[19:17:46] <cradek> JT-Hardinge: if someone cares what has been fixed since 2.3.0, there's always the release notes
[19:18:06] <cradek> JT-Hardinge: ... but still using 2.3.0 is silly
[19:20:32] <JT-Hardinge> yep
[19:22:39] <JT-Hardinge> 2.3.0 fix problem with full circles with G64P-
[19:23:00] <JT-Hardinge> seems to be the only entry
[20:39:39] <andypugh> I looked through the archives and saw your reply to my local-variable question jepler.
[20:41:01] <jepler> andypugh: good, I'm glad you found it.
[20:41:25] <jepler> andypugh: btw did you look at what I recently committed with the message "rtai_rtapi: give more information when tasks fault"?
[20:41:39] <jepler> if you are still dealing with null-pointer type bugs, this may be helpful to you
[20:42:29] <andypugh> I didn't look. I have been a bit distracted.
[20:44:57] <andypugh> Perhaps I should do a pull/build and give it a workout :-)
[20:45:42] <andypugh> I am also interested by the way that diff breaks strings over multiple lines. Does that work generally?
[20:47:25] <jepler> I assume you mean this:
[20:47:25] <jepler> + rtapi_print_msg(RTAPI_MSG_ERR,
[20:47:25] <jepler> + "RTAPI: Task %d[%p]: Fault with vec=%d, signo=%d ip=%08lx.\n"
[20:47:25] <jepler> + "RTAPI: This fault may not be recoverable without rebooting.\n",
[20:47:25] <jepler> + self, task, vec, signo, regs->ip);
[20:47:54] <jepler> yes. In C, "abc" "def" and "abcdef" are equivalent. They're still equivalent if there's a blank line intervening.
[20:48:15] <andypugh> That's remarkably handy to know.
[20:49:23] <andypugh> I am slightly surprised that "abc" "def" isn't equivalent to "abc""def" though, which would be abc"def I think?
[20:49:46] <andypugh> Or do you do quotes in strings another way?
[20:49:49] <cradek> \"
[20:49:53] <jepler> "abc\"def"
[20:51:11] <jepler> "abc""def" is equivalent to "abcdef" too
[20:51:37] <jepler> http://en.wikipedia.org/wiki/C_syntax#String_literal_concatenation
[20:51:47] <andypugh> I do keep getting caught out. I spent a whole (long) evening staring at a Switch statement wondering why it was causing a null pointer error. Eventually (after lots of diagnostif HM2_DBG messages) I found that C case: statements fall through, whereas I am used to the next case: terminating the previous one..
[20:52:15] <cradek> soon you'll be a grizzled C veteran
[20:52:54] <andypugh> So, when my loops completed without finding anything to act on, the case: dropped through with two out-of-range indices....
[20:53:38] <jepler> yes, at that point you'll deliberately write a use of Duff's Device to bedevil a future newbie.
[20:53:40] <andypugh> When you _know_ that is how it works, it is rather useful, but when you don't...
[20:53:45] <jepler> http://en.wikipedia.org/wiki/Duff%27s_device
[20:57:28] <andypugh> Eek!
[20:59:03] <andypugh> Reminds me of the trick used in the "Story of Mel" (Which I think I have linked to before, a rather curious hack on a drum-memory computer).
[20:59:19] <jepler> I think I have read that
[20:59:56] <andypugh> Basically a loop overflowing in such a way to change the actual opcode it was executing.
[21:21:37] <jepler> drum memory must have been crazy
[21:22:17] <andypugh> Hmm, is the way round this with a cast to void?
http://www.pastebin.ca/1982184
[21:24:06] <jepler> I'd use a temporary: buff = hal->pin.value; llio->write(..., &buff, sizeof(buff))
[21:24:59] <andypugh> surely buff = *hal->pin.value?
[21:25:04] <jepler> errrrrr right
[21:25:09] <jepler> durr
[21:25:38] <andypugh> So, really, I need &*hal->pin.value ?
[21:25:48] <andypugh> (yes, I am being silly there)
[21:29:11] <andypugh> The odd thing is that buff is a u32, as is *pin.value. So I am not clear what the problem is there?
[21:30:17] <andypugh> Not that it matters.
[21:30:17] <jepler> you mean with the original code, or with buf = *hal->pin.value ?
[21:30:29] <andypugh> Original code.
[21:30:37] <jepler> It has to do with the loss of the "volatile" qualfier.
[21:30:58] <jepler> suppose you have the code 'x = *a; x = x + *a'
[21:31:38] <jepler> if a points at a volatile value, then the compiler has to retrieve the value stored at that memory location twice, once each time the expression *a is being evaluated
[21:32:00] <jepler> if it's not volatile, then it's free to choose to retrieve the value only once
[21:32:34] <jepler> if you pass the volatile unsigned int * to a function that expects a non-volatile pointer, that function may not retrieve the value the number of times you expect
[21:32:40] <andypugh> Ah, so if *hal->pin.value was a conventional variable, there would be no problem?
[21:32:51] <jepler> yes. It's about "volatile", not about void* vs int*
[21:33:08] <andypugh> That clarifies things rather.
[21:34:06] <andypugh> What was puzzling me was that I thought (void *) meant "I don't care, pass me the address to anything", not paying attention to the volatile part.
[21:34:44] <andypugh> And, being volatile, odd things could happen if the value got changed during the execution of llio->write.
[21:35:04] <andypugh> So the buffer seems like a wise move.
[21:35:33] <jepler> yes.
[21:44:31] <skunkworks> servo for our b axis.
http://www.youtube.com/watch?v=I4YI7E-OgCQ
[21:46:50] <jepler> short and sweet
[21:47:46] <Jymmm> * Jymmm is neither.
[22:31:04] <cradek> skunkworks: neat
[22:31:23] <cradek> skunkworks: youtube utterly fails to find similar videos on that one...
[22:31:34] <skunkworks> heh
[22:34:30] <skunkworks> it is pretty new - have to give it a chance ;)