Web simulator documentation and examples missing. #1284
Comments
|
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
This update adds native support for some of the most commonly found datatypes in OT systems. This includes support for bitfields, unsigned integers, signed integers, and floating point numbers in multiple word sizes (16 bit, 32 bit and 64 bit). Relevant changes include: A reworked version of simulator.py that relies on struct.unpack, struct.pack, and other native functions to simplifly datatype handling while also incorportating additional checks to ensure the register layout behaves as expected. In order to simplifly future work development, the Bits field has been renamed bitfield16, while also adding support for 32 and 64 bit fields. To help facilitate adoption, several changes have been done to the project files to ensure a smooth transition. This includes: - Updated documentation to reflect new datatypes, including examples. - Updated unit tests, to ensure the code works as expected. - Updated the simulator example to illustrate how the new datatypes can be used Resolves [discussion]: pymodbus-dev#1458 Partially addresses: pymodbus-dev#1284
This update adds native support for some of the most commonly found datatypes in OT systems. This includes support for bitfields, unsigned integers, signed integers, and floating point numbers in multiple word sizes (16 bit, 32 bit and 64 bit). Relevant changes include: A reworked version of simulator.py that relies on struct.unpack, struct.pack, and other native functions to simplifly datatype handling while also incorportating additional checks to ensure the register layout behaves as expected. In order to simplifly future work development, the Bits field has been renamed bitfield16, while also adding support for 32 and 64 bit fields. To help facilitate adoption, several changes have been done to the project files to ensure a smooth transition. This includes: - Updated documentation to reflect new datatypes, including examples. - Updated unit tests, to ensure the code works as expected. - Updated the simulator example to illustrate how the new datatypes can be used Resolves [discussion]: pymodbus-dev#1458 Partially addresses: pymodbus-dev#1284
This update adds native support for some of the most commonly found datatypes in OT systems. This includes support for bitfields, unsigned integers, signed integers, and floating point numbers in multiple word sizes (16 bit, 32 bit and 64 bit). Relevant changes include: A reworked version of simulator.py that relies on struct.unpack, struct.pack, and other native functions to simplifly datatype handling while also incorportating additional checks to ensure the register layout behaves as expected. In order to simplifly future work development, the Bits field has been renamed bitfield16, while also adding support for 32 and 64 bit fields. To help facilitate adoption, several changes have been done to the project files to ensure a smooth transition. This includes: - Updated documentation to reflect new datatypes, including examples. - Updated unit tests, to ensure the code works as expected. - Updated the simulator example to illustrate how the new datatypes can be used - Performed linting on 3.12 Resolves [discussion]: pymodbus-dev#1458 Partially addresses: pymodbus-dev#1284
This update adds native support for some of the most commonly found datatypes in OT systems. This includes support for bitfields, unsigned integers, signed integers, and floating point numbers in multiple word sizes (16 bit, 32 bit and 64 bit). Relevant changes include: A reworked version of simulator.py that relies on struct.unpack, struct.pack, and other native functions to simplifly datatype handling while also incorportating additional checks to ensure the register layout behaves as expected. In order to simplifly future work development, the Bits field has been renamed bitfield16, while also adding support for 32 and 64 bit fields. To help facilitate adoption, several changes have been done to the project files to ensure a smooth transition. This includes: - Updated documentation to reflect new datatypes, including examples. - Updated unit tests, to ensure the code works as expected. - Updated the simulator example to illustrate how the new datatypes can be used - Performed linting on 3.12 Resolves [discussion]: pymodbus-dev#1458 Partially addresses: pymodbus-dev#1284
This update adds native support for some of the most commonly found datatypes in OT systems. This includes support for bitfields, unsigned integers, signed integers, and floating point numbers in multiple word sizes (16 bit, 32 bit and 64 bit). Relevant changes include: A reworked version of simulator.py that relies on struct.unpack, struct.pack, and other native functions to simplifly datatype handling while also incorportating additional checks to ensure the register layout behaves as expected. In order to simplifly future work development, the Bits field has been renamed bitfield16, while also adding support for 32 and 64 bit fields. To help facilitate adoption, several changes have been done to the project files to ensure a smooth transition. This includes: - Updated documentation to reflect new datatypes, including examples. - Updated unit tests, to ensure the code works as expected. - Updated the simulator example to illustrate how the new datatypes can be used - Performed linting on 3.12 Resolves [discussion]: pymodbus-dev#1458 Partially addresses: pymodbus-dev#1284
|
Hello, I am currently contemplating on possibilities for automating use of the client. The ReST-API would be a convenience for me, and I could possibly create a skeleton for the build_json_* functions based on their html equivalents. But what kind of state would you expect for it at this point? At best, they would be filled, but I don't think I have the know-how/time to set up full integration tests for whatever I would do, much less fully document it. So in short: if anything is done, what is the expected outcome? |
|
I am not sure how you can make a rest api without fully integrating it. This might b3 easier if you submit a pull request, allowing us to review it. Ps. the pull request do not need to be "everything" but enough that we can see the direction is sound. |
|
Documentation is of course important, without it the feature is unknown, however writing documentation is easier than programming skeletons, just have a look in docs |
Yeah true, I guess it could not be called that :D What I meant is that if I take build_html_registers and convert on build_json_registers (more or less copy-paste + adapt at this point), I would get enough to manipulate registers with json format API. This indeed would not be a full API in any sense. Plus as said, I don't know enough of the features included in build_html_registers (mainly operations, Set, Clear, Stop, etc) to validate if they function properly or not. Due to these, I'd still call it a skeleton at best. Same would apply for the other json endpoints. If I had time, I do have plans on how to implement it completely. Sadly, I'm lacking on the extra-time department :/
Of course. But in my case, the same skeleton principle would apply. It would only be something like But regardless. I'll see what I can do about the PR. No promises though. |
|
Thinking about combining server and simulator so that the simulator will only be a http server using the server. |
The new web simulator misses some features, before being the main simulator:
Documentation of config done !
Documentation of web pages waits until (someone) the have a better look.
Documentation of http_server and main can be done.
The text was updated successfully, but these errors were encountered: