Developing of SZARP continues

Recently, a lot has happened in our github project. We started with a general code review to get rid of all sorts of bugs and warnings at compile and build packages with our SZARP. On the occasion of this work we abandoned support for Analysis (boilers are out!), Psetd, and a large range of extinct daemons. Then we moved our window applications to a more up-to-date version of wxWidgets which will greatly streamline the introduction of new functionality. In the meantime, we’ve improved the heap (not stack) of bugs, very often mistakenly labeled as features. This year, the team of contributors came out with a shield. Even three.

During this work, the need for a new Danfoss FC protocol was born. This protocol specifies the master-slave access technique for serial communication. We will not dwell on specifics here, but it is worth mentioning the quality and amount of documentation. Just be careful – the English version of the documentation is the only recommendable.

After a brief discussion on whether it should be a separate program or whether it can use all the good offered by metadaemon, more commonly known as borutadmn, the answer was clear. Our good borough will get another protocol to handle. Where to start?

We started by reviewing the documentation (once again we recommend English version!), wherein we define the critical moments of this protocol. We promised not to get into the detailed specifications, but the protocol required that. From the documentation we learned that in order to obtain data we have to create a 16 byte telegram

  • STX is always 0x02 (we do not like magic numbers),
  • LGE in case of 16 byte telegram will always be 0x0E (hic!) ¹,
  • This ADR is the address of our slave, enlarged by 0x80 (the 7th bit is always 1),
  • Databytes are the contents of a telegram (described below),
  • BCC is a logical sum of XOR logic on all remaining bytes

Databytes in our case contains 6 of 2 bytes positions – PKE, IND, PWEHIGH, PWELOW, PCD1, PCD2. There is a parameter number in the PKE and a function that the inverter is requested to do with the parameter. IND is used to query array parameters. Other items are used by the slave to provide information.

Backing to borutadmn, it is a metadaemon that already has plugins for supporting protocols such as modbus (tcp and serial, client and server), zet (tcp and serial, client), fp210 (serial, client), lumel (serial, client) wmtp (tcp, client). It is based on libevent event handling, which ensures continuity of tasks on many devices. This ensures efficient work with minimal hardware effort. By writing a new module for our metadata we tried to keep the C ++ 11 standard, which was not always in line with the spirit of our boruta.

After a few days of uneven battle, the borutadmn was abducted and our contributor received the first data from the Danfoss VLT 6000 inverter. There was a so-called test phase on the table that detected a plenty of abnormalities in maintaining communication stability. These errors were quickly localized and corrected.

Configuration of the Danfoss inverters using the FC protocol is very similar to the daemon configuration for other protocols. For our new module we had to introduce a new attribute to param, called parameter-number, located in the ipk-extra namespace. It corresponds to the parameter number we want to read. For configuration details, please visit our Documentation section.

In the near future, the plugin should appear in the newer metadata borutadmn_z based on libzmq, which offers even more possibilities, including read and write 2/4 byte unsigned data.


¹ – for our needs we only use 16 byte telegrams (LGE = 0x0E), but 8 byte telegrams are allowed – then LGE = 0x06