second on ethercat driver. the way it works is with a user component that slurps up an xml config and beams it to the realtime part. (I cant remember how it does that). I would guess that the way config is structured would be much the same.
the ethercat driver could probably habdle CAN stuff without a ton of modification. On Thu, Jun 13, 2024, 10:38 AM Rod Webster <r...@vehiclemods.net.au> wrote: > I'm not sure if this would help but I would look at what Scott Laird has > done with the Hal Ethercat driver recently > https://github.com/linuxcnc-ethercat/linuxcnc-ethercat > I would try and use a similar XML to what is used for Ethercat. eg Look at > his CIA402 driver and its settings. > And of course, you will probably find that all the hard stuff is already > done to support Canopen over Ethercat. > Note this repo has a buildbot that sends the debs to the > etherlabmaster repository where the Ethercat master is distributed from. > And this repo is already set up in the LinuxCNC 2.9.2 ISO so its a very > quick process to get a working ethercat build. > Scotts a great guy and will be only too happy to help if you raise an issue > there. > > > Rod Webster > *1300 896 832* > +61 435 765 611 > Vehicle Modifications Network > www.vehiclemods.net.au > > > On Thu, 13 Jun 2024 at 06:38, Nicklas SB Karlsson <n...@nksb.eu> wrote: > > > Are currently trying to use CANopen with a device and have done some > > development. Have until now run hard coded mappings > > but now reached a point there configuration is needed. Implement > graphical > > configuration and store configuration in > > binary format would of course be one option but have chosen a text file > > possible to edit manually. Use maps like below. > > > > > > map={.cobId=181h, .name="encoder.cnt", .dir=HAL_OUT, .type=HAL_S32, > > .bitlen=32, .bitpos=32, .name_scaled="encoder.pos", > > .name_gain="encoder.pos.scale", .gain=0.13} > > map={.cobId=201h, .name="pos.cnt", .dir=HAL_IN, .type=HAL_S32, > .bitlen=32, > > .bitpos=0} > > > > > > First field is message "identifier" for the messages on the network. > > Second is name of hal pin. Third is hal direction. > > Fourth is hal datatype. Fifth is length of number in message which may be > > one for a single bit. Sixth to eigth is > > optional, if availabe it is name of hal pin for scaled value. Seventh if > > available is name of hal parameter for scaling > > gain. Eigth if available is gain default value. There is probably a need > > to add one parameter before the first to > > identify network in case several are available. > > > > This should work for CANopen both over CAN networks but also over > Ethercat > > but are a little bit unsure about how to > > identify the message if used over Ethercat. CAN network use rather small > > messages 8 bytes maximum for ordinary CAN and > > some order of magnitude larger for CAN FD, all variables in same message > > same direction. Ethercat use much larger > > messages and may have both inputs and outputs in "same" message, message > > is sent in a ring similar principle as cascaded > > shift register so outputs is written in message before sent while inputs > > are read from message then it arrive back. Need > > for mapping is same so should hovewer be possible to use same syntax in > > configuration file. > > > > Syntax in configuration file is currently more or less as an array in C > as > > I copied the hard coded mappings from C to > > configuration file. Have a simple first far from perfect implementation > or > > hack that read the mappings from the > > configuration file. Anybody have any suggestions about the syntax for the > > configuration file? There is some more or less > > standard to write down these kind of mappings for CANopen I have missed? > > Any parser in Linuxcnc which may be reused to > > read this configuration file possible with other syntax? > > > > > > There is also sometimes a need for a "configuration script" before nodes > > enter mode of operation normal. First idea is > > to borrow the CANopen CiA309-3 standard and simply enter the command(s) > in > > a file, possible same file as used for the > > mapping. Anybody have any other suggestion? > > > > > > Regards Nicklas Karlsson > > > > > > > > _______________________________________________ > > Emc-developers mailing list > > Emc-developers@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
