-
Notifications
You must be signed in to change notification settings - Fork 0
Pfeiffer Endpoint: Implementation of Pfeiffer telegram protocol #224
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
Conversation
…We assemble and the command at each get / set and disensemble / format the response corresponding to the datatype defined by pfeiffer.
|
Apparently Paul has a device that needs this at UW, so we have another place to test this code |
pkolbeck
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it true that the response datatype is always the same as the command datatype?
wcpettus
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, a couple small comments.
|
Procedural note: this Dockerfile still on 5.1.0 - other current release is 5.1.2 (which the modbus PR uses) |
…d parts of the disensembled message. Nicer formarting of long dict.

Implementation of Pfeiffer telegram protocol following documentation from Pfeiffer manuals.


The frame of the protocol is defined by:
Each parameter has a number (which may differ from device to device). For values Pfeiffer has a table of predefined datatypes and how they have to be formated:
Implementation works very nice with our pressure gauge of type HPT 200 from Pfeiffer.
The configuration file significantly improved in readability (see example folder).