Back
[05:18:02] <morficcell> morficcell is now known as morficmobile
[06:45:07] <ries_> ries_ is now known as ries
[17:34:22] <morfic-> morfic- is now known as morfic
[19:51:57] <ries_> ries_ is now known as ries
[20:04:21] <cradek> SWPadnos: [I haven't been following all that but] if it's a bug it should be fixed
[20:11:36] <andypugh> No sign in the code of setting the velocity to zero when enable goes false. The step_rate_reg register for the FPGA is zeroed, but not the active step rate.
[20:15:17] <andypugh> In fact, the whole velocity calculation is in hm2_stepgen_instance_prepare_tram_write which is skipped if enable is false.
[20:24:24] <jepler> what swp is thinking of is the behavior modified in these two commits (the top one partially reverts the bottom one):
[20:24:28] <jepler> da68626 Don't change hm2 stepgen position when .enable is low
[20:24:30] <jepler> 1f75173 Fix hm2 stepgen.enable=0 behavior
[20:24:44] <jepler> I haven't tried for myself to experience the buggy behavior
[20:25:19] <jepler> > +When True, the stepgen instance works as expected.
[20:25:24] <jepler> hm, that's a slightly unfortunate wording
[20:31:09] <andypugh> I am not sure which version I am looking at. But when disabled it doesn't update position _or_ ramp down the velocity.
[20:31:50] <jepler> the software stepgen behavior is to treat "old velocity" as 0 when enabling, for the purpose of obeying constraints.
[20:31:56] <andypugh> The question is whether enable=false should drop the velocity to zero immediately or respect the ramp.
[20:32:43] <jepler> the software stepgen behavior is to never issue a step when enable is false
[20:32:44] <andypugh> I think immediately makes sense.
[20:33:15] <andypugh> You could ramp the velocity while not making steps. But it would take a lot more sork.
[20:33:19] <andypugh> (work)
[20:35:55] <jepler> steps are never issued when enable=false, and when enable transitions from false to true the old velocity (for the purposes of imposing velocity and acceleration limits) is taken as 0
[20:36:08] <jepler> I am trying to avoid saying that the velocity has any particular value while enable is false
[20:38:05] <andypugh> In the hostmot driver there isn't any detection of enable going true, it just stops being suppressed by it being false.
[20:38:33] <jepler> sorry, I'm talking about what stepgen should do (and what my memory says software stepgen does without looking at the code), not what hostmot2 does.
[20:38:47] <andypugh> The "enable" variable is only used once, at line 286
[20:39:41] <andypugh> I understand what you are saying. I am trying to figure out what the fix is for the Hostmot2 version
[20:41:24] <andypugh> (No, I don't know why I am doing that. I will crawl back under my rock)
[20:43:51] <jepler> I haven't tested it, but I expect the combined 1f75173+da68626 eliminates the undesired motion just after reenabling.. afaik that's what seb set out to fix, I just objected to the part that involved playing with position-cmd
[20:44:31] <jepler> please don't.
[20:45:16] <jepler> (er, maybe I meant playing with position-fb)
[20:47:41] <SWPadnos> sorry - was on the phone
[20:48:07] <SWPadnos> I don't know if the two commits referenced fix the problem in velocity mode, they were intended to fix abrupt motion after enable in position mode
[20:48:29] <jepler> the commits I'm talking about are not in 2.4.0. they're on master.
[20:48:48] <SWPadnos> sure, so grommit wouldn't have them anyway
[20:48:53] <jepler> after testing I'd be pleased to see them cherry-picked back to v2.4_branch *hint* *hint*
[20:50:08] <SWPadnos> I absolutely hate responding to emails that were sent with outlook
[20:50:36] <SWPadnos> hey, those are simple commits for me to practice on, aren't they :)
[20:52:31] <SWPadnos> oh, in other news, I'm sure that I won't be able to be at CNC workshop for very long, if at all
[20:52:41] <SWPadnos> I need to go to LA on the 24th or 25th
[20:52:46] <jepler> shoot.
[20:52:53] <SWPadnos> yeah, it is a bummer
[20:53:21] <SWPadnos> I may be able to be there for the first couple of days though
[20:53:23] <cradek> arg
[20:54:50] <andypugh> Looking at the diffs, they should fix the problem being discussed.
[20:55:14] <andypugh> And talking of diffs, when might I expect a decision on my 3pwm and led patches?
[20:55:51] <jepler> I haven't taken a serious look at the second iteration yet
[20:56:15] <jepler> are you using 3pwm yourself?
[20:57:00] <andypugh> Not yet, I am practicing with a microcontroller, then need to write a HAL comp to do the phase calculations (probably this weekend)
[20:57:47] <jepler> are the calculations different than clarke2/clarke3/clarkeinv?
[20:58:35] <andypugh> A bit.
[20:59:23] <andypugh> They include those transforms, but there needs to be an input for the encoder, an encoder offset, possibly an alignment phase in setup and maybe even a seperate component for hall-sensor motors.
[20:59:40] <jepler> glancing at your may 7 version of 3pwm I see there are still indentation anomalies
[20:59:40] <SWPadnos> they should (just) be sin(angle), sin(angle+120), and sin(angle-120)
[20:59:43] <jepler> hm2_ioport_gpio_process_tram_read(hm2);
[20:59:46] <jepler> + hm2_tp_pwmgen_read(hm2); // check the status of the fault bit
[20:59:48] <SWPadnos> with angle changing based on a velocity input
[20:59:48] <jepler> hm2_encoder_process_tram_read(hm2, period);
[21:04:44] <andypugh> Argh! I spent ages messing with tab stops and search-and replace. Where the hell have those crept back in from?
[21:07:59] <jepler> 3pwm has its own master rate dds separate from tradition pwm?
[21:08:44] <JT-Work> andypugh: seb
[21:08:48] <jepler> OK, I see it does
[21:08:49] <andypugh> It's a different register on the FPGA, yes.
[21:09:02] <jepler> we should copy the regmap from hostmot2-firmware to emc, it looks like it's newer
[21:14:02] <andypugh> SWPadnos: I think we need a Park transform too, and there is no sin and cos in HAL, so it seems sensible to wrap it all up into one comp rather than wire 4 or 5 different things together in HAL.
[21:14:27] <SWPadnos> what makes you think there's no SIN or COS in HAL?
[21:14:36] <jepler> andypugh: in general it looks like good code
[21:14:42] <SWPadnos> remember that siggen and the motion controller are also HAL components ...
[21:15:08] <jepler> SWPadnos: I think andypugh means there's not a dedicated component for computing sin(theta) onto a hal pin
[21:15:24] <SWPadnos> but I wasn't suggesting wiring trig functions together in HAL, just pointing out (incorrectly) that it should be really simple to write :)
[21:16:28] <jepler> andypugh: I think in general the code looks fine. if I don't test LED over the weekend, give me a kick in the teeth .. I mean, a gentle reminder to do it
[21:16:29] <andypugh> Ah, yes. I, too, am assuming that it will be easy to write, otherwise I wouldn't be thinking of doing it.
[21:17:23] <andypugh> The LED has been tested by me on 7i43 and by Dave911 on 5i20.
[21:17:41] <jepler> OK, that's good to know
[21:17:58] <andypugh> There is a problem that I diffed inexpertly and the led patch won't take without the 3pwmgen one.
[21:18:06] <jepler> is there just one LED?
[21:18:21] <jepler> that's not unusual .. I am sure they modify "nearby" code in a number of places
[21:18:35] <jepler> have you been able to test that the enable/fault logic works in a sensible way?
[21:18:46] <andypugh> One physical LED you mean?
[21:19:06] <jepler> one software-controllable LED
[21:19:14] <jepler> it looks like that's what the PIN file specifies for 5i20 anyway
[21:19:36] <andypugh> No, there are generally 8, but all controlled by one register.
[21:20:16] <jepler> oh
[21:20:27] <jepler> I saw "count" as 1 and jumped to conclusions
[21:20:28] <andypugh> Yes, the fault-enable works sensibly now, whilst accepting that there are other, alternative, equally sensible ways to work.
[21:20:29] <SWPadnos> one LED "module", with 8 lights
[21:21:16] <andypugh> Some boards have 4, I went through all the manuals to get the count right for the boards I think that EMC tries to drive.
[21:21:38] <jepler> hmm .. unfortunate if that knowledge isn't embedded in the idrom :(
[21:22:54] <andypugh> It might be, but the LEDs weren't documented at all in the regmap file, so I was guessing.
[21:24:29] <andypugh> At the moment it should get the right number for 7i43, 5i20, 5i22, 5i23, 4i65, 4i68 and 3X20. If anyone is using any of the last 4 I have never heard them mention it.
[21:24:42] <jepler> here's what the vhdl files say:
http://pastebin.com/EBEi3LXK
[21:24:52] <jepler> i23 has 2, i68 has 4, x20 has 1, others have 8
[21:25:56] <andypugh> I gave up on the 3x20 single led, it looked more difficult.
[21:26:50] <jepler> hmmmm I have a suspicion you can write the LED register as all 0s, then read back -- where you get 0s there's an LED, where you don't there's not. but I can't test that at the moment.
[21:27:28] <jepler> what's more difficult about supporting a single LED?
[21:28:40] <andypugh> The manual describes it as a TxRx (or something) one that can be user-accessed if required. Without the hardware I didn't want to assume that it was addressed the same way, nor did I want to assume that it was the MSb of the register.
[21:29:29] <andypugh> And most of the FPGA registers are read-only or write-only, though it isn't hard to test it.
[21:35:40] <jepler> hm -- and if I'm tickling the right register with the raw interface, I'm wrong about the method I suggested for determinig the led count
[21:36:11] <andypugh> It's not working for me either :-)
[21:36:16] <andypugh> 0x200?
[21:37:16] <andypugh> If you write F0000000 then the LEDs will come on if you have the right register.
[21:37:48] <andypugh> (and no doubt shine brightly in an opaque box?)
[21:37:53] <jepler> yes
[21:38:01] <jepler> well, I'm not even in the same building as my 5i20
[21:38:19] <andypugh> Snap, with my 7i43.
[21:38:30] <andypugh> isn't VNC marvellous?
[21:38:51] <jepler> http://pastebin.com/GELfPrXD
[21:40:13] <andypugh> Looks the same as mine. I lost 3 days assuming that my driver was wrong until I realised that write-only registers existed.
[21:41:39] <jepler> don't feel bad -- I looked at the vhdl source and thought it was an example of a read/write register
[21:42:28] <jepler> bbl, time to get out of the office