morficcell is now known as morficmobile
ries_ is now known as ries
morfic- is now known as morfic
ries_ is now known as ries
SWPadnos: [I haven't been following all that but] if it's a bug it should be fixed
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.
In fact, the whole velocity calculation is in hm2_stepgen_instance_prepare_tram_write which is skipped if enable is false.
what swp is thinking of is the behavior modified in these two commits (the top one partially reverts the bottom one):
da68626 Don't change hm2 stepgen position when .enable is low
1f75173 Fix hm2 stepgen.enable=0 behavior
I haven't tried for myself to experience the buggy behavior
> +When True, the stepgen instance works as expected.
hm, that's a slightly unfortunate wording
I am not sure which version I am looking at. But when disabled it doesn't update position _or_ ramp down the velocity.
the software stepgen behavior is to treat "old velocity" as 0 when enabling, for the purpose of obeying constraints.
The question is whether enable=false should drop the velocity to zero immediately or respect the ramp.
the software stepgen behavior is to never issue a step when enable is false
I think immediately makes sense.
You could ramp the velocity while not making steps. But it would take a lot more sork.
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
I am trying to avoid saying that the velocity has any particular value while enable is false
In the hostmot driver there isn't any detection of enable going true, it just stops being suppressed by it being false.
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.
The "enable" variable is only used once, at line 286
I understand what you are saying. I am trying to figure out what the fix is for the Hostmot2 version
(No, I don't know why I am doing that. I will crawl back under my rock)
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
(er, maybe I meant playing with position-fb)
sorry - was on the phone
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
the commits I'm talking about are not in 2.4.0. they're on master.
sure, so grommit wouldn't have them anyway
after testing I'd be pleased to see them cherry-picked back to v2.4_branch *hint* *hint*
I absolutely hate responding to emails that were sent with outlook
hey, those are simple commits for me to practice on, aren't they :)
oh, in other news, I'm sure that I won't be able to be at CNC workshop for very long, if at all
I need to go to LA on the 24th or 25th
yeah, it is a bummer
I may be able to be there for the first couple of days though
Looking at the diffs, they should fix the problem being discussed.
And talking of diffs, when might I expect a decision on my 3pwm and led patches?
I haven't taken a serious look at the second iteration yet
are you using 3pwm yourself?
Not yet, I am practicing with a microcontroller, then need to write a HAL comp to do the phase calculations (probably this weekend)
are the calculations different than clarke2/clarke3/clarkeinv?
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.
glancing at your may 7 version of 3pwm I see there are still indentation anomalies
they should (just) be sin(angle), sin(angle+120), and sin(angle-120)
+ hm2_tp_pwmgen_read(hm2); // check the status of the fault bit
with angle changing based on a velocity input
Argh! I spent ages messing with tab stops and search-and replace. Where the hell have those crept back in from?
3pwm has its own master rate dds separate from tradition pwm?
OK, I see it does
It's a different register on the FPGA, yes.
we should copy the regmap from hostmot2-firmware to emc, it looks like it's newer
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.
what makes you think there's no SIN or COS in HAL?
andypugh: in general it looks like good code
remember that siggen and the motion controller are also HAL components ...
SWPadnos: I think andypugh means there's not a dedicated component for computing sin(theta) onto a hal pin
but I wasn't suggesting wiring trig functions together in HAL, just pointing out (incorrectly) that it should be really simple to write :)
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
Ah, yes. I, too, am assuming that it will be easy to write, otherwise I wouldn't be thinking of doing it.
The LED has been tested by me on 7i43 and by Dave911 on 5i20.
OK, that's good to know
There is a problem that I diffed inexpertly and the led patch won't take without the 3pwmgen one.
is there just one LED?
that's not unusual .. I am sure they modify "nearby" code in a number of places
have you been able to test that the enable/fault logic works in a sensible way?
One physical LED you mean?
one software-controllable LED
it looks like that's what the PIN file specifies for 5i20 anyway
No, there are generally 8, but all controlled by one register.
I saw "count" as 1 and jumped to conclusions
Yes, the fault-enable works sensibly now, whilst accepting that there are other, alternative, equally sensible ways to work.
one LED "module", with 8 lights
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.
hmm .. unfortunate if that knowledge isn't embedded in the idrom :(
It might be, but the LEDs weren't documented at all in the regmap file, so I was guessing.
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.
here's what the vhdl files say: http://pastebin.com/EBEi3LXK
i23 has 2, i68 has 4, x20 has 1, others have 8
I gave up on the 3x20 single led, it looked more difficult.
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.
what's more difficult about supporting a single LED?
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.
And most of the FPGA registers are read-only or write-only, though it isn't hard to test it.
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
It's not working for me either :-)
If you write F0000000 then the LEDs will come on if you have the right register.
(and no doubt shine brightly in an opaque box?)
well, I'm not even in the same building as my 5i20
Snap, with my 7i43.
isn't VNC marvellous?
[21:38:51] <jepler> http://pastebin.com/GELfPrXD
Looks the same as mine. I lost 3 days assuming that my driver was wrong until I realised that write-only registers existed.
don't feel bad -- I looked at the vhdl source and thought it was an example of a read/write register
bbl, time to get out of the office