-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cleanup branch: PMON #37
base: develop
Are you sure you want to change the base?
Conversation
This was tested and confirmed to be working on 12/16. Video recording: Log file: There's still a bug where one or more units briefly fail to respond in time, despite increasing the fault tolerance at various levels ( I do not think this is a pressing problem though, based on how quickly recovers from the lack of response. The problem doesn't seem to be isolated to any particular unit. My hunch is that we're pushing an aggressive polling cycle that involves multiple reads (status, process_value) every time and occasionally the the DP16 units are polled in an unprepared state, but like I said, I'm not too concerned about this as an immediate issue. |
I mentioned this in our meeting on 12/20, but I think there's a problem with how the The temperatures are updating slower than they should. This behavior can be seen in the video I posted in PR#34. The with self.modbus_lock: # Lock held for all units
for unit in self.unit_numbers:
self._poll_single_unit(unit) # Each unit can take up to 0.5s before timing out
time.sleep(0.1) # single sleep at end The I'm going to pursue some changes to acquire and release modbus_lock between each unit, and try to track the actual time spent polling so that we're not making unnecessarily long |
…t read. Simplify error paths
…BEAM_dashboard into bugfix/cleanup-PMON
This PR is for misc cleanup and changes related to the
ProcessMonitorSubsystem