David and Andrew,
Thank you for the responses!
The simplicity of David’s solution is enticing.. But, oer Andrew’s response, I understand that there’s probably a proper way to do this with gevent. Andrew, are you able to provide any references or hints
for the gevent semaphore / lock approach? Is it as simple as making a call to gevent (similar to gevent.sleep()) when we would like to prevent handle_publish from being called again? Unfortunately I don’t know much about gevent or how it is used by Volttron.
Thanks again!
-- Joe
From:
Andrew Rodgers <andrew@xxxxxxxxxxxxxxxxxxx>
Reply-To: "andrew@xxxxxxxxxxxxxxxxxxx" <andrew@xxxxxxxxxxxxxxxxxxx>
Date: Wednesday, July 31, 2024 at 4:10 PM
To: "Raker, David M via volttron-dev" <volttron-dev@xxxxxxxxxxx>, "Thompson, Joe" <jthompson@xxxxxxxx>
Cc: "Raker, David M" <david.raker@xxxxxxxx>, "Smallwood, Seann" <SSmallwood@xxxxxxxx>
Subject: [EXTERNAL] Re: [volttron-dev] Volttron 8.1: How to Pause the handle_publish
It's best to use actual gevent semaphores or locks if you do this, don't just use a boolean instance variable or you won't have guarantees of consistency. — Andrew
Rodgers Co-Founder ACE IoT Solutions https: //aceiotsolutions. com
[aceiotsolutions. com]
It's best to use actual gevent semaphores or locks if you do this, don't just use a boolean instance variable or you won't have guarantees of consistency.
On July 31, 2024, 3:44 PM EDT
volttron-dev@xxxxxxxxxxx wrote:
Hi Joe,
I think the least invasive thing to do would probably be to introduce an instance variable called, let’s say, “self.publish_lock”. When you enter the close_contactor procedure, set the lock
True. On each run of handle_publish, check the lock and return before doing anything if it is set True. Set the lock False again when you are ready to run handle_publish as normal.
You could also, in principle, cancel the subscription and/or replace the function being used as a callback when the close_contactor is running, but I would try the previous approach first.
Dave
Check twice before you click! This email originated from outside PNNL.
Hello Volttron Team,
The Issue:
We are running into a challenge that we need help with. Please see the attached agent.py for reference. We have a little 5 second control loop for orchestrating the operation of an inverter with a battery energy storage system.
Every 5 seconds:
- the platform driver reads from the inverter and published its data
- via a subscription to the inverter’s topics, the handle_publish callback is fired
- our control logic is all contained within handle_publish
- one loop of the controller finished in well under 5 seconds, so the next iteration commences on the next handle_publish call
This has worked well for a long time until recently introducing some more complex controls. Essentially we have added a new control step that is called whenever the controller notrices that the battery’s contactor has opened up. This new
step / procedure, “close_contactor”, is called and is tasked with running through some steps to attempt to close the contactor again so that the controller can continue like normal.
But the “close_contactor” procedure is guaranteed to take around 70 seconds to complete due to some gevent.sleep() calls. During this time, there seems to be many other control threads that pop up every 5 seconds as the handle_publish callback
continues to be called in each subsequent 5 second interval.
Desired Behavior:
We are looking for a way to temporarily pause the execution of subsequent handle_publish callback calls while an existing thread is already running handle_publish. Is there a way to do this in Volttron? Or is our approach to this controller
fundamentally flawed and we will need to refactor our control algorithm?
Thank you for your time!
Joe Thompson
Technical Leader
Electric Power Research Institute
Energy Storage and Distributed Generation
(912) 663-3407
*** This email message is for the sole use of the intended recipient(s) and may contain information that is confidential, privileged or exempt from disclosure under applicable law. Unless otherwise
expressed in this message by the sender or except as may be allowed by separate written agreement between EPRI and recipient or recipient’s employer, any review, use, distribution or disclosure by others of this message is prohibited and this message is not
intended to be an electronic signature, instrument or anything that may form a legally binding agreement with EPRI. If you are not the intended recipient, please contact the sender by reply email and permanently delete all copies of this message. Please be
advised that the message and its contents may be disclosed, accessed and reviewed by the sender's email system administrator and/or provider. ***
|