I think you are mixing LinuxCNC HAL nomenclature with CANopen nomenclature. That could ultimately be very confusing I think.
> 0x1600 - 0x17FF are RPDO pins and end up as input pins. > 0x1400 - 0x15FF are communication parameters and these may require som > more thinking. > This example that I posted is for a battery charger. The 16 bit value at location 6071:00 on Charger with the address 0x0A refers to the charger maximum allowed current out to the battery. There is no physical pin. The non-linux world doesn’t refer to this as a pin. > ###6###,19/03/10,10:56:08,r,0A,1602:01,60710010,( 1618018320) The first two > bytes go to 0x6071:00 This next parameter could easily be 600100001 since it's a binary ON/OFF control for the charger. But if it was only 1 bit wide then the next parameter would start at bit 17 and go on for 32 bits. This could be a pin if there was an enable/disable line on the charger connector. > ###6###,19/03/10,10:56:11,r,0A,1602:02,60010008,( 1610678280) The next byte > goes to 0x6001:00 It's easier to waste space and then be able to read the last 4 bytes on a byte boundary rather than a bit boundary which is why the previous one was 8 bits wide rather than 1. The last value is scaled charger output voltage. Although my display shows it as Big Endian it's actually transmitted in the CAN frame as Little Endian. > ###6###,19/03/10,10:56:15,r,0A,1602:03,22720020,( 577896480) The last 4 > bytes go to 0x2272:00 So once every 1/2 second a message starting with 0x40A shows up on the bus and everyone sees it. The Charger and in this case also a small display are the only ones interested in it. The charger uses the information to set charge on/off, voltage and current. The display grabs the information and shows what the current charge voltage and max current are set to. The charger also reports in a different message what it measures for battery voltage and what the current charge current is and it reports if it's enabled. That's all identified by the Object Dictionary entries at 18xx and 1Axx. John > Read out these mapping and adding pins should be rather simple but > naming is a little bit more complicated. Without an *.eds or *.dcf file for > CAN networks or an esi? *.xml file for Ethercat pins adding pins which end > with the (index, subindex) numbers are probably a good choice. > > I suspect there will be cases then manually accessing the dictionary of > devices is useful and discovered I already added a probably incomplete > implementation of CiA 309-3 ASCII server in the linuxcnc driver. This may be > used to read what is needed from dictionary and for configuration using the > manual and/or a *.eds/*.dcf or esi *.xml file if available. > > > I did not find binary protocol. Do anybody know about a configuration tool > which use or may use an CiA 309-3 gateway for communication? Or parse > dictionary files? > > > Nicklas Karlsson > > > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
