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