Repository navigation
Regarding the issue where registers cannot actually be deleted in Map View. #136
Replies: 1 comment 1 reply
|
this looks like it is in how the values are stored rather than in the delete itself. deleting a row does remove the entry from the map model and unregisters it from the server, and clear table goes through the same remove path, but the actual register values are kept separately in a global map in ModbusDataUnitMap that covers the whole address range. every write goes into both the local map and that global map, and reads only ever come back out of the global map, so removing the unit map never clears the value that sits behind the address. that explains both parts of what you are seeing. when the same address is added again, the new row is filled from the server data for that address, which is read from the global map, so the old value comes back instead of zero. and since clear table removes rows the exact same way delete does, it cannot clear those stored values either. the reconnect part depends on two settings but comes from the same place. if the global unit map option is on, the server answers from that global map for every address anyway, so the rows in map view do not decide what is served. if auto add registers on request is on, the first request from the master rebuilds the range and fills it from the same global values, so a deleted register is served again as soon as the master asks for it. a real fix would need the remove path to also clear the stored value for that address in the global map, or at least make delete and clear table do that as an explicit step. |
Uh oh!
There was an error while loading. Please reload this page.
After a register is deleted in Map View, it remains accessible when the master reconnects to the slave.


If the same register is added again, its previously configured values are still retained.
This behavior is still reproducible even after pressing the "Clear Table" button.
All reactions