Bug in VelBusLink software


I’ll try to do my best to explain it in english…

I have a DM1 module at address $51 and a 4PD at $81. I did some experiments with assigning and removing buttons from the 4PD to the action list of the DM1 by using the software.

Now, after removing ALL actions, the DM1 still reacts to commands coming from the 4PD.

I checked and double checked the action list in the software and it is completely empty: no button assigned to any of the 8 actions.

I did a backup of the DM1 module and used a hex editor to check the memory map against the one described in the protocol file and I found out that the DM1 has some settings left:

-> mem. locations $38, $70 and $C4 contains $81
-> mem. locations $39, $71 and $C5 contains $00
(please note: $00, not $01 !!!)

All other bytes are $FF, except the name at the end

If I use the ‘Read Data From Memory’ command by sending 0F FB 51 03 FD 00 38 6D 04 to read the value of memory location $0038, I receive $81, so the protocol is working.

If I modify locations $39, $71 and $C5 to $01, the 3 corresponding actions are bound to PushButton 1 on the 4PD. At that time, I can remove the binding, but depending on HOW you remove the binding, it can go wrong…

If you select the name of the button in the right part of the screen (so, the second node in the tree) and press the -] button, the software writes the wrong data to the DM1 module:

FC 00 70 81 <-- wrong, should be $FF
FC 00 71 00 <-- wrong, should be $FF
FC 00 72 FF
FC 00 73 FF
FC 00 74 FF

If you select the name of the 4PD module in the right part of the screen (so, the first node in the tree) and press the -] button, the correct data is written to the DM1 module.

Hope this info is clear enough to solve the problem…



Could you please check this out too in the next update?



Don’t forget to click on the ‘Apply’ button after removing buttons for a certain action

Hi Vel324,

That is not the problem. The problem is that, depending on how the binding is removed, the VelBusLink sends the wrong data to the 4PD

in dutch (sorry…)

Als je in het rechtse deel van het scherm (de boomstructuur) de knop schrapt (een level 2 node), dan wordt de bit op 0x71 van die knop wel gewist, maar het adres van de module op 0x70 niet. De software stuurt :

FC 00 70 81 <-- adres van de 4PD module
FC 00 71 00 <-- ongeldige bitmask voor de buttons

en dat moet dus zijn:

FC 00 70 FF <-- geen link meer met de 4PD @ 0x81 = OK
FC 00 71 FF <-- geen link meer met button xx op die 4PD = OK

Schap je echter de volledige module (een level 1 node), dan gaat het wel goed.

Dit probleem heeft dus niks te maken met niet op de Apply knop te klikken. Meer nog, bovenstaande stream wordt naar de 4PD gezonden net omdat ik op Apply klik.

De software stuurt de foute gegevens naar de 4PD (81 00 ipv FF FF).

Bekijk het protocol: 81 00 is toch een ongeldig button adres?


The software should delete the module node if all of its channels are removed. If the module node is still present in the list on the right, then the software might write the address of the module, with 00 as the second byte (eg. with no channel flags set).

If I understand the problem correctly that is :slight_smile:

Hi Vel448

That is exactly the problem. And I think it is wrong: there are no channels selected, so the address of the module should be cleared also.

If not, the 4RY/1DM modules reacts in a strange way: because no channel is stored, it doesn’t matter WITCH button on the 4PD is pressed, as long as the address matches, the 4RY/1DM do their thing…