* pid control configuration @ 2019-05-01 22:53 Vijay Khemka 2019-05-01 23:05 ` Ed Tanous 0 siblings, 1 reply; 17+ messages in thread From: Vijay Khemka @ 2019-05-01 22:53 UTC (permalink / raw) To: Patrick Venture, James Feist; +Cc: openbmc @ lists . ozlabs . org [-- Attachment #1: Type: text/plain, Size: 789 bytes --] Hi Patrick/James, I am not understanding how to get these following data for configuration file for pid. I only had p(proportional), i(integral) and d(differential) values from my thermal team. But unable to maop these to required parameter. "required": [ "Class", "FFGainCoefficient", "FFOffCoefficient", "ICoefficient", "ILimitMax", "ILimitMin", "Inputs", "Name", "OutLimitMax", "OutLimitMin", "PCoefficient", "SlewNeg", "SlewPos", "Type", "Zones" ] Also we have a requirement of stepwise and pid together for some sensors, is it possible to configure same sensor for both types. Regards -Vijay [-- Attachment #2: Type: text/html, Size: 5221 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: pid control configuration 2019-05-01 22:53 pid control configuration Vijay Khemka @ 2019-05-01 23:05 ` Ed Tanous 2019-05-01 23:10 ` Patrick Venture 2019-05-02 23:24 ` Vijay Khemka 0 siblings, 2 replies; 17+ messages in thread From: Ed Tanous @ 2019-05-01 23:05 UTC (permalink / raw) To: openbmc On 5/1/19 3:53 PM, Vijay Khemka wrote: > Hi Patrick/James, > > I am not understanding how to get these following data for configuration > file for pid. I only had p(proportional), i(integral) and > d(differential) values from my thermal team. But unable to maop these to > required parameter. > > > > "required": [ > > "Class", This will be PIDController in the case of PID, and is part of how entity manager divides up the config information to the various components. > > "FFGainCoefficient", > > "FFOffCoefficient", In your case, both of these FF variables would be 0.0 > > "ICoefficient", Would be the I value from your thermal team. > > "ILimitMax", > > "ILimitMin", These sets the limits to the integral coefficient to prevent integral runaway in the case where the controller cannot ever reach the target temperature. If you don't want to use these at all (which I wouldn't recommend from a control perspective) you can set them to unreasonably large and unreasonably small values, and they will have no effect. > > "Inputs", The sensors you want to control, by name. > > "Name", This is the "pretty" name for this controller, and can be whatever you want. The controller will show up in DBus and Redfish under this name. > > "OutLimitMax", > > "OutLimitMin", > I believe both of these are in % of fan speed these days, so setting them to 100 and 0% respectively will probably give you the behavior you want if you don't have other data from your thermal team around limits. > "PCoefficient", Your P value from your thermal team. > > "SlewNeg", > > "SlewPos", These two reflect the D values from your thermal team. If they only gave you one D value, there are two things here. 1. It could use the same coefficients for both positive and negative derivative values. Or 2. It only applies to Positive slew rates, and negative is zero. You would need to talk to your team to understand what they intended. > > "Type", The Entity manager type, which I believe it PIDController, but I don't have the examples in front of me. > > "Zones" Fan zones in which this controller applies to. For Tioga pass I would expect you to only have a single fan zone for the whole node. > > ] > > > > > > Also we have a requirement of stepwise and pid together for some > sensors, is it possible to configure same sensor for both types.Yes, you can declare multiple controllers. Whichever controller requests the high fan speed will be the one that's used for the PWM output. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: pid control configuration 2019-05-01 23:05 ` Ed Tanous @ 2019-05-01 23:10 ` Patrick Venture 2019-05-01 23:15 ` Patrick Venture 2019-05-02 23:24 ` Vijay Khemka 1 sibling, 1 reply; 17+ messages in thread From: Patrick Venture @ 2019-05-01 23:10 UTC (permalink / raw) To: Ed Tanous; +Cc: OpenBMC Maillist On Wed, May 1, 2019 at 4:05 PM Ed Tanous <ed.tanous@intel.com> wrote: > > On 5/1/19 3:53 PM, Vijay Khemka wrote: > > Hi Patrick/James, > > > > I am not understanding how to get these following data for configuration > > file for pid. I only had p(proportional), i(integral) and > > d(differential) values from my thermal team. But unable to maop these to > > required parameter. > > > > > > > > "required": [ > > > > "Class", > This will be PIDController in the case of PID, and is part of how entity > manager divides up the config information to the various components. > > > > "FFGainCoefficient", > > > > "FFOffCoefficient", > In your case, both of these FF variables would be 0.0 > > > > "ICoefficient", > Would be the I value from your thermal team. > > > > > "ILimitMax", > > > > "ILimitMin", > > These sets the limits to the integral coefficient to prevent integral > runaway in the case where the controller cannot ever reach the target > temperature. If you don't want to use these at all (which I wouldn't > recommend from a control perspective) you can set them to unreasonably > large and unreasonably small values, and they will have no effect. > > > > > "Inputs", > > The sensors you want to control, by name. > > > > > "Name", > This is the "pretty" name for this controller, and can be whatever you > want. The controller will show up in DBus and Redfish under this name. > > > > > "OutLimitMax", > > > > "OutLimitMin", > > > > I believe both of these are in % of fan speed these days, so setting > them to 100 and 0% respectively will probably give you the behavior you > want if you don't have other data from your thermal team around limits. > > > "PCoefficient", > Your P value from your thermal team. > > > > > "SlewNeg", > > > > "SlewPos", > > These two reflect the D values from your thermal team. If they only > gave you one D value, there are two things here. 1. It could use the > same coefficients for both positive and negative derivative values. Or > 2. It only applies to Positive slew rates, and negative is zero. You > would need to talk to your team to understand what they intended. > > > > > "Type", > The Entity manager type, which I believe it PIDController, but I don't > have the examples in front of me. > > > > > "Zones" > Fan zones in which this controller applies to. For Tioga pass I would > expect you to only have a single fan zone for the whole node. > > > > > ] > > > > > > > > > > > > Also we have a requirement of stepwise and pid together for some > > sensors, is it possible to configure same sensor for both types.Yes, you can declare multiple controllers. Whichever controller > requests the high fan speed will be the one that's used for the PWM output. Thanks Ed for those great answers. I'll provide the units answer: If the PID is a margin controller and it's set-point is in centigrade and output in RPM: pCoefficient is your p value in units: RPM/C and integral coefficient RPM/Csec If the PID is a fan controller whose output is pwm: pCoefficient is %/RPM and iCoefficient is %/RPM sec ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: pid control configuration 2019-05-01 23:10 ` Patrick Venture @ 2019-05-01 23:15 ` Patrick Venture 0 siblings, 0 replies; 17+ messages in thread From: Patrick Venture @ 2019-05-01 23:15 UTC (permalink / raw) To: Ed Tanous; +Cc: OpenBMC Maillist On Wed, May 1, 2019 at 4:10 PM Patrick Venture <venture@google.com> wrote: > > On Wed, May 1, 2019 at 4:05 PM Ed Tanous <ed.tanous@intel.com> wrote: > > > > On 5/1/19 3:53 PM, Vijay Khemka wrote: > > > Hi Patrick/James, > > > > > > I am not understanding how to get these following data for configuration > > > file for pid. I only had p(proportional), i(integral) and > > > d(differential) values from my thermal team. But unable to maop these to > > > required parameter. > > > > > > > > > > > > "required": [ > > > > > > "Class", > > This will be PIDController in the case of PID, and is part of how entity > > manager divides up the config information to the various components. > > > > > > "FFGainCoefficient", > > > > > > "FFOffCoefficient", > > In your case, both of these FF variables would be 0.0 > > > > > > "ICoefficient", > > Would be the I value from your thermal team. > > > > > > > > "ILimitMax", > > > > > > "ILimitMin", > > > > These sets the limits to the integral coefficient to prevent integral > > runaway in the case where the controller cannot ever reach the target > > temperature. If you don't want to use these at all (which I wouldn't > > recommend from a control perspective) you can set them to unreasonably > > large and unreasonably small values, and they will have no effect. > > > > > > > > "Inputs", > > > > The sensors you want to control, by name. > > > > > > > > "Name", > > This is the "pretty" name for this controller, and can be whatever you > > want. The controller will show up in DBus and Redfish under this name. > > > > > > > > "OutLimitMax", > > > > > > "OutLimitMin", > > > > > > > I believe both of these are in % of fan speed these days, so setting > > them to 100 and 0% respectively will probably give you the behavior you > > want if you don't have other data from your thermal team around limits. > > > > > "PCoefficient", > > Your P value from your thermal team. > > > > > > > > "SlewNeg", > > > > > > "SlewPos", > > > > These two reflect the D values from your thermal team. If they only > > gave you one D value, there are two things here. 1. It could use the > > same coefficients for both positive and negative derivative values. Or > > 2. It only applies to Positive slew rates, and negative is zero. You > > would need to talk to your team to understand what they intended. > > > > > > > > "Type", > > The Entity manager type, which I believe it PIDController, but I don't > > have the examples in front of me. > > > > > > > > "Zones" > > Fan zones in which this controller applies to. For Tioga pass I would > > expect you to only have a single fan zone for the whole node. > > > > > > > > ] > > > > > > > > > > > > > > > > > > Also we have a requirement of stepwise and pid together for some > > > sensors, is it possible to configure same sensor for both types.Yes, you can declare multiple controllers. Whichever controller > > requests the high fan speed will be the one that's used for the PWM output. > > Thanks Ed for those great answers. > > > I'll provide the units answer: > > If the PID is a margin controller and it's set-point is in centigrade > and output in RPM: > pCoefficient is your p value in units: RPM/C and integral coefficient RPM/Csec > > If the PID is a fan controller whose output is pwm: > pCoefficient is %/RPM and iCoefficient is %/RPM sec The non-step PID operates at a 10x frequency fans : sensors. so it tries to control the fans 10x per second, and checks the status of the thermal sensors involved once every second. that's hard-coded presently in the behavior of the code. I think the step-wise operates similarly but I would have to check. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: pid control configuration 2019-05-01 23:05 ` Ed Tanous 2019-05-01 23:10 ` Patrick Venture @ 2019-05-02 23:24 ` Vijay Khemka 2019-05-06 16:20 ` Ed Tanous 1 sibling, 1 reply; 17+ messages in thread From: Vijay Khemka @ 2019-05-02 23:24 UTC (permalink / raw) To: Ed Tanous, openbmc Hi Ed, Thanks for detailed definition of each parameter, it really helps. I have a follow up question from R100 Chassis.json in entity manager where "fan" class is also defined as pid controller. I don't think we have any pid data for fans, we only have pid data for temperature sensors. My understanding here is pid data are only defined for temp sensors which will generate pwm values for fan. I might be missing something here, please clarify. Regards -Vijay On 5/1/19, 4:06 PM, "openbmc on behalf of Ed Tanous" <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of ed.tanous@intel.com> wrote: On 5/1/19 3:53 PM, Vijay Khemka wrote: > Hi Patrick/James, > > I am not understanding how to get these following data for configuration > file for pid. I only had p(proportional), i(integral) and > d(differential) values from my thermal team. But unable to maop these to > required parameter. > > > > "required": [ > > "Class", This will be PIDController in the case of PID, and is part of how entity manager divides up the config information to the various components. > > "FFGainCoefficient", > > "FFOffCoefficient", In your case, both of these FF variables would be 0.0 > > "ICoefficient", Would be the I value from your thermal team. > > "ILimitMax", > > "ILimitMin", These sets the limits to the integral coefficient to prevent integral runaway in the case where the controller cannot ever reach the target temperature. If you don't want to use these at all (which I wouldn't recommend from a control perspective) you can set them to unreasonably large and unreasonably small values, and they will have no effect. > > "Inputs", The sensors you want to control, by name. > > "Name", This is the "pretty" name for this controller, and can be whatever you want. The controller will show up in DBus and Redfish under this name. > > "OutLimitMax", > > "OutLimitMin", > I believe both of these are in % of fan speed these days, so setting them to 100 and 0% respectively will probably give you the behavior you want if you don't have other data from your thermal team around limits. > "PCoefficient", Your P value from your thermal team. > > "SlewNeg", > > "SlewPos", These two reflect the D values from your thermal team. If they only gave you one D value, there are two things here. 1. It could use the same coefficients for both positive and negative derivative values. Or 2. It only applies to Positive slew rates, and negative is zero. You would need to talk to your team to understand what they intended. > > "Type", The Entity manager type, which I believe it PIDController, but I don't have the examples in front of me. > > "Zones" Fan zones in which this controller applies to. For Tioga pass I would expect you to only have a single fan zone for the whole node. > > ] > > > > > > Also we have a requirement of stepwise and pid together for some > sensors, is it possible to configure same sensor for both types.Yes, you can declare multiple controllers. Whichever controller requests the high fan speed will be the one that's used for the PWM output. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: pid control configuration 2019-05-02 23:24 ` Vijay Khemka @ 2019-05-06 16:20 ` Ed Tanous 2019-05-06 18:18 ` Vijay Khemka 2019-05-10 21:20 ` Vijay Khemka 0 siblings, 2 replies; 17+ messages in thread From: Ed Tanous @ 2019-05-06 16:20 UTC (permalink / raw) To: Vijay Khemka, openbmc On 5/2/19 4:24 PM, Vijay Khemka wrote: > My understanding here is pid data are only defined for temp sensors which will generate pwm values for fan. > The above is not how phosphor pid control operates. The temperature controllers "request" a given fan RPM, then the fan PID controller (which is scanned much more quickly than the temperature controllers) attempts to drive the fan to that speed. This ends up being a two stage feedback loop that can perform better than a single PID loop. In control theory, this is called a "Cascade" control scheme https://en.wikipedia.org/wiki/PID_controller#Cascade_control -Ed ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: pid control configuration 2019-05-06 16:20 ` Ed Tanous @ 2019-05-06 18:18 ` Vijay Khemka 2019-05-06 18:54 ` Ed Tanous 2019-05-10 21:20 ` Vijay Khemka 1 sibling, 1 reply; 17+ messages in thread From: Vijay Khemka @ 2019-05-06 18:18 UTC (permalink / raw) To: Ed Tanous, openbmc On 5/6/19, 9:20 AM, "Ed Tanous" <ed.tanous@intel.com> wrote: On 5/2/19 4:24 PM, Vijay Khemka wrote: > My understanding here is pid data are only defined for temp sensors which will generate pwm values for fan. > The above is not how phosphor pid control operates. The temperature controllers "request" a given fan RPM, then the fan PID controller (which is scanned much more quickly than the temperature controllers) attempts to drive the fan to that speed. This ends up being a two stage feedback loop that can perform better than a single PID loop. Where would I get data for Fan pid whatever data we get from thermal team are Only for temperature pids. In control theory, this is called a "Cascade" control scheme https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_PID-5Fcontroller-23Cascade-5Fcontrol&d=DwICaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=gRrQtSejyIRsjuPS0GfqwX6bOmjSCOqs7BU5oina6oM&s=o56OqsqtJgiAeHSyp3Zd4yb8oFO8lzH-DIYsokTyc48&e= Thanks for this. -Ed ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: pid control configuration 2019-05-06 18:18 ` Vijay Khemka @ 2019-05-06 18:54 ` Ed Tanous 0 siblings, 0 replies; 17+ messages in thread From: Ed Tanous @ 2019-05-06 18:54 UTC (permalink / raw) To: Vijay Khemka, openbmc On 5/6/19 11:18 AM, Vijay Khemka wrote: > > Where would I get data for Fan pid whatever data we get from thermal team are > Only for temperature pids. I'm not really sure who you're asking, as that's more of a Facebook organizational question than an engineering one. I would assume the thermal team needs to give you new parameters based on the different controller model. You could likely approximate them by assuming a linear response of the fans and backing out the math from PWM units into RPM units, but this would be an approximation. Depending on the required performance and predictability needed out of your thermal scheme, this approximation might be "good enough". ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: pid control configuration 2019-05-06 16:20 ` Ed Tanous 2019-05-06 18:18 ` Vijay Khemka @ 2019-05-10 21:20 ` Vijay Khemka 2019-05-13 16:32 ` Patrick Venture 1 sibling, 1 reply; 17+ messages in thread From: Vijay Khemka @ 2019-05-10 21:20 UTC (permalink / raw) To: Ed Tanous, openbmc On 5/6/19, 9:20 AM, "Ed Tanous" <ed.tanous@intel.com> wrote: On 5/2/19 4:24 PM, Vijay Khemka wrote: > My understanding here is pid data are only defined for temp sensors which will generate pwm values for fan. > The above is not how phosphor pid control operates. The temperature controllers "request" a given fan RPM, then the fan PID controller (which is scanned much more quickly than the temperature controllers) attempts to drive the fan to that speed. This ends up being a two stage feedback loop that can perform better than a single PID loop. Ed, we are not using cascade control here in facebook. We only use outer loop which gives data for fan to drive. Is it possible to still run Phosphor pid controller with single loop? Regards -Vijay ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: pid control configuration 2019-05-10 21:20 ` Vijay Khemka @ 2019-05-13 16:32 ` Patrick Venture 2019-05-13 17:32 ` Ed Tanous 0 siblings, 1 reply; 17+ messages in thread From: Patrick Venture @ 2019-05-13 16:32 UTC (permalink / raw) To: Vijay Khemka; +Cc: Ed Tanous, openbmc On Fri, May 10, 2019 at 2:21 PM Vijay Khemka <vijaykhemka@fb.com> wrote: > > > > On 5/6/19, 9:20 AM, "Ed Tanous" <ed.tanous@intel.com> wrote: > > On 5/2/19 4:24 PM, Vijay Khemka wrote: > > My understanding here is pid data are only defined for temp sensors which will generate pwm values for fan. > > > > The above is not how phosphor pid control operates. The temperature > controllers "request" a given fan RPM, then the fan PID controller > (which is scanned much more quickly than the temperature controllers) > attempts to drive the fan to that speed. This ends up being a two stage > feedback loop that can perform better than a single PID loop. > > Ed, we are not using cascade control here in facebook. We only use outer loop which gives data for fan to drive. > Is it possible to still run Phosphor pid controller with single loop? Your cascade PID could be a pass-through -- so that it receives the set-point from the sensor PID and then just sets it directly within that loop.. It may require a new PID controller that is just a pass-through to explicitly exist -- i haven't dove into phosphor-pid-control in a while, but you probably need to write a basically empty PID controller object type. > > Regards > -Vijay > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: pid control configuration 2019-05-13 16:32 ` Patrick Venture @ 2019-05-13 17:32 ` Ed Tanous 2019-05-15 19:21 ` Vijay Khemka 0 siblings, 1 reply; 17+ messages in thread From: Ed Tanous @ 2019-05-13 17:32 UTC (permalink / raw) To: Patrick Venture, Vijay Khemka; +Cc: openbmc On 5/13/19 9:32 AM, Patrick Venture wrote: > On Fri, May 10, 2019 at 2:21 PM Vijay Khemka <vijaykhemka@fb.com> wrote: >> >> >> >> On 5/6/19, 9:20 AM, "Ed Tanous" <ed.tanous@intel.com> wrote: >> >> On 5/2/19 4:24 PM, Vijay Khemka wrote: >> > My understanding here is pid data are only defined for temp sensors which will generate pwm values for fan. >> > >> >> The above is not how phosphor pid control operates. The temperature >> controllers "request" a given fan RPM, then the fan PID controller >> (which is scanned much more quickly than the temperature controllers) >> attempts to drive the fan to that speed. This ends up being a two stage >> feedback loop that can perform better than a single PID loop. >> >> Ed, we are not using cascade control here in facebook. We only use outer loop which gives data for fan to drive. >> Is it possible to still run Phosphor pid controller with single loop? > > Your cascade PID could be a pass-through -- so that it receives the > set-point from the sensor PID and then just sets it directly within > that loop.. It may require a new PID controller that is just a > pass-through to explicitly exist -- i haven't dove into > phosphor-pid-control in a while, but you probably need to write a > basically empty PID controller object type. > +1 That is an option for you. >> >> Regards >> -Vijay >> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: pid control configuration 2019-05-13 17:32 ` Ed Tanous @ 2019-05-15 19:21 ` Vijay Khemka 2019-05-15 21:50 ` Ed Tanous 0 siblings, 1 reply; 17+ messages in thread From: Vijay Khemka @ 2019-05-15 19:21 UTC (permalink / raw) To: Ed Tanous, Patrick Venture; +Cc: openbmc On 5/13/19, 10:32 AM, "Ed Tanous" <ed.tanous@intel.com> wrote: On 5/13/19 9:32 AM, Patrick Venture wrote: > On Fri, May 10, 2019 at 2:21 PM Vijay Khemka <vijaykhemka@fb.com> wrote: >> >> >> >> On 5/6/19, 9:20 AM, "Ed Tanous" <ed.tanous@intel.com> wrote: >> >> On 5/2/19 4:24 PM, Vijay Khemka wrote: >> > My understanding here is pid data are only defined for temp sensors which will generate pwm values for fan. >> > >> >> The above is not how phosphor pid control operates. The temperature >> controllers "request" a given fan RPM, then the fan PID controller >> (which is scanned much more quickly than the temperature controllers) >> attempts to drive the fan to that speed. This ends up being a two stage >> feedback loop that can perform better than a single PID loop. >> >> Ed, we are not using cascade control here in facebook. We only use outer loop which gives data for fan to drive. >> Is it possible to still run Phosphor pid controller with single loop? > > Your cascade PID could be a pass-through -- so that it receives the > set-point from the sensor PID and then just sets it directly within > that loop.. It may require a new PID controller that is just a > pass-through to explicitly exist -- i haven't dove into > phosphor-pid-control in a while, but you probably need to write a > basically empty PID controller object type. > +1 That is an option for you. Ed, please see if following declaration in entity manager would work as I am not defining any pid values here. { "Class": "fan", "Inputs": [ "MB_FAN0_TACH" ], "Name": "MB_FAN0_TACH", "Outputs": [ "Pwm 1" ], "Type": "Pid", "Zones": [ "Pid 1" ] }, >> >> Regards >> -Vijay >> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: pid control configuration 2019-05-15 19:21 ` Vijay Khemka @ 2019-05-15 21:50 ` Ed Tanous 2019-05-16 0:07 ` Vijay Khemka 2019-05-31 21:00 ` Vijay Khemka 0 siblings, 2 replies; 17+ messages in thread From: Ed Tanous @ 2019-05-15 21:50 UTC (permalink / raw) To: Vijay Khemka, Patrick Venture; +Cc: openbmc On 5/15/19 12:21 PM, Vijay Khemka wrote: > > > Ed, please see if following declaration in entity manager would work as I am not defining any pid values here. > { > "Class": "fan", > "Inputs": [ > "MB_FAN0_TACH" > ], > "Name": "MB_FAN0_TACH", > "Outputs": [ > "Pwm 1" > ], > "Type": "Pid", > "Zones": [ > "Pid 1" > ] > }, > > >> > >> Regards > >> -Vijay > >> > > I'm assuming you loaded this on a system. If it gave you the behavior you're looking for, you're done. If it didn't, it's probably time to start debugging and tuning. I run my systems in the cascade controller setup. If you're deviating from that, you'll likely find some places that need better documentation and code improvements. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: pid control configuration 2019-05-15 21:50 ` Ed Tanous @ 2019-05-16 0:07 ` Vijay Khemka 2019-05-31 21:00 ` Vijay Khemka 1 sibling, 0 replies; 17+ messages in thread From: Vijay Khemka @ 2019-05-16 0:07 UTC (permalink / raw) To: Ed Tanous, Patrick Venture; +Cc: openbmc On 5/15/19, 2:50 PM, "Ed Tanous" <ed.tanous@intel.com> wrote: On 5/15/19 12:21 PM, Vijay Khemka wrote: > > > Ed, please see if following declaration in entity manager would work as I am not defining any pid values here. > { > "Class": "fan", > "Inputs": [ > "MB_FAN0_TACH" > ], > "Name": "MB_FAN0_TACH", > "Outputs": [ > "Pwm 1" > ], > "Type": "Pid", > "Zones": [ > "Pid 1" > ] > }, > > >> > >> Regards > >> -Vijay > >> > > I'm assuming you loaded this on a system. If it gave you the behavior you're looking for, you're done. If it didn't, it's probably time to start debugging and tuning. Thanks, No, I have not yet tested this but I can start this once we have our pid data and update documentations. I run my systems in the cascade controller setup. If you're deviating from that, you'll likely find some places that need better documentation and code improvements. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: pid control configuration 2019-05-15 21:50 ` Ed Tanous 2019-05-16 0:07 ` Vijay Khemka @ 2019-05-31 21:00 ` Vijay Khemka 2019-06-03 17:43 ` Ed Tanous 1 sibling, 1 reply; 17+ messages in thread From: Vijay Khemka @ 2019-05-31 21:00 UTC (permalink / raw) To: Ed Tanous, Patrick Venture; +Cc: openbmc On 5/15/19, 2:50 PM, "Ed Tanous" <ed.tanous@intel.com> wrote: On 5/15/19 12:21 PM, Vijay Khemka wrote: > > > Ed, please see if following declaration in entity manager would work as I am not defining any pid values here. > { > "Class": "fan", > "Inputs": [ > "MB_FAN0_TACH" > ], > "Name": "MB_FAN0_TACH", > "Outputs": [ > "Pwm 1" > ], > "Type": "Pid", > "Zones": [ > "Pid 1" > ] > }, > > >> > >> Regards > >> -Vijay > >> > > I'm assuming you loaded this on a system. If it gave you the behavior you're looking for, you're done. If it didn't, it's probably time to start debugging and tuning. This config is failing with below message. Apr 12 23:32:39 tiogapass swampd[1310]: terminate called after throwing an instance of 'std::out_of_range' Apr 12 23:32:39 tiogapass swampd[1310]: what(): _Map_base::at Is there any default data which I can be used for config but has no impact in its action? I run my systems in the cascade controller setup. If you're deviating from that, you'll likely find some places that need better documentation and code improvements. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: pid control configuration 2019-05-31 21:00 ` Vijay Khemka @ 2019-06-03 17:43 ` Ed Tanous 2019-06-03 18:18 ` Vijay Khemka 0 siblings, 1 reply; 17+ messages in thread From: Ed Tanous @ 2019-06-03 17:43 UTC (permalink / raw) To: Vijay Khemka, Patrick Venture; +Cc: openbmc On 5/31/19 2:00 PM, Vijay Khemka wrote: > > This config is failing with below message. > Apr 12 23:32:39 tiogapass swampd[1310]: terminate called after throwing an instance of 'std::out_of_range' > Apr 12 23:32:39 tiogapass swampd[1310]: what(): _Map_base::at > If I had to guess, you're missing a property that's required. > Is there any default data which I can be used for config but has no impact in its action? Like I said before, I don't know of anyone running phosphor-pid like you are hoping to. The "default" is to run in cascade loop mode, and all the existing systems are examples of that configuration. It's likely time for you to break out GDB and start debugging your configuration. Alternatively, approximating your fans as linear, and using that as the output targets would likely get you to a working thermal solution faster than going down the path you're going. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: pid control configuration 2019-06-03 17:43 ` Ed Tanous @ 2019-06-03 18:18 ` Vijay Khemka 0 siblings, 0 replies; 17+ messages in thread From: Vijay Khemka @ 2019-06-03 18:18 UTC (permalink / raw) To: Ed Tanous, Patrick Venture; +Cc: openbmc Thanks Ed, I will debug with some passthrough data. Regards -Vijay On 6/3/19, 10:44 AM, "Ed Tanous" <ed.tanous@intel.com> wrote: On 5/31/19 2:00 PM, Vijay Khemka wrote: > > This config is failing with below message. > Apr 12 23:32:39 tiogapass swampd[1310]: terminate called after throwing an instance of 'std::out_of_range' > Apr 12 23:32:39 tiogapass swampd[1310]: what(): _Map_base::at > If I had to guess, you're missing a property that's required. > Is there any default data which I can be used for config but has no impact in its action? Like I said before, I don't know of anyone running phosphor-pid like you are hoping to. The "default" is to run in cascade loop mode, and all the existing systems are examples of that configuration. It's likely time for you to break out GDB and start debugging your configuration. Alternatively, approximating your fans as linear, and using that as the output targets would likely get you to a working thermal solution faster than going down the path you're going. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2019-06-03 18:18 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-05-01 22:53 pid control configuration Vijay Khemka 2019-05-01 23:05 ` Ed Tanous 2019-05-01 23:10 ` Patrick Venture 2019-05-01 23:15 ` Patrick Venture 2019-05-02 23:24 ` Vijay Khemka 2019-05-06 16:20 ` Ed Tanous 2019-05-06 18:18 ` Vijay Khemka 2019-05-06 18:54 ` Ed Tanous 2019-05-10 21:20 ` Vijay Khemka 2019-05-13 16:32 ` Patrick Venture 2019-05-13 17:32 ` Ed Tanous 2019-05-15 19:21 ` Vijay Khemka 2019-05-15 21:50 ` Ed Tanous 2019-05-16 0:07 ` Vijay Khemka 2019-05-31 21:00 ` Vijay Khemka 2019-06-03 17:43 ` Ed Tanous 2019-06-03 18:18 ` Vijay Khemka
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.