libedssharp
libedssharp copied to clipboard
$NODEID is not saved in OD c file
If I try to export c file with PDO mapping an use the $NODEID define, it is not saved in the c file e.g. if the objects COB-ID used by RPDO (0x1400) is set to 0x00000180+$NODEID in the entry for 0x1400 is /1400/ {{0x2L, 0x0180L, 0xfeL},
expected is something like /1400/ {{0x2L, 0x0180L+$NODEID, 0xfeL},
That is right. The $NODEID ist not a define for the *.c file, but for the *.eds file.
CANopenNode calculates the COB-IDs based on the node ID configured in the code.
So there is no difference if RPDO (0x1400/01) in the editor is set to 0x00000180+$NODEID or 0x00000180?
CiA301:
Sub-index 01h contains the COB-ID of the RPDO (+valid, reserved and frame bits) e.g. Generic pre-defined connection set for RPDO (0x1400) CAN-ID: 200h + Node-ID. So e.g. for Node 8 there should a 208h or generic 200h+$NODEID
But if CANopenNode calculates the COB-IDs based on the node ID configured in the code, then the INPUT default value in the OD Editor should be, different to the CiA 302 description, just the base ID (COB-ID - $NODEID) = 208h - 8h = 200h for the example above.
@trojanobelix You're correct. I think the fix should really be in CANopenNode as well as libedssharp.
In CANopenNode, CO_PDO.C, the functions "CO_RPDOconfigCom" and "CO_TPDOconfigCom" will add the nodeId to the COB-ID for the first 4 TPDO/RPDOs if they use the default values (0x180, 0x280, 0x380, 0x480 for TPDO). This is hard-coded. The rest of the PDOs are however left at whatever default value you put in the GUI (+$NODEID will have no effect).
So if you want to add "NodeID" then use first 4 PDOs, otherwise leave first 4 PDOs unused and start from 5th or use non-default COB-IDs.
Be careful with $NODEID
The $NODEID is used in the editor, it takes what ever value is in the Concrete Node Id then will substitue this when generating the OD for occurances of $NODEID and then attempt to add them together. (if this fails it just uses the inital value)
Also $NODEID is valid in EDS files, the problem with this is the eds file itself has no concept of what the actual node id is so unless you can pass this intention through to the stack then it is added at runtime, it is useless. So the workaround in the editor is to just use what ever is in concrete node id and apply that (and ofcause the default cobs 0x180 0x200 etc will get node ID added to them by canopen node).
Robin
On Thu, 15 Aug 2019 at 11:55, AminGholamzadeh [email protected] wrote:
@trojanobelix https://github.com/trojanobelix You're correct. I think the fix should really be in CANopenNode as well as libedssharp.
In CANopenNode, CO_PDO.C, the functions "CO_RPDOconfigCom" and "CO_TPDOconfigCom" will add the nodeId to the COB-ID for the first 4 TPDO/RPDOs. This is hard-coded. The rest of the PDOs are however left at whatever default value you put in the GUI (+$NODEID will have no effect).
So if you want to add "NodeID" then use first 4 PDOs, otherwise leave first 4 PDOs unused and start from 5th.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/robincornelius/libedssharp/issues/158?email_source=notifications&email_token=AABG2GEI2JL3I2UELRWNSFTQEUYYTA5CNFSM4GWQAK6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4LQIPQ#issuecomment-521602110, or mute the thread https://github.com/notifications/unsubscribe-auth/AABG2GBJDXHM6KLXFA5UNMDQEUYYTANCNFSM4GWQAK6A .
Yeah the problem is CANopenNode has no concept of "+$NODEID " I get my NodeID from DIP switches and so there's no way libedssharp can substitute the $NODEID with the correct value. If CANopenNode implement this then at run-time, just before initialising CO object, it will substitute $NODEID.
All in all there's nothing more libedssharp can do about this I believe so thanks Robin, saved me a lot of nervous coding.
On Tue, 12 Feb 2019 at 10:34, trojanobelix [email protected] wrote:
So ther is no difference between
0x00000180+$NODEID
CanopenNode will take any "default cob id"
There is a small difference in the editor if you use the Network PDO report, currently if you write only a default COB eg 0x00000180 the Network report will show that, if the PDO is written as 0x00000180+$NODEID then it will add the concrete NodeID in the report window.
As for what is written to the OD, no it makes no difference 0x00000180 always implies 0x00000180+$NODEID (and it will use the actual node id at runtime) so if you store that in an eeprom and change it, it will be fine.