Back
[00:06:05] <skunkworks> smelly cat - smelly cat. what are they feeding you...
[00:13:27] <jepler> LawrenceG: any luck
[00:13:27] <jepler> ?
[00:16:03] <cradek> jepler:
[00:16:03] <cradek> File "/home/chris/emc2.trunk/bin/emctop", line 107, in timer
[00:16:05] <cradek> if button_pressed:
[00:16:05] <cradek> NameError: global name 'button_pressed' is not defined
[00:16:22] <jepler> argh
[00:16:27] <jepler> at least I didn't backport that right away
[00:18:26] <jepler> "Oh I'll do one last bit of clean-up before I commit this; it's code I commented out because I didn't need it"
[00:21:07] <jmkasunich> back
[00:21:26] <cradek> jepler: much better
[00:21:30] <jepler> cradek: oh good
[00:21:40] <jepler> cradek: thanks for trying it out
[00:24:03] <jmkasunich> never thought there would be so many opinions about a jogwheel
[00:30:04] <cradek> jogwheel works perfectly
[00:30:33] <cradek> hey look, an appropriate error message
[00:31:00] <cradek> but only one way (no error when I turn the jogwheel while keyboard jogging)
[00:36:56] <jepler> interesting -- cia formats my changelogs into bullet lists.
http://cia.navi.cx/stats/project/emc/.message/3f47c0
[01:08:27] <LawrenceG> jepler: thanks... have several new/modified comps built and working... very cool and very easy to add parts to hal without rebuilding the whole system
[01:09:03] <jepler> LawrenceG: glad to hear it
[01:09:38] <jepler> beware that if you modify a comp but don't give it a new name, it'll be overwritten when the next bugfix upgrade comes out
[01:10:22] <LawrenceG> I added an integer output to scale.comp.... it now outputs both a float and an integer presentation
[01:11:13] <LawrenceG> I feed that to a non fp comp that is driving a triac gate for spindle speed control
[01:12:16] <jepler> is the spindle working at all well yet?
[01:12:33] <LawrenceG> no problem... if I get it working the way I want I will try and check it in via one of the developers
[01:12:39] <jmkasunich> cradek: regarding that error message
[01:12:55] <jepler> LawrenceG: you might be able to use the regular 'scale' plus conv_float_s32 (or _u32) to convert the float to an integer
[01:13:02] <jmkasunich> the jog command error is issued while processing the jog command (like other errors that accompany commands)
[01:13:15] <jmkasunich> the wheel isn't a command as such
[01:13:33] <jmkasunich> and I don't want to issue hundreds of error messages
[01:13:36] <LawrenceG> not yet...the ssr relay I am using doesnt track the drive signal very well
[01:14:20] <LawrenceG> I may look at a bridge rectifier/fet combination instead
[01:15:16] <LawrenceG> at least they turn off when told!
[01:16:11] <jmkasunich> cradek: actually, I'm not sure that should be an error (as in setting the error flag), maybe should just silently discard the jog command
[01:22:21] <cradek> error messages should be used when the user needs to correct something, and not as a smack on the knuckles just because he messes up
[01:22:38] <cradek> I think, but I'm not entirely sure, that this is the second case, in which case it shouldn't error
[01:23:54] <cradek> I'm thinking of something like trying to scroll down past the bottom of a document. An editor should stop scrolling, or beep, or something inocuous - it should NOT interrupt the user and say "You tried to scroll past the bottom of the document" [OK]
[01:26:14] <jmkasunich> yeah
[01:26:21] <jepler> I agree
[01:26:46] <cradek> you agree about error messages, or about this case?
[01:26:50] <jepler> about this case
[01:26:51] <jmkasunich> there are several tests in a row (already there) which printed things
[01:26:56] <jmkasunich> and I just tacked this one on the end
[01:27:12] <jmkasunich> I put a fixme in there expressing my doubts about it really needing a message
[01:28:16] <jmkasunich> http://pastebin.ca/402881
[01:28:31] <jmkasunich> I would probably argue that several of those messages shouldn't be errors
[01:28:58] <cradek> I think they would represent gui bugs though?
[01:29:07] <cradek> (I've never seen them)
[01:29:22] <jmkasunich> you mean the first two?
[01:29:52] <jepler> or race conditions between multiple GUIs
[01:29:59] <jmkasunich> I suspect getting a command that trips those tests means something somewhere has a bug
[01:30:00] <jepler> AXIS tries to test as many preconditions as it can to avoid these messages
[01:30:01] <jmkasunich> (or a race)
[01:30:24] <jepler> the arrow key is just nonresponsive when ESTOP is on..
[01:30:30] <jmkasunich> what I'm wondering about now is the SET_JOINT_ERROR_FLAG
[01:30:42] <jmkasunich> I have no clue what that does (I mean beyond setting a flag)
[01:31:03] <jmkasunich> does that require some action to clear the flag?
[01:31:07] <cradek> funny, I feel the same way
[01:31:12] <jmkasunich> no clue - thats some inherited EMC1 stuff
[01:31:31] <jepler> ./motion/motion.c:SET_JOINT_FERROR_FLAG(joint, 0);
[01:31:34] <jepler> something resets it
[01:31:54] <jmkasunich> from my drives background, when a drive throws an error (we call them faults), user intervention is required to restart
[01:32:24] <jepler> some places it's used to avoid printing too many errors
[01:32:26] <jepler> if (!GET_JOINT_ERROR_FLAG(joint)) {
[01:32:26] <jepler> /* report the error just this once */
[01:32:26] <jepler> reportError("joint %d following error", joint_num);
[01:32:26] <jepler> }
[01:32:28] <jepler> SET_JOINT_ERROR_FLAG(joint, 1);
[01:32:57] <jmkasunich> I'm seriously tempted to treat the homing test and the wheel jog test like the limits test at the end of the pastebin snippet
[01:33:14] <jmkasunich> duh, even that one sets the error flag
[01:33:42] <jepler> ./motion/control.c:axis_data->error = GET_JOINT_ERROR_FLAG(joint);
[01:33:49] <jepler> and it's eventually sent back to userspace (I think)
[01:34:13] <jepler> /* clear any outstanding axis errors when going into enabled
[01:34:13] <jepler> state */
[01:34:13] <jepler> SET_JOINT_ERROR_FLAG(joint, 0);
[01:34:37] <jmkasunich> so IOW, joint errors don't really do all that much
[01:34:39] <jepler> hm but there's another one in handle_jogwheels which must be of recent vintage
[01:34:45] <jepler> but no, I don't think it actually does much
[01:34:54] <jmkasunich> they don't shut down the machine or anything
[01:37:43] <jmkasunich> what about hte "can't jog while homing" message? should I get rid of that one too?
[01:38:44] <jepler> fine by me
[01:39:57] <jmkasunich> fixed
[01:40:22] <jmkasunich> jepler: got a question about home_sequence stuff
[01:40:28] <jepler> I'll try to answer
[01:41:05] <jmkasunich> in control.c line 1131, you test for "is it ok to start a sequence" (basically, is a single axis home already going on
[01:41:27] <jmkasunich> most commands do that kind of "can I do this" testing in command.c (in the big switch)
[01:41:42] <jmkasunich> and if they can't execute the command, they drop it at that point
[01:42:07] <jmkasunich> any reason you can think of why I shouldn't move that test?
[01:42:47] <jepler> put it in the most natural place
[01:43:53] <jmkasunich> ok
[01:44:14] <jepler> be careful that you don't move home_sequence = 0; which is erroneously in the for loop (!?)
[01:44:45] <jmkasunich> actually, I pulled it out of the for loop when I made my change yesterday
[01:44:48] <jepler> so I don't you can't get rid of the separate HOME_SEQUENCE_START state, it still has to set home_sequence = 0
[01:44:55] <jmkasunich> right
[01:44:57] <jepler> ok -- I must not have updated
[01:45:25] <jmkasunich> if you don't have emcmotStatus->homing_active = 1; after the loop, you didn't
[01:45:42] <jepler> did you ever look at the comp 'personality' stuff? I am still trying to decide if it's so opaque nobody will be able to understand it...
[01:45:57] <jmkasunich> no, I've been too busy
[01:46:06] <jepler> ok, np
[01:47:45] <jepler> soon I'm going to add something more useful and easier to understand -- instead of 'option data' and a struct, you'll be able to write 'variable float old_in;' (as many 'variable's as you like) and get a convenience define for each one
[01:48:41] <jmkasunich> they'll actually be in a struct, you just won't see it?
[01:48:44] <jepler> right
[01:49:28] <jepler> and it'll support arrays 'variable float old_values[4];'
[01:49:39] <jmkasunich> handy
[01:49:56] <jepler> I hope so
[01:51:32] <jepler> I'm thrilled that LawrenceG could do something useful with comp pretty quickly
[01:51:59] <jmkasunich> yeah
[01:52:23] <jmkasunich> it really is quick to write a simple comp
[01:52:44] <jmkasunich> when ed was working on the stepgen problem, he lamented the lack of an xor component
[01:52:54] <jmkasunich> 10 mins later, we had an xor
[01:53:20] <jepler> that tempts me to backport 'lut5', you can do all the possible logic functions for 2-5 inputs if only you can figure out the mysterious 32-bit number for it
[01:53:43] <jmkasunich> did I see a new comp called "logic" ?
[01:54:00] <jepler> yeah --
http://linuxcnc.org/docs/devel/html/man/man9/logic.9.html
[01:54:08] <jepler> Experimental general 'logic function' component. Can perform 'and', 'or' and 'xor' of up to 16 inputs
[01:54:53] <jmkasunich> hmmm
[01:55:26] <jmkasunich> cool, other than the fun config values
[01:55:35] <jepler> yeah, that's the problem with both lut5 and logic
[01:55:58] <jmkasunich> if personality was a string array, you could do "and3,xor3,or12,and2"
[01:56:21] <jmkasunich> nand, nor, and xnor too
[01:56:37] <jmkasunich> that means parsing code, which is a bit of a pain, but....
[01:56:50] <jepler> I don't think it would be too bad
[01:57:18] <jmkasunich> should there be a count? or does the number of elements in the array specify that?
[01:57:48] <jepler> because I didn't want to reserve any value for 'sentinel' in the personality array, you have to specify both
[01:58:22] <jmkasunich> I've used -1 for the sentinel for things like step_type, etc
[01:58:44] <jmkasunich> oh - the personality logic is part of comp, and general, right?
[01:58:47] <jepler> yes
[01:59:01] <jmkasunich> I was thinking it (and the array's default value) could be set as needed by that specific comp
[01:59:32] <jmkasunich> does that also mean that personality is always an int array?
[01:59:53] <jepler> yes
[02:00:20] <jepler> the source to logic.comp, if you didn't find it already:
http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/components/logic.comp?rev=1.1;content-type=text%2Fplain
[02:00:38] <jmkasunich> I'm letting myself get distracted again
[02:01:01] <jmkasunich> (I'm talking to you while backporting the jog interlocking to 2.1 - probably not a good idea)
[02:01:16] <jepler> that's no good
[02:01:25] <jepler> I'll let you work on that, I should do drudgery like dishes and tending the cats
[02:01:36] <jmkasunich> ok
[02:13:06] <jmkasunich> homing code needs to be moved out of control.c one of these days
[02:13:11] <jmkasunich> its 500 lines
[02:13:19] <jmkasunich> (at least)
[02:37:27] <jepler> jmkasunich: based on what you've seen so far with fpga step generation, is 100 FFs too little area for one step generator?
[02:37:46] <jmkasunich> I think so
[02:37:52] <jepler> seems like you get that many FFs pretty quick with just the position, velocity, and acceleration registers
[02:37:54] <jmkasunich> I haven't counted them up yet
[02:38:09] <jmkasunich> I think peter did, lemme check some of my emails from him
[02:38:27] <jmkasunich> we're not doing accel in hardware
[02:38:38] <jepler> oh no?
[02:38:46] <jmkasunich> but position, velocity, and the timing params (steplen,etc) add up
[02:39:00] <jepler> I thought one of software stepgen's strong points was distributing acceleration along a servo period
[02:39:00] <jmkasunich> the driver implements accel - new frequency every 1mS
[02:39:36] <jmkasunich> I'm not sure how strong that really is
[02:40:15] <jmkasunich> at moderate speeds, you might not even be getting a step every servo period, let alone enough to witness ramping within a period
[02:42:09] <jmkasunich> can't find peter's comments on gate count for stepgen
[02:42:29] <jmkasunich> fwiw, he fit 8 stepgens, 8 pwmgens, and 8 encoder counters in a 5i20
[02:42:42] <jmkasunich> pwmgen is the smallest
[02:42:49] <jmkasunich> stepgen might be the biggest
[02:42:52] <jepler> 5i20 is 20k ffs?
[02:43:07] <jmkasunich> I don't think its that hi
[02:43:12] <jmkasunich> 200k "gates"
[02:44:37] <jmkasunich> 4704 FFs and 4704 4-input LUTs
[02:44:49] <jmkasunich> I think 2 luts and 2 ffs is a slice, and 2 slices is a clb
[02:44:59] <jmkasunich> 2176 CLBs
[02:45:51] <jepler> hm ok
[02:46:28] <jepler> there are 576 (I think) LUT+FFs in the pluto
[02:46:44] <jmkasunich> so about 1/8 as much
[02:47:01] <jepler> that's great as long as I only want one stepgen :-P
[02:47:58] <jmkasunich> you could probably shrink the stepgen some
[02:48:26] <jepler> by picking the right number of bits for this and that, you mean?
[02:48:34] <jmkasunich> I think peter is using 48 bit accum, 24 bit rate, and 12 bits for the timing params (3 counters)
[02:48:58] <jmkasunich> dropping those to 40, 20, and 8 would make a dent in the gate/ff count
[02:49:19] <jepler> accum_bits - rate_bits ~= maximum steps per ms?
[02:49:24] <jmkasunich> prescale the clock for the timing param counters so you still have a good range - don't need extreme resoltion
[02:49:33] <jmkasunich> yes
[02:51:20] <jepler> seems like a rate of 1 would give about 1 step per ms if the clock is 1ns
[02:51:56] <jmkasunich> ?
[02:52:11] <jepler> 1ms / 2^20 ~= 1ns
[02:52:17] <jmkasunich> oh, right
[02:52:44] <jmkasunich> I don't think of 1 per ms as being a good minimum frequency
[02:52:51] <jmkasunich> but then, 1nS isn't the real clock
[02:53:24] <jmkasunich> if you prescaled the clock down to 1MHz, then 1 = 1Hz, 2^19 = 500KHz
[02:53:35] <jmkasunich> seems like a nice range/resolution combo
[02:53:53] <jmkasunich> you could use a 32 bit accum
[02:54:36] <jmkasunich> 12 bits above the pickoff point means up to 4K steps/period, at 500KHz max thats 8mS
[02:54:49] <jepler> was just working out that math
[02:55:31] <jepler> then the timing parms are in microseconds as well?
[02:55:54] <jmkasunich> yeah, kind of convenient
[02:56:04] <jmkasunich> 1 to 255uS with 8 bits, plenty long
[02:56:11] <jmkasunich> could probably do 6 bits
[02:56:27] <jepler> what are the 3 timing params
[02:56:29] <jepler> ?
[02:56:39] <jmkasunich> steplen, dirhold, dirsetup
[02:56:50] <jepler> with stepspace the same as steplen?
[02:56:58] <jmkasunich> stepspace isn't used by the hardware
[02:57:24] <jmkasunich> the driver uses stepspace to calc the max frequency, as long as you don't exceed that you won't have less than the proper space between steps
[02:57:27] <jepler> if stepspace+steplen is high it just .. yeah
[02:58:15] <jepler> it's tempting to make dirhold == dirsetup
[02:58:33] <jepler> as another corner to cut
[02:59:05] <jmkasunich> that could help
[02:59:16] <jmkasunich> another corner: use the same timing params for all channels
[02:59:33] <jmkasunich> each channel still needs its own counters, but they'd share the register
[02:59:39] <jmkasunich> registers
[02:59:43] <jepler> yeah
[03:00:54] <jmkasunich> so, per channel you're looking at 20 bit rate register, 32 bit accumulator, 2 eight bit loadable down counters
[03:01:17] <jmkasunich> global: prescaler from Fclk to 1MHz, and two 8 bit timing param registers
[03:01:37] <jmkasunich> plus some glue
[03:01:56] <jepler> yeah -- the epp interface uses a fair number of gates
[03:02:00] <jmkasunich> the accums are the only ones that need to be readable
[03:02:51] <jepler> for pluto I'd be thrilled to get 4 stepgen, 1 or 2 pwm, 1 or 2 quadrature, and the rest I/O
[03:03:00] <jepler> but I think that's "you're dreaming" territory
[03:03:05] <jmkasunich> that would be most impressive
[03:03:18] <jmkasunich> drop the pwm and quadrature and you might have a shot
[03:03:31] <jmkasunich> keep one pwm maybe, for spindle speed
[03:03:39] <jmkasunich> oh, you want lathe spindle encoder....
[03:03:50] <jmkasunich> lathe version: 2 stepgen, 1 pwm, 1 encoder
[03:03:55] <jepler> mill version: 3 stepgen + 1pwm + digital I/O
[03:04:01] <jmkasunich> mill version: 3/4 stepgen, one pwm
[03:04:11] <jepler> yeah, doing two versions wouldn't be too bad
[03:04:51] <jepler> the new stepgen is essentially the fpga method we've been discussing, right?
[03:05:03] <jmkasunich> pretty much
[03:05:33] <jmkasunich> I did a few things differently
[03:05:38] <jmkasunich> mostly the down counters
[03:06:06] <jmkasunich> instead of loading one value, waiting for it to hit zero, and loading another value (or starting another counter), I just loaded the sum
[03:06:50] <jmkasunich> I think one counter 1 or 2 bits longer could replace all three
[03:07:04] <jmkasunich> load it with the sum of all three timing params
[03:07:10] <jmkasunich> then do equality comparisons
[03:07:20] <jmkasunich> start with len+hold+setup
[03:07:34] <jmkasunich> when it counts down to hold+setup, terminate the step pulse
[03:07:41] <jmkasunich> when it counts down to setup, change dir (if needed)
[03:07:58] <jmkasunich> when it counts down to zero, unhold the accum
[03:08:07] <jmkasunich> (you hold the accum when a dir change is pending)
[03:08:32] <jmkasunich> how expensive are equality comparisons in that FPGA family?
[03:08:46] <jmkasunich> 4 input LUT compares 2 bits
[03:08:55] <jmkasunich> five of them compare 8 bits
[03:09:08] <jepler> I can't remember if the LUTs are 3 or 4 bits
[03:09:27] <jmkasunich> 3 would make wide equality tests expensive
[03:12:49] <jepler> it can be a 4-input, 1-output LUT or a 3-input, 2-output LUT. In either case, one input can be from a "carry chain", and in the second case the second output is to the carry chain
[03:13:23] <jmkasunich> so one LUT per adder bit
[03:13:42] <jmkasunich> or counter bit
[03:13:51] <jepler> yeah it looks that way
[03:14:22] <jmkasunich> do the FFs have a separate clock enable?
[03:15:08] <jmkasunich> if so, count/don't count comes from there, not a LUT input
[03:15:46] <jepler> "u/d" is one of the inputs to a 3-LUT in this picture of the "Up/Down Counter Mode" for a logic block
[03:16:10] <jepler> in that mode there's a reset input which is not part of the LUT, it's shown as a separate mux
[03:16:28] <jmkasunich> oh
[03:16:38] <jepler> http://emergent.unpy.net/files/papers/acex.pdf page 21
[03:16:40] <jmkasunich> so a preloadable counter would be 2 luts per bit
[03:17:27] <jepler> sorry, the MUX is a load, not just a clear
[03:19:02] <jmkasunich> oh, in the "2 out" mode (carry), the 3 ins don't have to be the same....
[03:19:40] <jepler> Figure 10 shows how the cascade function can connect adjacent LEs to form functions with a wide fan-in. These examples show functions of 4n variables implemented with n LEs. The LE delay is 1.3 ns; the cascade chain delay is 0.6 ns. With the cascade chain, decoding a 16-bit address requires 3.1 ns.
[03:21:38] <jmkasunich> the clearable counter looks promising for the timing counters
[03:21:45] <jmkasunich> make it a clearable down counter
[03:22:02] <jmkasunich> and use the carry out to tell you when it hits zero
[03:22:40] <jmkasunich> do those FPGAs have any RAM?
[03:23:03] <jmkasunich> * jmkasunich reads the doc
[03:23:21] <jepler> yes but I haven't figured out how to use it yet
[03:23:52] <jmkasunich> looks like 256x16 in each ram block
[03:24:13] <jmkasunich> what is the clock?
[03:24:17] <jmkasunich> 40MHz IIRC?
[03:26:55] <jmkasunich> * jmkasunich thinks he knows how to get LOTS of channels
[03:27:41] <jmkasunich> one adder - read rate 0 from ram, read accum 0 from ram, add, write accum 0 to ram, repeat for channel 1, 2, 3, etc
[03:27:56] <jmkasunich> if the clock is 40MHz, and you only need 1MHz, you have 40 clocks to work with
[03:28:03] <jmkasunich> 10 channels with 4 clocks each ;-)
[03:28:34] <jepler> yes, 40MHz
[03:28:42] <jepler> I'd sure consider that if I could figure out the RAM
[03:29:57] <jmkasunich> how many eabs are in that device? 3?
[03:30:47] <jepler> yes
[03:31:00] <jmkasunich> so 2 of them could give you 256x32
[03:31:48] <jepler> this // this gives me 86 LEs used (device total is 576)
[03:31:48] <jepler> always @(posedge clk) velocity <= ivelocity;
[03:31:48] <jepler> always @(posedge clk) if(!hold) position <= position + hvelocity;
[03:32:00] <jepler> velocity 20 bits, position 32 bits (hvelocity is sign-extended velocity)
[03:32:05] <jepler> that's before I do hold time counters or any of that fancy stuff
[03:32:26] <jmkasunich> what is ivelocity?
[03:32:31] <jmkasunich> accel ramp?
[03:32:49] <jepler> no, that's the actual value from input pins, which I latch into velocity
[03:32:56] <jmkasunich> duh, its not an add, just an assign
[03:33:21] <jmkasunich> so you don't really do that "always", only when the PC is writing?
[03:33:47] <jepler> yes
[03:34:25] <jmkasunich> duh, at first I missed the line that said "this uses X resources" and I wondered why you were showing me code
[03:34:32] <jepler> oh -- sorry
[03:34:46] <jmkasunich> not your fault I can't read
[03:35:30] <jmkasunich> the ram thing is very interesting
[03:35:45] <jmkasunich> it could get you silly numbers of channels, limited only by I/O pins
[03:37:23] <jmkasunich> the epp bus has handshaking, right?
[03:38:38] <jmkasunich> so if you are trying to read or write data for channel N, it can wait until that channel comes around
[03:38:53] <jmkasunich> read velocity N into vel register
[03:39:20] <jmkasunich> read accum N into vel register
[03:39:34] <jmkasunich> write velocity N back into ram (this allows the PC to change it)
[03:39:43] <jmkasunich> oops
[03:39:56] <jmkasunich> read velocity N from RAM into vel register
[03:40:09] <jmkasunich> read accum N from RAM into accum register
[03:40:15] <jmkasunich> write velocity N back into ram (this allows the PC to change it)
[03:40:33] <jmkasunich> write sum of accum and vel register back into ram
[03:41:16] <jmkasunich> a PC write of velocity N would be deferred until velocity N is in the vel register, then overwrite the regsiter and be written to RAM 1 cycle later
[03:41:35] <jmkasunich> a PC read of accum N would be deferred until accum N is in the accum register
[03:41:50] <jmkasunich> 4 clocks per channel
[03:42:04] <jepler> I assume that all you say is true
[03:42:11] <jmkasunich> lol
[03:42:11] <jepler> I'm starting to go fuzzy
[03:42:16] <jmkasunich> it is late
[03:42:22] <jmkasunich> especially for you
[03:42:46] <jmkasunich> do you have any digital hardware background?
[03:43:39] <jepler> no, unfortunately not
[03:43:41] <jmkasunich> I tend to think in gates and registers, and have to translate that into vhdl... if you are strictly software, you are more likely to think in vhdl/verilog directly
[03:43:58] <jepler> I took a "these are gates, they are made of transistors" class back in college but little of it stuck
[03:44:05] <jepler> I think we might have done a karnaugh map once
[03:44:12] <jmkasunich> although to be honest, this algorithm (using the ram) might be better represented in code with an array
[03:44:27] <jmkasunich> for n = 0 to numchan
[03:44:53] <jmkasunich> ram[2*n] = ram[2*n] + ram[2*n+1];
[03:45:13] <jmkasunich> presto, numchan accumulators, with only one adder
[03:45:47] <jmkasunich> make that 8*n
[03:45:52] <jmkasunich> then the counters:
[03:46:11] <jmkasunich> ram[8*n+2] = ram[8*n+2] -1
[03:46:20] <jmkasunich> and +3, +4
[03:47:13] <jmkasunich> is that making any sense at all?
[03:47:38] <jmkasunich> I'm not sure it would even make sense to me if I didn't already know what I meant
[03:47:45] <jepler> yes some
[03:47:49] <jepler> I'm not sure how you've numbered your RAM
[03:48:05] <jmkasunich> just an array of 256 words, 32 bits wide
[03:48:18] <jepler> is there dual-read + write ram? if not, your first arithmetic can't be done in one cycle
[03:48:22] <jepler> 22:44:53 <jmkasunich> ram[2*n] = ram[2*n] + ram[2*n+1];
[03:48:43] <jmkasunich> that assumed that accum and vel for a channel were stored in consecutive locations
[03:49:08] <jmkasunich> then I changed to 8*n, so I had 8 consecutive locations for each channel
[03:49:22] <jmkasunich> accum, vel, timer0, timer1, timer2, and some spares
[03:49:43] <jmkasunich> could think of it as an array of structs, one per channel
[03:50:21] <jmkasunich> I think the first math operation might take 3 cycles
[03:50:30] <jepler> I'm just trying to figure out why quartus says it can't combine any of these LUTs with FFs
[03:50:30] <jmkasunich> read vel, read accum, write accum
[03:50:44] <jmkasunich> the others would take 2, read and write
[03:52:32] <jmkasunich> before I go to bed, here's another weird idea to twist your mind around
[03:52:38] <jmkasunich> bit serial, channel parallel
[03:52:51] <jmkasunich> again using the ram
[03:53:09] <jepler> no you'll make my head explode
[03:53:27] <jmkasunich> one 16 bit word contains bit 0 of accum 0, bit 0 of vel 0, bit 0 of accum1, bit 0 of vel 1, etc ( 8 channels)
[03:53:43] <jmkasunich> the logic is a 1 bit adder, carry held in a ff until the next clock
[03:54:11] <jmkasunich> 32 clocks = eight 32 bit sums
[03:54:35] <jmkasunich> transforming the data from bit serial to bit parallel for PC I/O is left as an excersize
[03:54:56] <jmkasunich> on that note, goodnight
[03:55:26] <jepler> goodnight
[03:55:31] <jepler> sorry I distracted you from your backport again
[03:55:35] <jmkasunich> its done
[03:55:52] <jmkasunich> an hour ago
[03:57:45] <jepler> oh
[03:57:48] <jepler> nevermind then
[12:39:19] <jepler> good morning
[12:42:38] <rayh> How you doing today?
[12:42:53] <rayh> oops school starting up.
[12:44:37] <skunkworks> school?
[12:48:57] <rayh> My connection crashes when they startup the computer labs at school
[12:49:29] <SWPadnos> heh
[12:49:56] <skunkworks> ouch
[12:50:46] <SWPadnos> why is the school on your dial-up party line? :)
[12:50:57] <rayh> I hope that the microwave folk get here this spring.
[12:51:42] <rayh> My dial up is located at the school
[12:52:01] <rayh> closet full of modems.
[12:52:15] <SWPadnos> ah
[12:52:22] <SWPadnos> like our old BBS
[12:53:46] <rayh> That's the model.
[13:00:43] <alex_joni> hi guys
[13:01:30] <rayh> Hi alex
[13:02:04] <SWPadnos> hi Alex
[14:12:36] <jepler> rayh: oh my morning has been frustrating but I'm sure it'll get better
[14:13:08] <SWPadnos> of course
[14:13:18] <SWPadnos> you could talk to rafa for a while to cheer you up
[14:15:53] <jepler> thanks for the suggestion
[14:17:10] <SWPadnos> heh
[14:17:44] <SWPadnos> I read through your discussion with jmk about FPGA stepgens
[14:18:02] <SWPadnos> unfortunately, I did so before having coffee, so I didn't retain much
[14:18:29] <jepler> I was reading it while half asleep so I missed a lot too
[14:19:11] <SWPadnos> I'm not sure about the acex, but I know that some other FPGAs let you use RAM as dual-port if you halve the storage space
[14:19:17] <alex_joni> http://www.robcon.ro/emc/59BE8D55.jpg
[14:19:23] <jepler> If I want to do 4 stepgens + other functionality on pluto I think I have to follow his suggestion to use RAM for the data and have some sort of a state machine do each of the step generators in turn
[14:19:39] <SWPadnos> yep, probably
[14:19:41] <alex_joni> jepler: something for you :)
[14:20:11] <SWPadnos> F3 and F5 should be translated ;)
[14:20:40] <alex_joni> SWPadnos: "patches happily accepted" :-P
[14:20:42] <anonimasu> alex_joni: what's that?
[14:20:45] <SWPadnos> heh
[14:20:51] <alex_joni> anonimasu: AXIS
[14:20:59] <alex_joni> one of the emc2 GUIs
[14:21:00] <anonimasu> your part.
[14:21:18] <alex_joni> not my part.. the pic shows a nice translation, the part is irrelevant
[14:21:55] <jepler> alex_joni: cool -- check it in!
[14:21:56] <cradek> is it chinese?
[14:21:59] <jepler> the part does look cool
[14:22:00] <SWPadnos> it looks like a stylized Japanese character
[14:22:07] <alex_joni> jepler: I only got the pic.. waiting for the rest now
[14:22:11] <SWPadnos> or a small air manifold ;)
[14:22:12] <alex_joni> will check it in once I have it
[14:22:14] <cradek> whee
[14:22:36] <jepler> it's a running dude
[14:22:54] <SWPadnos> with wavy things coming out of his hands
[14:22:54] <alex_joni> a friend of mine from the cool tool is now in .. bogota? he sent it to me just now
[14:26:44] <cradek> I really like how 'the cool tool' unabashedly uses Free software, giving all the rights to their users, and some of their users decide to improve the software. They concentrate on selling hardware, which it seems they're good at doing.
[14:30:12] <cradek> alex_joni: do you know what that part is? it's very small
[14:31:53] <cradek> oh! I see the 'running dude' now
[14:32:41] <SWPadnos> I'm still betting on a stylized character of some sort (or an air manifold)
[14:33:01] <SWPadnos> hmm. no ports, probably not a manifold
[14:33:06] <cradek> it's only 29mm across - my bet is it's jewelry
[14:33:28] <SWPadnos> yep
[14:33:49] <SWPadnos> pendant maybe - the upper circle (up left) could be a chain hole
[14:40:07] <jepler> I think the whole 'comp' documentation could benefit from being reorganizd
[14:40:09] <jepler> reorganized
[14:43:40] <SWPadnos> I never found it in the docs on an installed system
[14:44:37] <cradek> it's unfortunate there's a block called comp, so man comp doesn't give you what you want
[14:44:39] <SWPadnos> hmm. I now remember seeing a chapter in the manual that was cut off
[14:44:45] <SWPadnos> heh - I noticed ;)
[14:44:57] <SWPadnos> any pydoc didn't help either
[14:45:09] <SWPadnos> and
[14:47:40] <jepler> there's not a manpage for comp(1)
[14:47:45] <jepler> someone should write it
[14:49:49] <jepler> comp documentation is in HAL_User_Manual.pdf (chapter 9) but it looks like it didn't make the integrator manual.
[15:17:34] <rayh> I just put a couple of images on my wiki page that seems to show an issue with TP.
[15:17:39] <rayh> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Rayhenry
[15:21:21] <SWPadnos> that looks how I imagine slow jogwheel operation acts
[15:23:18] <rayh> Those two are only two loops around the spiral from each other.
[15:23:43] <SWPadnos> similar segment lengths? (I haven't looked at the code yet)
[15:24:11] <rayh> segment length or angle must make the difference.
[15:25:22] <rayh> Almost looks like there are "harmonics" in it someplace.
[15:26:16] <rayh> I know there will be times here when the system says "I can't go that speed."
[15:26:27] <rayh> but these seem excessive.
[15:26:42] <SWPadnos> the images are in reverse order
[15:26:49] <SWPadnos> the spiky one happened first, it seems
[15:27:19] <SWPadnos> hmmm - the names support that: screenshot-2 then screenshot-3
[15:27:19] <rayh> Yes.
[15:27:30] <SWPadnos> ok (was searching though the G-code for that :) )
[15:27:34] <SWPadnos> through
[15:27:58] <SWPadnos> deos it happen every time on that particular go-round?
[15:28:18] <rayh> The snapshot is not sync'd with the actual executing line.
[15:28:31] <SWPadnos> ok
[15:28:49] <rayh> My next test is to see if I get similar behavior with a different box.
[15:28:57] <rayh> That was made with the mini-tx
[15:29:05] <SWPadnos> try a differnt feedrate first
[15:29:05] <rayh> -itx
[15:29:10] <SWPadnos> different
[15:30:06] <rayh> You know how hard it is for this old man to handle that many tasks at once?
[15:30:52] <SWPadnos> heh
[15:31:11] <SWPadnos> ok - Applications -> Accessories -> Text Editor .... ;)
[15:32:15] <rayh> How much difference is speed do you think. 90%
[15:32:36] <SWPadnos> dunno - just curious if it changes anything
[15:33:21] <rayh> Will try.
[15:36:38] <alex_joni> FO should do the same thing
[15:37:59] <SWPadnos> alex_joni, shhh - that's too easy
[15:41:22] <rayh> I've never been known to do things the easy way ;)
[15:43:30] <rayh> about the same thing for the 6'th loop
[15:44:36] <rayh> as the 7'th shown as screenshot-2
[15:44:38] <cradek> rayh: what emc version?
[15:44:57] <rayh> this morning
[15:45:47] <cradek> I noticed in some of our sample configs, we run the traj cycle only every ten servo cycles - I don't think that's anywhere near often enough - try changing it so TRAJ_PERIOD = SERVO_PERIOD and see if you get some improvement
[15:45:49] <SWPadnos> rayh, what does the plot look like at ~20ms/div?
[15:46:13] <rayh> The points of large variation in velocity seem to change location with feedrate.
[15:47:08] <rayh> 20m/div?
[15:48:33] <rayh> That is to steep to see much in any one shot.
[15:49:13] <SWPadnos> horizontal - 20 ms/division
[15:49:38] <SWPadnos> you had it at 1 second, so we only seee roughly 1/50 the samples
[15:49:41] <cradek> can you post this gcode somewhere
[15:49:49] <SWPadnos> it's linked on the wiki page
[15:49:57] <cradek> oh!
[15:51:13] <rayh> This is the program roltek was having so much trouble with his servo drives.
[15:53:57] <jepler> around line 850 I saw speed really drop. I think if you look near there you'll find some extremely short segments.
[15:54:13] <jepler> I added G64 P.001 at the top, to turn on segment combining, and I don't get speed drops there now
[15:54:20] <cradek> yep me too
[15:55:24] <cradek> X-3.4732Y-2.43Z-1.8911
[15:55:24] <cradek> X-3.4723Y-2.4313Z-1.8912
[15:55:24] <cradek> these are lines 821, 822
[15:55:25] <cradek> he can fix this by either fixing the cam output or using tolerance mode like jepler says
[15:56:25] <cradek> before about line 800 the program doesn't contain these kinds of lines and I see very good tangential velocity plots in halscope
[15:57:26] <rayh> I suggested g64 p.001 and tried it here.
[15:57:48] <rayh> If the p value gets very large velocity goes goofy.
[15:58:14] <rayh> I didn't look for the kinds of lines you see though.
[15:59:19] <cradek> I confirmed here that G64 P0.001 fixes it
[16:00:03] <rayh> I'll ask him to go back and look at his cam for this.
[16:00:23] <rayh> Thanks guys.
[16:00:41] <cradek> if he can't fix it, tolerance mode is a great workaround - that's why it's there - mostly for bad cam output
[16:00:42] <jepler> I've run through about line 2700 now with G64 P.001, and halscope hasn't captured XYZvel dropping below about .770 inch/second more than once around line 850. That time it dropped to about .51 inch/second for about 100ms
[16:03:44] <cradek> yay, not a bug :-)
[16:03:49] <jepler> the point at which small segments start to give bad results depends on machine acceleration and requested speed. so if his accel is less than sim/axis (20.0 on each axis, 20.0 in [TRAJ]) it may not be as good with P.001 as it is in our tests
[16:04:04] <jepler> line 3800 yet and no more dips below .770 inch/second
[16:04:09] <cradek> true
[16:04:36] <rayh> I'm only seeing about two loops around that cause this kind of behavior.
[16:04:43] <rayh> Beyond that it seems to be fine.
[16:04:54] <rayh> Inside of those it seems to be fine also.
[16:05:30] <cradek> lines 800-900 have long, long, short, long, long, short
[16:05:41] <jepler> cradek: is there a HAL parameter which gives the executing line? It would be nice to find out what line was executing when halscope triggered...
[16:05:47] <cradek> before line 800, the output is good
[16:05:51] <rayh> I should have left the line numbers in his file.
[16:06:16] <alex_joni> jepler: I don't think there is.. but I can easily add that
[16:06:17] <cradek> AXIS shows the real line numbers anyway
[16:06:29] <alex_joni> cradek: yeah, but it's not linked into halscope
[16:06:29] <jepler> "physical" line numbers
[16:06:44] <rayh> right.
[16:06:49] <jepler> I know machinists are different than programmers, but I'm more than happy to think in physical line numbers
[16:07:14] <rayh> I still think in 10s because then I could add stuff.
[16:07:29] <jepler> yeah that was the way it was done on old line-number BASIC too
[16:07:32] <jepler> I'm so happy those days are over :-P
[16:08:04] <rayh> Right I remember some of that.
[16:09:14] <rayh> I still remember setting register values with toggle switches and reading results with lamps.
[16:10:09] <rayh> Okay. Thanks for all the help on this and for the work of writing it.
[16:10:30] <cradek> :-)
[16:10:39] <jepler> you had lamps? luxury! we had to use an ammeter to find out how many bits were TRUE in the accumulator, and then guess which ones they were
[16:10:48] <SWPadnos> you had meters?
[16:10:55] <jepler> well I call it a meter
[16:10:58] <SWPadnos> when I was young we had to use our tongues!
[16:11:02] <jepler> really you just passed the current .. yeah that was exactly it!
[16:12:09] <cradek> but when you tell that to kids today, do they believe you?! no!
[16:12:16] <SWPadnos> of course not
[16:12:23] <rayh> I was in fat city when I got to the Allen Bradley 7300 CNC. It had momentary switches and lamps.
[16:12:40] <jepler> http://en.wikipedia.org/wiki/Differential_power_analysis
[16:13:25] <cradek> rayh: I'm looking for a picture of that...
[16:13:51] <cradek> lots of people selling spare parts (for a huge sum I'm sure)
[16:14:53] <cradek> http://www.jd-enterprises.com/AKBE_web.JPG
[16:15:01] <cradek> what a great order to put the letters in!
[16:15:36] <SWPadnos> easier for non-typists, I imagine
[16:15:55] <jepler> I'm surprised they had all the letters
[16:15:59] <SWPadnos> though it's hard to imagine someone in this day not knowing the layout of a QWERTY keyboard
[16:16:04] <jepler> and comma?
[16:16:28] <cradek> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=7586334274
[16:16:39] <cradek> here's a "board" for it, for $95
[16:16:49] <cradek> This is a working Board. It Has been checked and verified to be in full working order.
[16:16:54] <cradek> yeah I bet it has.
[16:17:50] <jepler> this must be way newer, it has a CRT
http://www.digitek-asi.com/images/cncs/ab8400.jpg
[16:19:57] <cradek> wow
[16:20:19] <cradek> wonder if the dymo labels came on it?
[16:21:58] <rayh> Yes the 8400 was newer
[16:24:40] <jepler> I ran the program again from the start (instead of using run-from-line) and I don't even get the glitch I saw around line 850 the last time
[16:25:31] <jepler> does his mill really have 60 inches of "Z" travel?
[16:26:03] <rayh> I don't really know.
[16:26:23] <cradek> the 60" long ball-end mill is what I'd like to see
[16:26:26] <rayh> It would have to look like those old G&Ls at Rolands.
[16:26:38] <jepler> cradek: only thing I could figure is that this is a finishing pass
[16:26:54] <jepler> not starting with a a 30x30x60 solid piece
[16:27:05] <cradek> looks like he needs a lathe :-)
[16:27:11] <jepler> hah
[16:27:25] <jepler> is CSS done yet?
[16:27:35] <cradek> no, matt s says he'll do it, so I don't have to
[16:27:42] <alex_joni> ha
[16:28:01] <cradek> brb
[16:28:02] <rayh> * rayh makes a note to bug matt.
[16:28:15] <rayh> oh hi mshaver
[16:30:08] <mshaver> hey ray!
[16:30:23] <mshaver> wait, reading back...
[16:30:38] <alex_joni> mshaver: oh-oh, now you're stuck with CSS
[16:30:54] <jepler> alex_joni: only until someone else with commit privs shows up to say how CSS doesn't sound *that* hard
[16:31:09] <alex_joni> jepler: yeah, there are all kinds of folks around :)
[16:31:39] <mshaver> for a minute I was saying to myself, "What's CSS?"...
[16:31:54] <mshaver> I'm no web designer!
[16:32:22] <mshaver> oh yea, constant surface speed...
[16:32:27] <alex_joni> hahaha
[16:32:31] <alex_joni> try CSS2 :P
[16:34:27] <mshaver> actually, the last couple of days i've been setting up a workbench in my office and getting together a bunch of wire & connectors to make myself some test setups - i don't have any cnc machines in my shop.
[16:36:51] <rayh> Where did you set up your office?
[16:37:44] <mshaver> in that apartment on the side of the house - perhaps i'm being a little pretentious calling it an "office"
[16:38:00] <mshaver> more like "room with table"
[16:38:11] <SWPadnos> you should see my cellar - err - office :)
[16:38:18] <rayh> Fantastic. That is a good use for that space.
[16:38:52] <rayh> Hey. You ought to register so I can bug you directl
[16:39:11] <mshaver> register?
[16:39:33] <mshaver> I'm already registered, but they never drafted me
[16:39:52] <mshaver> damn good thing I'm old now...
[16:40:11] <SWPadnos> phew!
[16:40:55] <rayh> I was dead last in the draft lottery.
[16:41:19] <rayh> guess I'd better shut up in the devel.
[16:41:25] <mshaver> yea, but in a town of 50 people...
[16:41:48] <rayh> gotta run to town guys. bbl
[16:44:07] <mshaver> me too - gotta go install a dvd drive in a pc - back later for more! soldering too!
[16:55:11] <jepler> interesting -- a G49 tool length offset doesn't seem to be reset on M2
[16:55:24] <jepler> I couldn't figure out why the AXIS preview plot and the actual plot didn't line up .. a left-over tool length offset was the reason
[17:01:17] <jepler> just for fun I wrote a Python program to generate a toolpath similar to todd2.ngc using arcs.
http://emergent.unpy.net/files/sandbox/todd.py output:
http://emergent.unpy.net/files/sandbox/todd.ngc
[17:04:57] <skunkworks> jepler: do you really think you could get 4 step generators in the pluto?
[18:17:34] <jepler> skunkworks: I'm not sure how hard I'm going to try to do a step generator for pluto
[18:18:42] <cradek> jepler: that is apparently according to the spec
[18:21:01] <skunkworks> jepler: I think if it is possible - there would be tons of people that would go for it. $70 dollar step generator is unheard of
[18:24:37] <jepler> skunkworks: that may be true .. but there are a couple of things that hold me back: I think that servo, no stepper, is the way to go. And I've discovered from the first few users of pluto_servo that I'm really not interested in supporting a product
[18:24:51] <SWPadnos> heh
[18:25:04] <jepler> (if I thought I could sell it for $$ it might be a different story)
[18:25:10] <SWPadnos> $$$
[18:25:14] <SWPadnos> minimum
[18:25:28] <jepler> the pluto-p board is so cheap in part because it's crappy -- it's not $70 by the time you add proper isolation, for instance
[18:25:44] <SWPadnos> or an in=spec voltage regulator
[18:25:48] <SWPadnos> in-spec
[18:33:19] <a-l-p-h-a> another 10 more units to centre drill, drill, enlarge, tap. Another 40 steps.
[18:33:25] <a-l-p-h-a> ~1hr...
[18:33:50] <a-l-p-h-a> has anyone made their own automated tapping unit?
[18:35:52] <cradek> I hear tapping heads on a drill press work really nicely
[18:35:59] <cradek> (I've not used one)
[18:36:19] <SWPadnos> they work great, on a drill press or in a bridgeport
[18:36:40] <SWPadnos> though I've only used them in manual mode, of course
[18:36:57] <SWPadnos> a Tapmatic is the best thing since sliced bread though
[18:37:50] <a-l-p-h-a> tapmatic, can it fit on a lathe turret?
[18:38:07] <a-l-p-h-a> err. tailstock that extends.
[18:49:47] <SWPadnos> there are R-8 tapers available for Tapmatics, among other things (like 1/2" shanks)
[18:58:44] <skunkworks> jepler: sorry - meeting. I understand on all your points.. I don't think I would use it either.
[19:56:30] <skunkworks> * skunkworks has always had a thing for servos.
[20:47:29] <alex_joni> jepler: do you still know how to update emc2/src/po/*.po's ?
[20:51:49] <jepler> To update a language's .po file from its .pot file, use the "msgmerge" command.
[20:51:52] <jepler> Because doing this frequently creates lots of uneeded revisions of the
[20:51:54] <jepler> .po files in CVS, and because different translators have preferences about
[20:51:57] <jepler> msgmerge flags (particularly --width, --no-wrap, and --no-fuzzy-matching),
[20:51:59] <jepler> this is not done automatically by the "make" process. The simplest "msgmerge"
[20:52:02] <jepler> commandline is:
[20:52:06] <jepler> msgmerge -U xx_axis.po axis.pot
[20:52:08] <jepler> -- src/po/README
[21:07:02] <alex_joni> darn.. must have missed that
[21:07:08] <alex_joni> I swear I read that file :P
[21:11:06] <alex_joni> jepler: oh, I did read that.. but that refers to the AXIS pot
[21:11:16] <alex_joni> I was wondering about the tcl stuff
[21:11:48] <jepler> alex_joni: it's the same to update any .po from its respective .pot
[21:12:02] <alex_joni> so the tcl.pot should be up to date?
[21:12:08] <jepler> if the Makefile is right
[21:12:31] <alex_joni> ok.. cool
[21:12:44] <jepler> touch a .tcl file and see if it rebuilds tcl.pot
[21:14:25] <alex_joni> yup, that works
[21:19:09] <alex_joni> it's been a while since I updated that :(
[21:25:06] <alex_joni> grep -e "msgstr \"\"" ro.po | wc -l
[21:25:06] <alex_joni> 190
[22:46:36] <roltek> cradek you there
[22:48:48] <roltek> have to leave see you later
