Back
[00:43:58] <jmkasunich> I hate battery operated stuff
[00:44:23] <jmkasunich> * jmkasunich searches for a couple of AAs that aren't dead
[00:49:19] <jmkasunich> charge charge charge
[00:50:07] <cradek> hi jmk
[00:50:22] <jmkasunich> hi
[00:50:47] <jmkasunich> beautiful very thin crescent moon, with the dark face illuminated by earthshine
[00:50:58] <jmkasunich> and the damned digicam won't work
[00:51:13] <cradek> it's not quite dark yet here
[00:51:28] <cradek> photos of the moon don't work anyway...
[00:51:31] <jmkasunich> it was still twilight here when I saw it
[00:51:47] <jmkasunich> would have been at least as nice a pic then
[00:51:50] <jmkasunich> why not?
[00:52:06] <cradek> the moon is too tiny
[00:52:08] <jepler> speaking of which did you see APOD?
http://antwrp.gsfc.nasa.gov/apod/ap070320.html
[00:52:24] <jmkasunich> not thru a 60mm 18x spotting scope ;-)
[00:52:33] <cradek> heh ok
[00:52:37] <cradek> jepler: that's very cool
[00:52:43] <jmkasunich> purty
[00:53:18] <jmkasunich> this is when I wish I had a dslr, or at least a high end digicam with a manual mode
[00:53:44] <jmkasunich> the point-n-shit that I have would probably not do well even if it did have charged batteries
[01:39:18] <jepler> I can't figure out why 'if(c) x <= x + y;' is taking so many logic blocks
[01:39:42] <jmkasunich> how wide are x and y?
[01:40:08] <jepler> x is 32 bits, y is 20 bits sign-extended (which I probably did in some wrong way)
[01:40:27] <jepler> I kinda think it's implementing it as x <= c ? x : x + y, which uses one set of LUTs for + and one for ?:
[01:40:50] <jepler> as opposed to using c as a ff load enable
[01:41:28] <jepler> because it's using about 32 + 32 + 20 LEs
[01:42:11] <jepler> (including the register for 'y')
[01:42:36] <SWPadnos> have you tried explicitly defining the !c case?
[01:42:52] <SWPadnos> by putting an "else x <= x" after that previous line
[01:42:56] <jepler> no, I haven't
[01:43:12] <SWPadnos> not that it should help, but it might
[01:43:46] <jmkasunich> the add is going to be 32 luts (minimum), and the y register is going to be 20ffs
[01:44:01] <jmkasunich> the x register will be 32 ffs, but they should be in the same clbs as the luts
[01:44:06] <jepler> if it's really doing x <= c ? x : x + y, then it will do a bit better if I write it as x <= x + (c ? y : 0) ..
[01:44:14] <jmkasunich> so the question is where are the other 32 luts going
[01:44:21] <SWPadnos> shouldn't that be 16 LUTs, since they each have 4 inputs + carry? (or 3 + carry)
[01:44:27] <jepler> jmkasunich: 32 to +, 32 to ?:
[01:44:33] <jepler> (my guess)
[01:45:22] <jmkasunich> each lut is 3 in, plus carry, and 2 out (sum and carry), right?
[01:45:41] <jmkasunich> so the 3 in are x, y, and c
[01:45:54] <jmkasunich> it ought to be able to do it with one lut per but
[01:46:16] <SWPadnos> ok - that would be 32 LUTs total, I can see that
[01:46:48] <jepler> jmkasunich: yes I think that accurately describes the arithmetic configuration
[01:48:02] <jepler> er no
[01:48:18] <jmkasunich> why not?
[01:48:20] <jepler> * jepler goes to look at the pictures again
[01:49:49] <jmkasunich> speaking of pictures:
http://jmkasunich.dyndns.org/pics/crescent_moon.jpg
[01:51:35] <jepler> the 3 inputs are carry, in1, and in2
[01:52:16] <jmkasunich> 3 including carry, not 3 plus carry
[01:52:40] <jmkasunich> what was that URL again? (the datasheet we were looking at last night)
[01:52:58] <jepler> http://emergent.unpy.net/files/papers/acex.pdf
[01:53:52] <jmkasunich> ok, in math mode the clock enable isn't usable
[01:54:55] <jmkasunich> looks like you have no choice but to have a mux upstream of the adder
[01:55:18] <jmkasunich> you should do the mux before the sign extend tho, so its only 20 bits wide, not 32
[01:55:27] <jepler> yes that's what I was saying
[01:56:08] <jmkasunich> since the mux is selecting between some value and zero, its only a two input function, not three
[01:56:22] <jmkasunich> not sure that matters much tho
[01:59:45] <jmkasunich> dang, you can't decouple the FF from the LUT
[02:00:09] <jmkasunich> it would be nice if you could use 20 FFs for the rate register, and the corresponding LUTs for the mux
[02:00:20] <jmkasunich> oh, you can
[02:00:39] <jmkasunich> in normal mode, data4 can be the input to the FF, and a NC in the LUT
[02:01:05] <jmkasunich> data 1 and data2 can be y[n] and c
[02:01:07] <jepler> well it's not figuring that out from what I've written
[02:01:26] <jepler> I haven't even gotten my 12 LEs back yet by moving the mux to before the sign extend
[02:01:37] <jmkasunich> how are you doing the sign extend?
[02:01:55] <jepler> wire [q-1:0] holdvelocity = hold ? {r{1'd0}} : velocity;
[02:01:56] <jepler> wire [r-1:0] signvelocity = {r{holdvelocity[q-1]}};
[02:01:56] <jepler> wire [q+r-1:0] addvelocity = {signvelocity, holdvelocity};
[02:02:31] <jepler> {r{v}} reproduces "v" r times
[02:02:40] <jmkasunich> heh, it would help if I could read verilog
[02:02:42] <jepler> {a,b} is concatenation
[02:02:53] <jmkasunich> I'm just learning to vhdl... no clue about veri
[02:02:59] <jepler> same here but in reverse
[02:03:14] <jmkasunich> what are q and r? the widths?
[02:03:20] <jepler> yes
[02:03:32] <jepler> oh yeah, [a:b] gives the bit width of things
[02:03:33] <jmkasunich> what is hold?
[02:03:44] <jepler> hold is what I've been calling 'c'
[02:03:57] <jepler> if(!hold) position <= position + velocity;
[02:04:04] <jmkasunich> ok
[02:04:33] <jmkasunich> what are you calling the 20 bit velocity register?
[02:04:35] <jepler> except now position <= position + addvelocity; unconditionally
[02:04:41] <jepler> reg [q-1:0] velocity;
[02:04:45] <jepler> always @(posedge clk)
[02:04:45] <jepler> if(load) velocity <= ivelocity;
[02:05:31] <jepler> (which is what uses up the LUTs next to velocity, I suppose)
[02:06:19] <jmkasunich> yeah
[02:06:31] <jmkasunich> dang, not having a dedicated clock enable sucks
[02:07:05] <jepler> instead of trying to micro-optimize this I should go figure out RAM instead
[02:07:18] <jmkasunich> yeah
[02:07:48] <jmkasunich> you're not gonna get below 32 (adder) + 20 (mux if you can tweak it) + 20 (register)
[02:21:36] <jmkasunich> cradek: you around?
[02:22:56] <cradek> yes
[02:23:32] <jmkasunich> what are the max velocity and accel specs for max?
[02:23:52] <cradek> they're in the max sample config
[02:23:58] <jmkasunich> duh
[02:24:04] <cradek> accel is 20-30, I forget what vel is, maybe .566
[02:24:33] <jmkasunich> Stuard isn't providing his numbers, I want to run thru the math and see what the implications of limiting the wheel overrun are
[02:24:46] <jmkasunich> (as opposed to aborting the move based on a timeout)
[02:24:59] <jmkasunich> wanted to use some realistic numbers
[02:25:26] <cradek> a sherline doesn't go nearly that fast - maybe 20ipm
[12:17:32] <cradek_> cradek_ is now known as cradek
[13:14:14] <SWPadnos> jepler, cool addition (especially for folks like me who will use touchscreens)
[13:14:32] <SWPadnos> one question though: does shift still toggle between the modes?
[13:14:50] <SWPadnos> (ie, if in rotate mode, will shift translate instead?)
[13:15:16] <jepler> SWPadnos: yes
[13:15:24] <SWPadnos> excellent! thanks
[16:33:06] <cradek> it's a trap!
[16:35:35] <SWPadnos> heh
[18:03:04] <jepler> if g43 with no h-number is now forbidden, can we change our interpreter so that if there is no h-number, the last t-number is used instead?
[18:03:20] <jepler> without breaking correct progams
[18:03:22] <jepler> programs
[18:04:57] <cradek> not the last T number, the loaded tool
[18:05:00] <cradek> and yes I think we could
[18:05:09] <cradek> that parallels how radius comp works
[18:05:22] <jepler> does that mean you think we should?
[18:06:48] <cradek> wonder what happens when you change tools
[18:06:57] <cradek> (heck I wonder now)
[18:07:44] <jepler> with g43 active, you mean?
[18:07:49] <cradek> yes
[18:12:43] <cradek> M6 semi-explicitly does NOT change the length offset
[18:15:11] <cradek> and I confirm that's the behavior
[18:16:19] <cradek> so this change seems a little bit problematic
[18:16:37] <cradek> ngc's g43 + ngc's m6 = crazy, I think
[18:17:01] <cradek> not sure how to make it more sane without breaking programs
[18:18:32] <cradek> in my ideal world, g43 could be left on, and it would use the loaded tool's length, and if you m6, the tooltip ends up in the same place after the change
[18:19:05] <cradek> the defined behavior (axes go to the same position) seems bogus to me
[18:19:43] <cradek> * cradek rambles to himself
[18:20:15] <jepler> or it should say "it is an error if .. tool length offset is in effect" for m6
[18:20:27] <jepler> (does it even say it's an error if tool shape comp is in effect?!)
[18:21:42] <cradek> no, you can apparently change tools with comp on (I just tried it)
[18:22:14] <jepler> oh golly
[18:22:34] <cradek> yeah, that seems bad too
[18:25:48] <cradek> fwiw my preference would be to break with the spec here
[20:04:53] <cradek> jepler: more people than you think appear to be using i2g
[20:05:35] <jepler> cradek: I guess so!
[20:06:03] <cradek> maybe we should release before the weekend...
[20:45:50] <anonimasu> cradek: that's how the control on my big mill does it..
[20:46:04] <anonimasu> it compensates for tool length when you do a toolchange so the tip ends up in the same place..
[20:47:19] <cradek> anonimasu: that seems sane
[20:47:36] <cradek> if you change tools at the top of travel though, and go to a longer tool, that's a problem
[20:48:33] <anonimasu> yeah, though I have no idea how it does it..
[20:48:44] <anonimasu> :)
[20:48:58] <anonimasu> I dont have a ATC yet, but it does the length as soon as you change tool..
[20:49:17] <anonimasu> I guess that's a special case the nc program should handle..
[20:49:25] <anonimasu> (ngc)
[20:50:09] <anonimasu> :)
[20:54:43] <cradek> a foolproof scheme would be to make the user turn off length and radius comp before changing tools
[20:55:28] <cradek> ngc does nt require that - and I think allowing changing tools with radius comp on has got to be a bug
[20:55:33] <cradek> not
[20:55:46] <alex_joni> did you guys ever hear about G68 3D coordinate rotation ?
[20:56:04] <anonimasu> yes
[20:56:04] <cradek> nope but I can picture it already
[20:56:24] <alex_joni> I think that's something nice ;)
[20:56:31] <anonimasu> yeah..
[20:56:38] <anonimasu> there's a cool video from centroid showing it in action..
[20:56:49] <anonimasu> machining a plate / / on the table..
[20:57:17] <cradek> I can't think of any reason that's particularly hard to do
[20:57:51] <cradek> the devil is in the details I'm sure
[20:58:02] <anonimasu> hehe
[20:58:08] <alex_joni> cradek: this would be at CANON level?
[21:02:27] <cradek> alex_joni: I haven't thought it through
[21:22:51] <lerman_> lerman_ is now known as lerman
[22:10:51] <roltek> hi cradek you there
[22:13:48] <roltek> does emc have g or m code return to home
[22:17:29] <jepler> g28
[22:18:35] <roltek> when you are doing a tool change and you call return to home comp and tool length automaticlly turn off
[22:23:46] <jepler> I do not know. Read the documentation or do some experimentation.
[22:25:59] <roltek> i am trying to inform you on how a tool change works
