SWPadnos is now known as SWP_Away
SWP_Away is now known as SWPadnos
anything happening with linuxcnc.org on dreamhost?
hey alex, are you still alive?
or should I say "alex_joni"
but screen does't beep.. so it takes a while, for me to notice
heh - I'll try to remember that
got a question about the STG driver
screnn/irssi .. probably it could even get configured to do that
the DAC scaling looks strange to me. It appears to go backwards
it worked ok for me.. odd
dave-e noticed yesterday that higher numbers for dac_scale caused lower output values
* alex_joni looks
the sclaing line is this:
/* scale the voltage to be written based on offset and gain */
volts = (*(stg->dac_value[i]) - stg->dac_offset[i]) * stg->dac_gain[i];
/* compute the value for the DAC, the extra - in there is STG specific */
ncounts = (short) ((-10.0 - volts) / 20.0 * 0x1FFF);
lines, I guess
I'm assuming that the allowable range of inputs to that equation is +- 10
I don't see any clamping anywhere
that should probably be checked in the dac_write function
I think the chip doesn't output more than 10V
I think I checked that..
but the equation will give funny numbers if you go outside that range
that might be true :/
it'll probably wrap around
you're probably right, the stg_dac_write() should clamp
yep. I'd say that volts should be checked after the offset and scaling computations
I can make that change if you like (though I can't test it)
I'm in the same boat.. didn't boot the stg box in a while
don't have an stg to try ;)
what looks strange though is the fact that the slope is negative
ask for 10V, and you get -0x1FFF from those calcs
maybe there's an inverting amplifier involved?
* alex_joni looks for the docs he used
I'm downloading the MAX547 datasheet now
ok - the buffers are inverting inside the chip
/* input / output: */
/* lCounts (decimal) ... -lCounts ... +0x1000 ... volts */
/* 0x1000 (4096) 0xfffff000 0 +10 */
/*out 0 0 0x1000 0 */
/* 0xfffff001 (-4095) 0xfff 0x1fff -10 */
well - I just made a listtle test program for the DAC calculation, and it looks good to me. I can commit the (untested, uncompiled) clamping change if you like
ok, this will be to HEAD, I'll test before we move TESTING
hmmm - shouldn't that be the other way around? ;)
ie, HEAD is stable, and testing has stuff that might break?
SWPadnos: HEAD is where changes happen, so it's unlikely to be the most stable; I might agree TESTING is not the greatest name.
fwiw, since nobody has tried my new TP, I'm tempted to stick it on HEAD too.
heh - OK, maybe "stable" would be better, and it mimics debian a bit better
well it is.. if you take into account the STABLE tag too
SWPadnos: the RELEASE tag will be present too (just like debians STABLE)
ok. it's just counterintuitive (to me)
I think it's developer-orientated
HEAD = UNSTABLE, TESTING = TESTING, RELEASE = STABLE (emc vs debian)
cradek: go right ahead
no, HEAD != UNSTABLE
UNSTABLE = foo branch
HEAD = new & shiny ;)
then should I check into the TESTING branch?
it's a tag, not a branch ;)
so you cannot check into it .. :P
you need to check in to HEAD
hmmm, in that case, I'd say that HEAD *is* "UNSTABLE", since it may break at any time
since developers would check unproven changes in there
ok.. I give up :P
maybe I should have a second pot of coffee
starting from a small typo (wink) .. how about this:
what if for run-in-place we use the same 'sudo make install' command, but it does setuid instead?
are you serious?
it's like installing into the same dir..
I'm just pondering.. glad you disagree ;)
I think it's a bad idea
or feel strong about it..
ie, if --enable-run-in-place has been specified, then make install just does make setuid, since the's the install method for RIP
because it depends on how you configured in the past to do what you want (not wipe out your installed files).
that's, not the's
cradek: can you explain a bit more? (not seeing what you mean)
I do see that reasoning, but I think it's bad to use the same target to do two totally differently things, depending on how you ran some other command, possibly long ago
... where one possible outcome is to install over a bunch of files
"explicit is better than implicit"
well. guess I'm not too fond of 'setuid' ;)
be verbose: make install-in-place ;)
could people take a look at this "shorthand CML" page
[20:49:25] <SWPadnos> http://community.moertel.com/pxsl/
SWPadnos_ is now known as SWPadnos
hmm, arc-arc blending is not very good if the blends are long
due to low accel?
how's line-arc ?
I guess everything's fine
it's long arcs blended into long arcs at very low accel
ok, I convinced myself it's fine :-)
same direction of curvature, or does it matter?
heh - yep
like people unnecessarily write at circle quadrants
have you tried with S-curve shapes?
tried WHAT with s-curve shapes?
S looks excellent
[22:10:22] <cradek> http://timeguy.com/cradek-files/emc/s.png
hmmm - what are the spikes?
they are where the path changes from circle to parabola
and those are related to the second order ddt
ok. that's the "jerk" that les has talked about, I think
it's still accel
yeah, it's not jerk
isn't jerk a sharp change in accel?
but accel changes implies some jerk
jerk is what you get when accel changes instantaneously (like at the left of the bottom trace)
and at those spikes (also bottom trace), but neglectable
it jumps from 0 to 10 (constraint) in one period
ok - that's what I was talking about - the spikes (and the pulses)
I don't fully understand the spikes, but they don't bother me as long as they don't violate constraints (I think they don't) and we don't care about limiting jerk (we don't)
just thinking toward some changes that someone (other than you :) ) should think about in the future