<_whitenotifier>
[nmigen-boards] whitequark closed issue #18: Handle edge case where the same `Subsignal` uses multiple `Connectors` - https://git.io/fjiGK
<mtrbot-ml>
[mattermost] <hartytp> MaxV: this is a user-set (VIA ethernet ideally) safety limit (e.g. limit power dissipation in TEC/heater). If you don't set this then you can't use the TEC
<mtrbot-ml>
[mattermost] <hartytp> (NB all are programmed as voltages between 0V and 3V)
<mtrbot-ml>
[mattermost] <hartytp> - MaxIPos, MaxIneg: these are also user-set safetys.
<mtrbot-ml>
[mattermost] <hartytp> - Iset this is the voltage that actually determines the TEC current. 0V = -3A, 1.5V=0A, 3V=3A (so 2A/V coefficient as we use Rsense = 50mOhm)
<mtrbot-ml>
[mattermost] <hartytp> Iset is the only one that the PID controller drivers
<mtrbot-ml>
[mattermost] <hartytp> drives
<mtrbot-ml>
[mattermost] <hartytp> *however* the user also needs to be able to disable the PID controller and set it to a a fixed value (e.g. for step response measurements)
<mtrbot-ml>
[mattermost] <hartytp> the way I'd normally do this is allow the user to set a specific value to the PID output, and then let the PID module overwrite that if it's active
<mtrbot-ml>
[mattermost] <hartytp> does that make sense?
<mtrbot-ml>
[mattermost] <hartytp> NB for the final version, we'll need to measure Vref with an adc (that's the precise value of the 1.5V) but we can leave that for now
lkcl has quit [Ping timeout: 265 seconds]
<mtrbot-ml>
[mattermost] <astro> that was very enlightening, thank you
<mtrbot-ml>
[mattermost] <astro> currently, there's the `pwm` command to switch off the pid
<mtrbot-ml>
[mattermost] <astro> I'll add ways to configure the `max*` channels
<mtrbot-ml>
[mattermost] <astro> would you like to configure raw pwm intervals (width/total) or should I implement the conversion already?
<_whitenotifier>
[nmigen] whitequark commented on issue #216: Memory port transparency model is flawed - https://git.io/Jesi0
<mtrbot-ml>
[mattermost] <hartytp> Can you implement the conversion please? It's only 1 line of code and it's much nicer for the user
<mtrbot-ml>
[mattermost] <hartytp> NB don't accept values that are outside the TEC driver nominal ranges of 0->3V
<mtrbot-ml>
[mattermost] <hartytp> and def have a quick skim over that page of the datasheet
<mtrbot-ml>
[mattermost] <hartytp> @rjo isn't this moot anyway since the PWM will be gone on the next design rev for the only one that actually matters
<rjo>
an SI units command is fine. but precisely for testing the PWM properties (reconstruction filter, crosstalk), a variable cycle length is what you want. and what's the point in hardcoding the cycle length?
<mtrbot-ml>
[mattermost] <astro> I have pushed pwm abstraction code and am waiting for this decision on the command input format
<mtrbot-ml>
[mattermost] <astro> so please discuss :)
<rjo>
and how meaningful would that calibration be?
<mtrbot-ml>
[mattermost] <hartytp> The TEC driver is decently specified (particularly once offsets are calibrated, which is part of the contract)
<rjo>
then again, if you calibrate the ineg and ipos limits, you'd also want to calibrate the iset scale since the intergrator will evade any anti-windup if you hit those limits.
<mtrbot-ml>
[mattermost] <hartytp> IMO the I/V limits don't need to be particularly accurately set
<rjo>
they do.
<mtrbot-ml>
[mattermost] <hartytp> more than a few %?
<rjo>
you loos that much from your operating range.
<mtrbot-ml>
[mattermost] <hartytp> yes, but it's only a % or so
<mtrbot-ml>
[mattermost] <hartytp> and, anyway, how is that relevant to SI calculations?
<mtrbot-ml>
[mattermost] <hartytp> one way you set a number between 0..1 which is mapped to 0..3V
<mtrbot-ml>
[mattermost] <hartytp> the other way you set a number between -3..+3 which is mapped to 0..3V
<mtrbot-ml>
[mattermost] <hartytp> either way, the microprocessor output is the same
<rjo>
you have to ensure that you stop integrating before you hit the hard limits.
<rjo>
because the range is implicit with SI units while it is explicit with full scale units.
<mtrbot-ml>
[mattermost] <hartytp> well, re integrator wind-up etc, that's still the same whatever your units
<rjo>
the reason to favor SI units would be if those SI units actually mean a lot for the user.
<mtrbot-ml>
[mattermost] <hartytp> and, the only reason to set limits is because you're worried about power dissipation, so you'd want to work in SI units then
<mtrbot-ml>
[mattermost] <hartytp> and, one generally sets the safeties with enough margin that %-level calibration isn't an issue
<rjo>
yes. i was only arguing that when the limits are scaled to SI then iset must also be because of those railing considerations.
<mtrbot-ml>
[mattermost] <hartytp> yes, so scale everything.
<rjo>
then you'll have to decide whether iset will get the safety margin (and will never hit ipos/ineg) or whether ipos/ineg have a margin and iset may exceed them.
<mtrbot-ml>
[mattermost] <hartytp> what margin?
<rjo>
this is not that important. but i'd argue that people won't know/will forget what the range is in SI units.
<rjo>
the margin that i just explained above.
<mtrbot-ml>
[mattermost] <hartytp> "this is not that important. but i'd argue that people won't know/will forget what the range is in SI units." I'd generally deal with this by having the CLI interface/python driver raise a suitable error if the user tries to exceed the valid ranges
<mtrbot-ml>
[mattermost] <hartytp> and have it in the doc strings
<mtrbot-ml>
[mattermost] <hartytp> that seems far less opaque than setting a number between 0..1 and not having an idea what order of magnitude of current is flowing through the TEC and whether it's likely to be safe
<rjo>
and about the power dissipation that's not well known at all and not calibrated, right? so you have very little knowledger about whether it's actually safe.
<mtrbot-ml>
[mattermost] <hartytp> depends on the situation, but for example you know the current rating of your tec/heater
<mtrbot-ml>
[mattermost] <hartytp> I'm not sure I'm following you...in terms of limits etc, the user interface doesn't make any difference. Internally, everything can be expressed in terms of full-scale if that's easier. Just a matter of working in user-friendly units for setting and read-out
<rjo>
i am just saying that the suggestion that the user interface can simply be scaled "correctly" is not the whole story and that it will leave room for misunderstanding.
<mtrbot-ml>
[mattermost] <hartytp> Ok. I'd also be happy with the ethernet interface working only in FS units and having the standard `set_{}` / `set_{}_mu` methods, with a docstring that notes that calibration is not precise