Skip to content
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

Handle very old (GP) firmware more robustly #27

Open
alexrudd2 opened this issue Jan 6, 2022 · 2 comments
Open

Handle very old (GP) firmware more robustly #27

alexrudd2 opened this issue Jan 6, 2022 · 2 comments

Comments

@alexrudd2
Copy link
Member

All versions of the firmware work great, except GP. [Marina has] mixed feelings about this since it's 10 years old now and these devices aren't circulating much. The loop type can't be changed (and register 85 doesn't exist yet) so that messes get_pid(), though set_pid() can be used if the loop isn't specified. The totalizer command is missing the dollar signs ({addr}T\r instead of {addr}$$T\r so it doesn't like this. Only GP actually uses the dollar signs, though everything else is backwards compatible. And lastly, the {addr}VE command also wasn't around yet, so GP isn't recognized to stop it from continue to create_mix() function. {addr}??m8 would work, but only for GP which is annoying.

Originally posted by @marinapalese in #15 (comment)

@alexrudd2
Copy link
Member Author

here's a brief overview:

Ideally, FlowController would ask for the connected device's version (and maybe other properties like max flow) on initialization. The class would then select from a series of subclasses (ie. FlowControllerGP) that implement all the features available for that specific device version. This is more complicated but provides back-compatibility and modern device features without compromising on either. There are many patterns (mixins w/ protocol vs. transport subclasses, yaml config file containing protocols, etc) that could be tried out based on how unique the handling needs to be.

Also ideally, we'd read/write the registers directly for all functions. Not only does this open up more features (as you've already shown in this PR!) but it allows greater accuracy for getting/setting flow rates on more modern MFCs.

This is a full library rewrite... but this is a small library so it's not out of the question. What would be needed is 1. a detailed list of all Alicat MFC versions and their communication protocols and 2. a good hardware test system with all supported MFCs that we could build a real test suite against.

If it's something you're interested in leading or helping out with, let me know and I'd be happy to find a way to support.

Originally posted by @patrickfuller in #15 (comment)

@alexrudd2
Copy link
Member Author

@marinapalese Try using backticks (`) to indicate code rather than single quotes ('). This works both in github comments and README.md since it's Markdown syntax. For the website you can also select text and click the code button, which wraps the text in backticks.
Screen Shot 2022-01-06 at 1 31 30 PM

'{addr}T\r' becomes {addr}T\r

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant