RevpiEpics

[XavSPM]

Hello everyone,

I am sharing what I have been able to achieve with pythonSoftIOC on RevolutionPi boards.
I have created a Python package to use the pythonSoftIOC implementation with revpimodio2.

https://github.com/XavSPM/RevpiEpics

Currently, only AIO boards are supported. However, this may evolve in the future.

If you have any comments, please do not hesitate. Be indulgent, this is the first time I have created a Python package.

Xavier

[AlexanderWells-diamond]

Thank you for sharing, it's always interesting to see how our software is being used.

I took a look through the code. I'm afraid I don't have any hardware to test it on so everything I say is purely from a visual inspection.

• Your analog out records currently define an on_update callback. You can save a parameter by using on_update_name (docs here). I would also suggest doing a lookup of the io_point variable inside that callback, rather than having it encapsulated when the lambda is created. This should remove the need for the intermediate lambda function.
• It is considered more modern to migrate configuration to a pyproject.toml file rather than specifying everything in setup.py. Here are docs about that
• The magic numbers in lists in builder_aio mean nothing to me; I expect they mean more to someone who knows something about the hardware. However I would suggest moving these lists into their own variables, which can then be given descriptive names to help identify them. This will also help if these numbers ever need to be externally configured.
• There's a fair amount of accessing of private variables, both of your own code and from imported libraries.
  • For your own code, you may want to reconsider what is actually private and what isn't; it looks to me like some of the private methods on RevPiEpics really don't need to be - they have minimal/non-existent usage of the state of the class instance. Perhaps look at moving them to class methods, or just free functions.
  • For library code, you may want to double-check if there's a properly documented way to access the data you need from the library, without resorting to private variable access.
• It is unnecessary to guard logging.debug calls with a flag - the logging library will do that for you based on the configuration you've already set up during initialization.
  • There's a very minor optimization you can make regarding using format strings vs print specifiers, but it's really not worth the time unless you are pressed for performance. See this discussion.

Hope this is what you were after!

[XavSPM]

Thank you @AlexanderWells-diamond for your comments.
Due to my limited coding experience, your feedback is extremely valuable to me.

Your analog out records currently define an on_update callback. You can save a parameter by using on_update_name (docs here). I would also suggest doing a lookup of the io_point variable inside that callback, rather than having it encapsulated when the lambda is created. This should remove the need for the intermediate lambda function.

I hadn’t thought of that solution. It’s definitely possible to create a list in RevPiEpics to link the PV name with the input/output name. This would allow me to remove the lambda function.

It is considered more modern to migrate configuration to a pyproject.toml file rather than specifying everything in setup.py. Here are docs about that

I wasn’t familiar with this type of configuration. My Python books are starting to get a bit old. I’ll take a closer look at this.

The magic numbers in lists in builder_aio mean nothing to me; I expect they mean more to someone who knows something about the hardware. However I would suggest moving these lists into their own variables, which can then be given descriptive names to help identify them. This will also help if these numbers ever need to be externally configured.

You’re right, for better code readability, I will replace these numbers with variables like this:

ANALOG_INPUT_OFFSETS = [0, 2, 4, 6]
STATUS_INPUT_OFFSETS = [8, 9, 10, 11]

For your own code, you may want to reconsider what is actually private and what isn't; it looks to me like some of the private methods on RevPiEpics really don't need to be - they have minimal/non-existent usage of the state of the class instance. Perhaps look at moving them to class methods, or just free functions.

You’re right, I will try to fix that.

For library code, you may want to double-check if there's a properly documented way to access the data you need from the library, without resorting to private variable access.

Unfortunately, after testing all possibilities, I only found this solution to determine the offset values of the cards and thus determine the input type.
Currently, there’s no function in revpimodio2 that gives me this information.

It is unnecessary to guard logging.debug calls with a flag - the logging library will do that for you based on the configuration you've already set up during initialization.
There's a very minor optimization you can make regarding using format strings vs print specifiers, but it's really not worth the time unless you are pressed for performance. See this discussion.

This is the first time I’m using the logging module, so I will study it in more detail.

I find this type of PLC very interesting, as it allows me to have an IOC integrated directly into it.
Moreover, with Cockpit, managing the installation becomes much easier.

If you’re interested, I invite you to check out this page: Documentation

[XavSPM]

Hello, @AlexanderWells-diamond

I have made the modifications you advised. You can see them in the dev branch. Your advice has been very helpful.

[XavSPM]

@AlexanderWells-diamond,

I've made significant changes to my program. Thanks to your advisors, my program is now more flexible and understandable. Thank you.