> From: Curtis Dutton [mailto:curtd...@gmail.com] > 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. > Thanks for the feedback Curtis. I have a CANUSB from Lawicel in Sweden that functions as a serial port. To get it to send CAN messages you do a couple of things: 1. Send it an S5 with a CR character. That sets the bit rate to 250kbps. 2. Send it an O with a CR character. That Opens the device. At this point it's able to receive messages so it reports lines of text that look like this: t70020100 CR which means t = Standard 11 bit ID message ID=700 which is from NMT master. DLC=2 which means there are two bytes 01 means GO_OPERATIONAL 00 means Everyone. CR character at the end.
Once a node like the LinuxCNC with say ID 0x36 is OPERATIONAL it sends a text string to the CANUSB which looks like t736105 CR t = Standard 11 bit ID message ID=736 which is heartbeat status (7xx) from node 36 DLC=1 which means there is one byte 05 means Node #36 (LinuxCNC) is OPERATIONAL. CAN message sent with the receipt of the CR character. This message should show up once per second. Now it's true that under Linux the socketCAN has methods with either C or Python to do this with sockets to the CANUSB dongle. But say I just wanted to have a module that used the serial port without the socketCAN overhead. Like say MODBUS to a USB to Serial Dongle. Is there a particular example; Documentation, Code for periodic transmission of serial messages and receiving serial messages. To take the above simple CANopen one step further periodic messages like for example once per second and on change a message like t328103 This is called a PDO message to Node 0x28 with 1 byte telling it that Relays 1 and 2 need to be ON. If Relay 1 needs to be switched off an async message is sent and then the subsequent periodic messages look like this: t328102 The HAL output pins for those two relays need to be reflected in that message. There might also be messages received like t3A820205 It's from the node with the relays and the first byte represents the relay status (0x3A8 & 0x07F = 0x28 Node ID) in the first byte showing only Relay 2 is ON and the second byte shows Bits 0 and 2 are set representing inputs 1 and 3 are currently ON. It's that information about inputs 1 and 3 that need to show up as HAL input pins. That's it. You now have CANopen control of a module with up to 8 relays and 8 inputs. Again the PDO message 0x380 + NodeID 0x28 might show up once per second and on a change in status. So how easy is it to add those simple messages out to a serial port to mirror HAL pins? > On Sat, Jan 23, 2021, 2:24 PM John Dammeyer <jo...@autoartisans.com> wrote: > > > > From: Nicklas SB Karlsson [mailto:nk@nksb.online] > > > > > > Den 2021-01-23 kl. 01:31, skrev John Dammeyer: > > > >> From: andy pugh [mailto:bodge...@gmail.com] > > > >> On Fri, 22 Jan 2021 at 23:16, John Dammeyer <jo...@autoartisans.com> > > 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
