Back
[02:43:41] <CIA-2> EMC: 03seb 07master * r3646840e462a 10/src/hal/drivers/mesa-hostmot2/ (hostmot2.h pwmgen.c): Revert "fix pwmgen memory leaks, & simplify pwmgen a bit"
[13:51:00] <jepler> cradek: did you get emc2-sim to build on your 10.04 laptop yet?
[13:53:40] <cradek> yes
[13:53:50] <cradek> I had to install tcl8.5-dev and tk8.5-dev, NOT tk-dev and tcl-dev
[14:22:38] <jepler> http://media.unpythonic.net/emergent-files/sandbox/0001-Add-a-relative-tolerance-for-arcs-rev2.patch
[14:22:51] <jepler> ^^ another patch I have laying around that maybe should be applied to 2.4
[14:23:32] <jepler> I remember we talked about it one day pretty thoroughly
[14:23:38] <cradek> yes I recall we studied that pretty hard
[14:23:45] <jepler> iirc the only outstanding objection was to the error message itself
[14:23:55] <jepler> which I agree is sucking harder and harder every day
[14:25:01] <jepler> (though I suppose I could leave the error message unchanged)
[14:25:01] <cradek> just skip changing the error, I guess. we don't want to disrupt the strings if we can avoid it, anyway.
[14:26:46] <jepler> http://emergent.unpy.net/files/sandbox/0001-Add-a-relative-tolerance-for-arcs-rev3.patch
[14:29:32] <jepler> hmmmmm
[14:29:40] <jepler> arc_radius and radiu2 are guaranteed positive, right?
[14:29:47] <jepler> (oh I can see they come from 'hypot' right there in the patch context)
[14:55:09] <jepler> oh, I *did* put that patch on master
[14:55:13] <jepler> huh
[15:32:24] <jepler> hi micges
[15:33:11] <micges> hi
[15:36:01] <micges> jepler: what's up?
[15:45:02] <jepler> not much
[15:45:16] <jepler> just trying to get through the week of work
[15:45:23] <jepler> and hoping to package up 2.4.0 this weekend
[15:46:07] <micges> would be cool
[15:48:37] <jepler> I also have 4000 europe vacation photos to sort through, and a blog entry to write on my fpga hardware rng from back in march
[15:50:02] <micges> maybe I'll also create blog
[15:50:24] <micges> if so it will be very irregulary updated ;)
[16:03:50] <micges> seb_kuzminsky: hi
[16:05:44] <jepler> micges: mine is pretty irregular too
[16:06:32] <jepler> micges: I'd rather people don't write blog entries when they have nothing to say, just to keep to some imagined schedule
[16:07:08] <jepler> micges: so I'd say "go for it"
[16:07:36] <micges> jepler: I agree
[16:09:17] <seb_kuzminsky> hi folks :-)
[16:09:56] <jepler> hi seb
[16:10:16] <micges> seb_kuzminsky: will you have few minutes to look at stepgen bug before 2.4.0 ?
[16:10:20] <seb_kuzminsky> jepler: how was europe?
[16:10:28] <seb_kuzminsky> micges: ah right, i should fix that
[16:10:31] <seb_kuzminsky> i'll do it tonight
[16:10:43] <jepler> seb_kuzminsky: pretty good on the whole
[16:11:13] <seb_kuzminsky> missed you when i came to lincoln
[16:11:14] <jepler> seb_kuzminsky: but the air travel problems have me thinking twice about international travel
[16:11:19] <jepler> seb_kuzminsky: yeah, too bad
[16:11:23] <seb_kuzminsky> jepler: srsly
[16:11:24] <jepler> chris told me some of the fun surrounding moving boss
[16:11:28] <seb_kuzminsky> time to get a pilot's license
[16:12:15] <jepler> pilot's license or not, I don't think it's financially viable to fly my own plane from nebraska to germany..
[16:14:37] <cradek> hi seb
[16:14:46] <seb_kuzminsky> hi cradek :-)
[16:15:19] <seb_kuzminsky> cradek: i think a friend in boulder will buy my x2, then we'll use the bp to make the cnc conversion parts for it
[16:15:28] <seb_kuzminsky> that should be an easier rigging project...
[16:15:30] <cradek> heh, cool
[16:15:39] <cradek> yes, does it require both hands to move, or just one?
[16:15:55] <seb_kuzminsky> maybe both if you pile the vise & clamp kit etc on the table first
[16:16:28] <cradek> did you get some parallels longer than 2" yet?
[16:16:33] <seb_kuzminsky> heh
[16:16:53] <seb_kuzminsky> i'm waiting to sell the old parallels first
[16:17:46] <cradek> it's neat that you're using it for home repairs already.
[19:14:07] <mozmck_work> bleh, still having boot problems with rtai patched kernel on 10.04
[19:14:49] <mozmck_work> boots fine on one machine (with intel onboard graphics which were more problematic), and not at all on another machine with an nvidia card.
[19:15:36] <cradek> yuck. you have my sympathies.
[19:15:40] <mozmck_work> this is with the latest patch from magma which was supposed to have some boot fixes.
[19:15:57] <mozmck_work> :) thanks!
[19:18:35] <mozmck_work> looks like somewhere the kernel versioning got broken again too. I now have to disable kernel module versioning in the kernel config to get things to work.
[20:25:19] <andypugh> I think I need a bit of advice on how to handle something the "EMC way"
[20:26:18] <andypugh> The three-phase PWM function in Hostmot2 has a readable enable bit and a readable fault bit.
[20:26:56] <andypugh> The enable bit is mirrored as an output to a pin. The fault bit depends on the input to a pin.
[20:27:27] <andypugh> If fault is active and you write to enable, nothing changes.
[20:28:25] <andypugh> if the fault bit is high, but there is no current fault and you write to enable, then fault goes low, and enable goes high
[20:28:38] <skunkworks905> Oracle Open Office Standard Edition is a complete, feature-rich office productivity suite
[20:28:46] <alex_joni> wrong channel ;)
[20:28:54] <skunkworks905> oops ;)
[20:28:59] <alex_joni> andypugh: why is the fault bit high?
[20:29:03] <andypugh> if enable is high and a fault happens, then fault goes high, and enable goes low
[20:29:14] <andypugh> external fault input
[20:29:26] <alex_joni> right
[20:29:44] <alex_joni> so when external fault goes low.. shouldn't the fault flag go low too?
[20:29:51] <alex_joni> or it's more of a latching thingie?
[20:29:52] <andypugh> But the state of the bit in the register latches
[20:30:02] <alex_joni> ok.. so enable acts as a reset?
[20:30:23] <andypugh> it latches till the enable bit is driven high
[20:30:27] <andypugh> Yes.
[20:30:54] <andypugh> But, here is the issue. The enable bit is only actively written to if the state in HAL has changed.
[20:32:06] <andypugh> In fact, it is a little more complex than that in the driver at the moment, as the last-written state is compared to the current state of the bit, and it is transmitted to the card if it differs.
[20:32:59] <andypugh> So, should the enable HAL pin mirror the register bit, or not?
[20:35:18] <jepler> enable is usually a HAL input to pwm, so pwm can't drive it
[20:35:31] <andypugh> I am thinking it probably should. Normally it will be written to by an external function every servo thread (from a button or an axis output). If it keeps getting reset by the driver_read function then it will not match the last-written value, so will keep being rewritten, which will toggle the bit and clear the fault...
[20:37:44] <andypugh> jepler: In that case I guess I need to arrange for the enable register to be written and read every cycle, whether it has changed or not?
[20:38:11] <andypugh> (Because I don't know if it has changed or not)
[20:38:33] <jepler> if you want to write it only on change, then keep the old value in your structure somewhere
[20:38:54] <andypugh> I am doing that, but that causes a problem.
[20:39:56] <andypugh> Because I only write it when the hal pin has changed, I don't toggle the register bit when it has been hanged by the FPGA because of a fault input.
[20:41:11] <andypugh> Though I could check if the hal pin matches the bit, rather than testing if the hal-pin matches the last-read
[20:41:15] <jepler> if you blindly write it all the time, it seems like you can miss a fault if you write it between the time the fault is registered in the fpga and the time the fault register is read by emc
[20:42:29] <andypugh> I don't _think_ I can over-ride the FPGA's opinion of whether the enable bit can be set or not. If the fault bit is active, the state of the enable bit can't be changed.
[20:44:37] <jepler> oh, you mean if it's a continuous fault
[20:45:31] <andypugh> I don't like the current situation, where the hal-fault can show true with the hal-enable showing true, but the register-enable is false and the PWM is off.
[20:47:29] <andypugh> Then if the fault clears, you have hal-fault showing false, hal-enable showing true, but the register enable bit is still false, to the PWM stays off.
[20:47:31] <jepler> is the "hal-enable" the IN-direction pin that will be connected to e.g., axis.0.motor-enable-out ? If so, it's no bug in your driver that it can say TRUE while the PWM is actually off due to an external fault condition
[20:47:55] <andypugh> It is indeed that type of pin
[20:47:58] <jepler> (because it's not your driver putting the value on that HAL pin, it's whatever OUT pin is connected to the same signal)
[20:49:03] <jepler> you can decide whether to clear a fault you want to require the HAL enable pin to be driven FALSE and then TRUE (a rising edge) to clear it after the external fault is removed, or whether driving it TRUE when the external fault disappears should be enough..
[20:49:29] <jepler> (I don't think we've had that specific situation before with another driver)
[20:49:50] <andypugh> No, that is exactly what I don't want me, personally, to decide. I want the EMC developers to decide for me.
[20:51:09] <jepler> in a sanely hooked-up emc system (with the fault going to axis.#.amp-fault-in) you will be able to depend on that rising edge the fault is cleared
[20:51:20] <andypugh> Bit if I did have to decide, I think I would go for attempting to enable the PWM if the hal-pin is true, the drive is not faulted and the pwm is currently disabled.
[20:51:59] <jepler> in a sanely hooked-up emc system (with the fault going to axis.#.amp-fault-in) you will be able to depend on that rising edge after the fault is cleared
[20:52:22] <jepler> (amp-fault-in takes you at least to "machine off" so the amp-enable-outs all go FALSE)
[20:52:23] <alex_joni> * alex_joni is seeing double
[20:52:44] <andypugh> No, if you read very carefully, he changed a word
[20:53:31] <jepler> now if only I'd read what andy says as carefully as he reads what I say..
[20:53:32] <andypugh> Does axis-amp-fault-in reset axis-amp-enable?
[20:53:54] <alex_joni> yes, eventually
[20:54:40] <andypugh> In that case I think my proposal covers both sanely and "insanely" wired systems.
[20:55:16] <jepler> if there's a delay of more than one period (between amp-fault-in going TRUE and amp-enable-out going FALSE) that's unintentional and should probably be fixed
[20:55:38] <jepler> there's no good reason for it to be other than instant
[20:56:14] <andypugh> ie the pwmgen (and its enable-out physical pin) will only go back high when the fault is cleared and the hal-enable is high (regardless of whether it has been toggled to false in the interim)
[20:57:34] <andypugh> It won't work for anyone who uses setp 3phase-pwmgen.0.enable = 1 in their hal file, but that serves them right
[20:58:33] <jepler> sounds OK to me. we can revisit the decision later if experience starts to indicate otherwise.
[20:58:56] <andypugh> Supplementary question. I have gone for calling the function tp_pwmgen in the code, and 3phase-pwmgen in the user-facing bits. Does that seem OK?
[20:59:33] <andypugh> (Numerals at the beginning of variable and function names is a no-no I think?)
[21:00:43] <jepler> 3phase-pwmgen is a bit long. have you considered 3pwmgen?
[21:00:49] <jepler> (yes, C identifiers can't begin with a numeral)
[21:01:04] <alex_joni> except roman numerals
[21:01:14] <alex_joni> IIIpwmgen :P
[21:01:26] <andypugh> It was 3ppwmgen until earlier this evening...
[21:01:46] <alex_joni> what about pwmgen-3phase ?
[21:01:57] <alex_joni> or pwmgen-3p ?
[21:02:09] <andypugh> pwmgen3 might work
[21:02:32] <andypugh> pwm3gen?
[21:02:49] <andypugh> (that looks rather l33t )
[21:04:26] <andypugh> And the declaration parameter, currently num_3phase_pwmgens is definitely rather long.
[21:05:36] <andypugh> 3pwmgen works. I will go for that.
[21:08:52] <jepler> alex_joni: you're mistaken about roman numerals, by the way. The unicode characer U+2160 "roman numeral one" is not acceptable at the beginning of an identifier by gcc, even when the c99 "universal identifer" feature is enabled.
[21:09:47] <alex_joni> how about capital i ?
[21:09:54] <jepler> (and yes, I've spent the last 5+ minutes determining that :-P)
[21:09:58] <jepler> alex_joni: what about capital i? That's a letter.
[21:10:05] <jepler> if you think it's also a roman numeral, you're mistaken.
[21:11:06] <alex_joni> Roman numerals are based on seven symbols: a stroke (identified with the letter I) for a unit
[21:12:01] <jepler> you're like the people who think that Σ and ∑ or β and ß are the same
[21:12:04] <jepler> you make me sick
[21:12:33] <jepler> I won't dispute that people often incorrectly "transliterate" Ⅲ as III.
[21:12:48] <alex_joni> "The characters in the range U+2160.217F are present only for compatibility with other character set standards which provide these characters. For ordinary uses, the standard Latin letters are preferred. "
[21:13:36] <alex_joni> from
http://en.wikipedia.org/wiki/Roman_numerals#Unicode
[21:14:13] <jepler> [citation needed]
[21:14:27] <alex_joni> I think cradek said that ;)
[21:19:22] <jepler> unfortunately for me, The Unicode Stnadard, Version 5.2, page 467 agrees with wikipedia
[21:19:58] <jepler> Roman Numerals. For most purposes, it is preferable to compose the Roman numerals from sequences of the appropriate Latin letters. However, the uppercase and lowercase variants of the Roman numerals through 12, plus L, C, D, and M, have been encoded for compatibility with East Asian standards. Unlike sequences of Latin letters, these symbols remain upright in vertical layout.
[21:22:09] <alex_joni> are you home already?
[21:22:10] <jepler> (but personally I'd rather see the roman numeral Ⅲ typeset with a single continuous bar above and below than as III)
[21:22:35] <jepler> home -- from work? no.
[21:22:57] <jepler> about to leave, I think
[21:23:17] <alex_joni> I'd imagine that would be better than reading about unicode roman numerals
[21:23:30] <alex_joni> I doubt any romans will come to check if we use unicode or not
[21:24:50] <jepler> bbl :)