I am struggling with one aspect of the coding style guide
80 character width does not go far when you have variables like:
does it make sense to create temporary variable to work with?
*tram = hm2->sserial.instance[i].hm2_conf_tram[n]
for example? That seems likely to be slower once compiled.
I suppose I could just use shorter variable names.
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
I would not assume that it would lead to worse code, either.
in fact, in this trivial code, gcc realizes that the two forms are equivalent: http://pastebin.ca/1981173
as it does in a slightly more complicated example where the unsimplified expression is ss->s[i].i1 = 1
in this case, when you deliberately reduce the level of optimization, the version with the local variable is fewer instructions. http://pastebin.ca/1981182
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
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
whoops, I forgot to set the git commiter info on my new virtual machine!
Author: jepler <firstname.lastname@example.org>
EMC: 03jepler 07master * rce8de3d45ed9 10/src/ (Makefile Makefile.modinc.in): build: tame the stack size warnings
EMC: 03jmelson 07master * r6258c17cc8f0 10/src/hal/drivers/hal_ppmc.c: add velocity estimation from encoder timestamp, currently only for new UPC
EMC: 03jmelson 07master * r68462e54b2ea 10/ (94 files in 47 dirs): Merge branch 'master' of ssh://email@example.com/git/emc2
what is correct way to implement fixed step jogging?
after i issue jog command i have to block somehow until it's finished
EMC: 03micges 07joints_axes3 * rc44fdf6d481f 10/ (236 files in 81 dirs): Merge branch 'master' into joints_axes3
jepler: pid with D works better here at 50m/min
old pid: http://imagebin.ca/view/8yb7StT.html
comparing pid.1.error and pid.0.error?
if so, that's an incredible difference
so it's a modest difference
it hears difference
You mean the sound of the machine is different? yes, that's what jon elson and I have also observed
yes thats it
thanks for testing and I'm glad the results were positive for you.
I'm hope that there will not be any other hostmot encoder velocity estimation bug :D
EMC: 03jepler 07master * r925174111aa3 10/src/rtapi/vsnprintf.h: support %zd, %zu in rtapi_vsnprintf
EMC: 03jepler 07master * r19641cca60b5 10/src/libnml/ (5 files in 3 dirs): fix printf-format warnings
EMC: 03jepler 07master * rf6571d423683 10/src/rtapi/ (rtai_ulapi.c rtapi_rtai_shm_wrap.h): silence warnings in rtapi_shm.h
EMC: 03jepler 07master * rb7bdc93f401a 10/.gitignore: ignore generated files
micges: are those two traces with the same tuning parameters, or did you re-tune (see if you could increase D) for the second?
bbl, time to drive to the office
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.
is it possible to add the tool diameter to the touch off window when you pick the tool table from the drop down list?
sure would save some time when changing tools
well, that's not really like diameter at all
er, maybe I don't understand what you mean
I mean add another text box for tool diameter
you mean you would give a diameter and it would write it in the tool table?
diameter and offset all at once
I think G10 L20 R... is not allowed
my Discovery 308 does it like that and it is hard to forget to edit the tool table that way
oh it is using G10 L10 to write the tool table?
the manual shows G10 L10 R X Z Q
you are right - it is allowed
hmm G10 uses radius but the tool table uses diameter...
at least the manual says so
anyway it made sense to me to have that after doing it on the mill yesterday when changing tools
bbl, gotta run to the other shop for a while
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-11-04.txt
some nebulous "improve (tool) touch off" is on my medium-length list of things to change about axis..
ries_ is now known as ries
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
if anyone interesed: video of my fast ja3 gantry machine: http://micges.wrzuta.pl/film/6YYFMP4tx4E/pb040188
pretty cool, is that first move to a sensor to see if the block actually got picked up?
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
it is only 52m/min
JT-Hardinge: first move is to some part of machine that soesn't exist yet
sensor is on handle
when I left work I could do 65m/min but with 5mm ferror
JT-Hardinge: if someone cares what has been fixed since 2.3.0, there's always the release notes
JT-Hardinge: ... but still using 2.3.0 is silly
2.3.0 fix problem with full circles with G64P-
seems to be the only entry
I looked through the archives and saw your reply to my local-variable question jepler.
andypugh: good, I'm glad you found it.
andypugh: btw did you look at what I recently committed with the message "rtai_rtapi: give more information when tasks fault"?
if you are still dealing with null-pointer type bugs, this may be helpful to you
I didn't look. I have been a bit distracted.
Perhaps I should do a pull/build and give it a workout :-)
I am also interested by the way that diff breaks strings over multiple lines. Does that work generally?
I assume you mean this:
+ "RTAPI: Task %d[%p]: Fault with vec=%d, signo=%d ip=%08lx.\n"
+ "RTAPI: This fault may not be recoverable without rebooting.\n",
+ self, task, vec, signo, regs->ip);
yes. In C, "abc" "def" and "abcdef" are equivalent. They're still equivalent if there's a blank line intervening.
That's remarkably handy to know.
I am slightly surprised that "abc" "def" isn't equivalent to "abc""def" though, which would be abc"def I think?
Or do you do quotes in strings another way?
"abc""def" is equivalent to "abcdef" too
[20:51:37] <jepler> http://en.wikipedia.org/wiki/C_syntax#String_literal_concatenation
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..
soon you'll be a grizzled C veteran
So, when my loops completed without finding anything to act on, the case: dropped through with two out-of-range indices....
yes, at that point you'll deliberately write a use of Duff's Device to bedevil a future newbie.
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
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).
I think I have read that
Basically a loop overflowing in such a way to change the actual opcode it was executing.
drum memory must have been crazy
Hmm, is the way round this with a cast to void? http://www.pastebin.ca/1982184
I'd use a temporary: buff = hal->pin.value; llio->write(..., &buff, sizeof(buff))
surely buff = *hal->pin.value?
So, really, I need &*hal->pin.value ?
(yes, I am being silly there)
The odd thing is that buff is a u32, as is *pin.value. So I am not clear what the problem is there?
Not that it matters.
you mean with the original code, or with buf = *hal->pin.value ?
It has to do with the loss of the "volatile" qualfier.
suppose you have the code 'x = *a; x = x + *a'
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
if it's not volatile, then it's free to choose to retrieve the value only once
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
Ah, so if *hal->pin.value was a conventional variable, there would be no problem?
yes. It's about "volatile", not about void* vs int*
That clarifies things rather.
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.
And, being volatile, odd things could happen if the value got changed during the execution of llio->write.
So the buffer seems like a wise move.
servo for our b axis. http://www.youtube.com/watch?v=I4YI7E-OgCQ
short and sweet
* Jymmm is neither.
skunkworks: youtube utterly fails to find similar videos on that one...
it is pretty new - have to give it a chance ;)