Feature/turbovac #231
Feature/turbovac #231
Conversation
…odule of the TurboCtl package.
…vac/telegram to load the telegram parameters, warnings and errors. If they are not included in the site-packages the module can not find the files and load them
…s a start character and extracts the length from the telegram header. The commands are expected in bytes and the response is in bytes as well
… and its builder and reader provided by the subfolder telegram for correct formatting and extraction of information from the telegram.
…led via the control word. Since this has to be send by every message, I had to store the state in the service and each endpoints uses it. To not stop running I had to use the scheduler to schedule regular telegrams. I made a new endpoint to enable / disable control and to start and stop the pump
|
switching merge target to develop (from main) |
wcpettus
left a comment
wcpettus
left a comment
There was a problem hiding this comment.
Incomplete, but to get things rolling
There was a problem hiding this comment.
generic question: do we want example files for every implementation?
or do we want to have an index where we link first/significant implementation config files to the controls repos (recognizing that those are private)
| - /usr/local/src_dragonfly/dragonfly/watchdog.py | ||
| - --config | ||
| - /root/AlarmSystem.yaml | ||
|
|
There was a problem hiding this comment.
similar generic question: when to include in docker-compose?
| import socket | ||
| import threading | ||
|
|
||
| from dripline.core import Service, ThrowReply |
There was a problem hiding this comment.
throughout this service code you are using Exception instead of ThrowReply
I didn't fully track which are caught and re-handled, but probably some should be ThrowReply?
| import threading | ||
|
|
||
| from dripline.core import Service, ThrowReply | ||
|
|
There was a problem hiding this comment.
also: lots of print statements instead of logger
| Service.__init__(self, **kwargs) | ||
|
|
||
| if isinstance(socket_info, str): | ||
| print(f"Formatting socket_info: {socket_info}") |
There was a problem hiding this comment.
flagging first example of print > logger
| self.socket = socket.create_connection(self.socket_info, self.socket_timeout) | ||
| except (socket.error, socket.timeout) as err: | ||
| print(f"connection {self.socket_info} refused: {err}") | ||
| raise Exception('resource_error_connection', f"Unable to establish ethernet socket {self.socket_info}") |
There was a problem hiding this comment.
flagging first example of Exception > ThrowReply
(although this is called in both init and reconnect, so possibly gets treated differently)
| print("Query successful after ethernet connection recovered") | ||
| except socket.error: # simply trying to make it possible to catch the error below | ||
| print("Ethernet reconnect failed, dead socket") | ||
| raise Exception('resource_error_connection', "Broken ethernet socket") |
| self.socket = socket.socket() | ||
| self.socket_timeout = float(socket_timeout) | ||
| self.socket_info = socket_info | ||
| self.STX = b'\x02' |
There was a problem hiding this comment.
is this universal to USS, or should it be an argument of init (where it could default to this)?
(too lazy to read the docs, you probably just know the answer)
There was a problem hiding this comment.
In all documents I find that its \x02 but making it a default parameter does not hurt
|
|
||
| for command in commands: | ||
| if not isinstance(command, bytes): | ||
| raise ValueError("Command is not of type bytes: {command}, {type(command)}") |
There was a problem hiding this comment.
change to ThrowReply?
and structurally - does the endpoint class do checking so that if this is properly paired you shouldn't get this error?
| self.service.control_bits.append(ControlBits.COMMAND) | ||
| self._log_action_id = self.service.schedule(self.checkin, datetime.timedelta(seconds=self.checkin_interval), datetime.datetime.now() + self.service.execution_buffer*3) | ||
| else: | ||
| raise ValueError('unable to enable control when checkin_interval evaluates false') |
2 participants
This pull requests implements
The USS protocol use the following stucture (see full definition at here
The USS protocol has variable length and no terminator. The USS protocol was developed by Siemens and e.g. used by Laybolds TurboVac Telegram.
The Turbopums of laybold TurboVAC have a serial telegram defined following the USS protocol with a fixed length of 24 bytes.
The telegram follows this structure:
See documentation here
For the implementation of the TurboVac control I reuse the TurboCtl/telegram submodule from thie TurboCtl github repository.
I implemented and tested the service and entity and its working with our turboVac 350/450i pump by Laybold.
Till now I could not test the "set" method since we need to have the pump running for this.