Not possible to have an object dictionary with discontiguous RPDO/TPDO

[FreddieChopin]

Some CANopen applications - like CANopenLift - use non-standard numbers and addresses of RPDO/TPDO, which frequently make them non-contiguous. For example one CANopen node can have just RPDO 257 and TPDO 130. Current state of CANopenNode source code - for example in CO_CANopenInitPDO() in CANopen.c at line 1226 - expects PDOs to be contiguous and start from 1.

In case of my CANopenLift node I would have to add 256 completely unused RPDOs just to have one needed RPDO 257. I know that I can add this single RPDO 257 as RPDO 1, but it would be nice to actually follow the standard requirements.

While we're at the topic of PDOs, couple of related issues:

1. Current experience with EDS editor is terrible (at least on Linux). Whenever I edit TPDO/RPDO, it resets allmost all the settings in the object dictionary that I entered (all PDO configuration and mapping entries get set to "no SDO access" and it clears the contents of "Count label" checkbox).
2. There is no way to use +$NODEID when editing the dictionary. Firstly because there is no way to export that value for CANopenNode and secondly because CANopenNode actually only sets this +$NODEID for the first 4 standard PDOs if some complex condition is met, which can be wrong in some cases (hard to tell).

[StormOli]

Re EDS editor, I've been having a few issues myself. I've managed to fix the error where all the mapping entries have no SDO access and created a Pull request for it.

[CANopenNode]

I commented the problem here: https://github.com/robincornelius/libedssharp/pull/260

libedssharp is huge, I can't maintain it all, I can only assure "Object Dictionary" tab is working properly. Which is enough, but requires more raw approach. Besides "TX PDO Mapping", "RX PDO Mapping" tabs, also "eds.cs" file, which is central part of everything, is hardly manageable (I made as little changes into it as possible).

At least I should add a notice about recommended PDO handling into README file.

[CANopenNode]

About non-standard RPDO configuration: CANopen.h and .c files automates quite a lot and are already complex. I tried to make them suitable for most common configuration and flexible for user to use alternative functions.

You can try (for lift):

1. used CO_MULTIPLE_OD define. You can then fine tune your configuration. I pushed example few minutes ago. But you have to re-export OD.h and OD.c files with latest CANopenEditor.
2. Make your own functions similar to CO_CANopenInitPDO(), CO_process_RPDO() and CO_process_TPDO(). You can fully control the PDOs.