jan iversen

Yes we need backward compatibility whenever possible! just make the parameters optional, the existing action should use kwargs if I remember right.

I understand your explanation of access, but it seems too complex and very theoretical. please do not forget this is a simulator not production. Only a very special user would...

Thinking about your example, that can be solved without the extra parameter, something like: ``` def custom_action3(_registers, _inx, cell, func_code): """Test action without access type as parameter.""" global code6_flag if...

If your changes are done and merged in time for v3.7.0 (due next week), then adding the function_code is ok. Otherwise API changes are not allowed until v3.8.0 which are...

For 3.7.0 API changes are allowed, and again much later for 3.8.0. API changes needs to be documented in API_changes.rst.

Thanks for the update. Version 3.8.0 will probably not be before December. But we do merge Pull Requests with API changes, they simply go into "wait_3_8_0"

It is acceptable, but opening a new PR might cause fewer discussions as this one had a couple of problems.....your choice.

Remark for the upcoming v3.8 API changes are allowed as long as they are documented in API_chsnges.rst, that might make the work easier.

I can surely see the need for make the connection a device, especially this would potentially open the possibility to show connection status and disconnect/reconnect on demand. However have a...

You request 2 registers == 4 bytes, however your device responds with 3 bytes. 0x1 0x3 0x4 0x0 0x1 0xbe Which is slave = 0x01 function code = 0x3 byte...