This sounds like the ethercat driver already does most of what you are discussing. It would be a good place to start if you planned on building something.
On Sat, Jan 23, 2021, 2:24 PM John Dammeyer <[email protected]> wrote: > > From: Nicklas SB Karlsson [mailto:[email protected]] > > > > Den 2021-01-23 kl. 01:31, skrev John Dammeyer: > > >> From: andy pugh [mailto:[email protected]] > > >> On Fri, 22 Jan 2021 at 23:16, John Dammeyer <[email protected]> > wrote: > > >> > > >>> And I take it from your answer that this sort of driver at this > point in time does not exist. > > >> Not as far as I know, but it might be a fairly simple thing to create. > > >> It need to create HAL pins then gather the data from wherever, and put > > >> it on the HAL pins. > > >> > > >> -- > > > That's probably more of a patchy method. > > > > > > CANopen has a number of states and needs some sort of master to > co-ordinate the state changes. > > > INIT, PRE-OPERATIONAL and OPERATIONAL are the 3 main ones. There's > also an ERROR and STOPPING etc. > > > > If I remember correct CANopen devices start in pre-operational mode, a > > SYNC is usually sent periodically and just because of this. > > The start with a RESET status message. Then PRE-OP. The SYNC is not > needed or required. The transition to OPERATIONAL happens when the NMT > master decides it's ready for that. > > > > > > > Once devices are configured data in the PDOs need to be mapped in hal > > and this require some more driver support. > > > > > > It is probably also useful with SDO communication which is usually used > > to configure devices. Configuration may equally well may be done by > > external tool if CiA309-3 gateway is implemented, protocol is text but > > graphical user interface may communicate using it have, have a simple > > one currently hardcoded entries. > > I disagree. > > The full CANopen spec is designed to be infinitely configurable making > much of it very complicated. Dynamic configuration of devices on power up, > although possible isn't required for a fixed hardware product that doesn't > change. This adds complexity. > > Once I finish my mill cabinet upgrade and a few other projects I do intend > on getting back to my CANopen Lite project which includes an application > for working with CANopen messages. > > Things were going really well until I ran into the issue that the Lazarus > sockets library did not support SocketCAN the way that the C and Python > libraries do. Which means I have to upgrade sockets.pp first. And that's > where I stopped and restarted other unfinished projects. > > The attached screen shots show however that it did work with the Lawicel > CANUSB. This software is written with the "Write Once" "Compile anywhere" > model and therefore has been tested and runs on WIN-7, WIN-10, Raspberry > Pi3B, BeagleBone Black and LinuxCNC. > > CANopen Lite is designed to work as a simpler version of CANopen that > doesn't have all the bells and whistles that a full CANopen implementation > might. However it has been tested with COTS CANopen devices like displays, > battery chargers, and CANopen based servo motors. > > In addition to the desktop application there will be a number of different > CANopen device samples that demonstrate how to create say a display module, > relay module or I/O module etc. Maybe even a motor or two. > > Mapping HAL PINs into Object Dictionary locations is the easiest way to > deal LinuxCNC. A readable configuration file in the same way that the HAL > file is read on start-up is one way to populate the object dictionary with > the HAL PINs that someone will want made visible on the CAN bus. It will > all depend on how access to the PINs is granted at the core program level. > > Anyway, it's a work in progress. Be a few months before I can get back to > it and I really want access to Raspberry Pi HAT MCP2515 CAN devices and the > internal CAN devices in a Beaglebone Black. And for that, there's some low > level OS library work required. > > John Dammeyer > > > > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users > _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
