Re: [Emc-users] CANopen: SOEM/SOES, CANfestival, anything more? --> Not fast enough
On Sat, 9 Mar 2019 10:59:15 -0800 "John Dammeyer" wrote: > Hi Nicklas > > When CANopen first came out I was quite resistant to the protocol. But as > I've used it more I've come to appreciate it's positives. A lot of COTS > devices out there don't support the whole concept of everything configurable > with files and on power up. But it doesn't really matter. Agree. > And although CANopen is really good as a PLC replacement and the number of > devices that now are compatible makes doing projects very simple there are > other areas where it just wouldn't work. Ethercat is probably better for > full axis control. I use CANopen with PLC. I have chosen Ethercat for full axis control but also have a CAN connector if needed. Nicklas Karlsson ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] CANopen: SOEM/SOES, CANfestival, anything more? --> Not fast enough
Hi Nicklas When CANopen first came out I was quite resistant to the protocol. But as I've used it more I've come to appreciate it's positives. A lot of COTS devices out there don't support the whole concept of everything configurable with files and on power up. But it doesn't really matter. And although CANopen is really good as a PLC replacement and the number of devices that now are compatible makes doing projects very simple there are other areas where it just wouldn't work. Ethercat is probably better for full axis control. The system on my home page is an example of a real mixed CAN project. Two controllers each with 5 CAN channels. USB interface to the PC for each. With a limit of 120 nodes maximum on any single CAN bus (driver issues) and the mechanical infrastructure set up as thirds the 150 lamps (PIC 18F series) were broken into 3 groups of 50 per ring. With 5 rings that's 750 lamps per side for a total of 1500 lamps. CAN bridges were used between the controller and the groups of fifty. Coincidently they had the same M9S12 processor we used in the controller so they had an extra CAN port available that was CANopen compatible. So PC -> USB -> M9S12 -...> 5 CAN channels Each CAN channel to Bridge ...-> 3 CAN channels to 50 lamps. Each Bridge also PC -> USB -> CAN4USB to all 10 Bridges with CANopen. The lamps periodically reported temperature and voltage and could be queried for their serial number. The node ID of the lamp could be programmed by sending a broadcast message with the serial number and new node number. Another broadcast message for all nodes could also ask the lamp with a specific serial # what its node # was. If a lamp was installed out of place it didn't require physical access at the end of a long arm bucket to switch out a lamp. The CANopen access allowed us to collect other statistics on CAN activity. The lamps were refreshed at a CINE camera rate of 24Hz which can be sample in such a way that film cameras, 50Hz European and 60Hz North American video would not result in a flickering effect due to refresh rates. This was an example where a custom high level protocol was the only solution. I've also been shipped around the world to a few places to fix custom CAN protocols that broke rules and resulted in the equipment not working well. John Dammeyer http://www.autoartisans.com > -Original Message- > From: Nicklas Karlsson [mailto:nicklas.karlsso...@gmail.com] > Sent: March-09-19 10:00 AM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] CANopen: SOEM/SOES, CANfestival, anything > more? --> Not fast enough > > > So CANopen is way different. Far more jitter. If you figure that the > average 8 byte CAN message is really closer to 135 bits with bit stuffing and > CRC each message at 1Mbps is 135 uS. That's only 7.4khz. Even if you used > less data and managed to keep the bit stuffed messages under 64 bits that's > still 64 microseconds and 15.6kHz. Not fast enough for step/direction > messages. > > > > John Dammeyer > > http://www.autoartisans.com > > Speed is certainly a problem on several axis and why I will not use CAN but I > want however use CANopen message format over other networks. > > > 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
Re: [Emc-users] CANopen: SOEM/SOES, CANfestival, anything more? --> Not fast enough
> So CANopen is way different. Far more jitter. If you figure that the > average 8 byte CAN message is really closer to 135 bits with bit stuffing and > CRC each message at 1Mbps is 135 uS. That's only 7.4khz. Even if you used > less data and managed to keep the bit stuffed messages under 64 bits that's > still 64 microseconds and 15.6kHz. Not fast enough for step/direction > messages. > > John Dammeyer > http://www.autoartisans.com Speed is certainly a problem on several axis and why I will not use CAN but I want however use CANopen message format over other networks. Nicklas Karlsson ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] CANopen: SOEM/SOES, CANfestival, anything more?
Oh and here's a link to a logic analyzer screen shot of CANbus Arbitration. The two bottom modules are both trying to send at the same time. The top module just receives and at the end of the message inserts the ACK bit. The two bottom pairs arbitrate with the bottom module releasing the bus, receiving the message and also sending the ACK bit and then retrying the transmission. Classic CAN. http://www.autoartisans.com/canrf/images/rf-arb.jpg It's not a really fast bit rate because it was done with my CANRF hardware which used ON OFF KEYING (OOK) at 916.5MHz to send wireless CAN. That project was scrapped after ZigBee came out. John Dammeyer http://www.autoartisans.com > -Original Message- > From: Nicklas Karlsson [mailto:nicklas.karlsso...@gmail.com] > Sent: March-09-19 8:37 AM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] CANopen: SOEM/SOES, CANfestival, anything > more? > > > ... > > For more hard real time applications the MilCAN protocol is more ideal > because all the messages are synchronized to SYNC FLAG messages and the > arbitration is limited to within a SYNC FLAG period avoiding jitter on > messages. But there's pretty well nothing available commercially for > MilCAN unfortunately. > > CANopen have a SYNC message, this is not as good as SYNC FLAG? > > > > > Where CAN bus systems really excel in automation is for things like tool > changers and part loaders/unloaders, control of coolant and other devices > etc. > > Sound reasonable. I plan to use it over Ethercat, its just to get some kind of > standarized message for configuration or whenever there is a need to > communicate with the device. > > > Still one of the best books on CANopen is this one. Looks like it's back in > print too. I've used it to create a master CANopen Stack. > > https://www.canopenbook.com/ > > Nice picture, I will try to look at it. > > > Regards 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
Re: [Emc-users] CANopen: SOEM/SOES, CANfestival, anything more?
No it's not but that's because MilCAN breaks a very fundamental rule of the CAN bus protocol. A bit of background. CSMA/CD used in the original coax based Ethernet stands for Carrier Sense, Multiple Access with Collision Detection. Each node would listen on the bus and if free would start to transmit. If another node also started to transmit at exactly the same time they would both back off for a random time and retry. This worked well up to about 50% bus utilization and then resulted in a saturated bus with very little data getting through. CAN bus also does carrier sense but starts off sending with an ID portion that is either 11 bits or 29 bits. The rule for CAN is no device may transmit the same ID and the lower the ID in value the higher the priority. So if two nodes start transmitting at exactly the same time the moment one of the ID bits transmitted is a 1 but is read back as a 0 that node backs off and switches into receive mode. Once the message is finished it tries again. That's called Collision Recovery hence the CSMA/CR. I'll see if I find a scope grab of that and post it. The CAN bus protocol also detects errors in the bit pattern and any node that detects and error can destroy the message forcing the sender to retry. It's done with bit stuffing and a sequence of bits longer than the stuff interval (called an Error Flag). Anyway. Back to MilCAN which doesn't allow retransmission of a message when it's been flagged as bad. Not all CAN hardware even supports that. And the system master that sends this SYNC FLAG includes a counter from 0 to 1023 that is incremented with each message wrapping around to 0 after the one that has 1023. There are both synchronous and asynchronous messages in MilCAN. The Synchronous ones are programmed to be sent during a specific SYNC FLAG value or multiple of. So say every 16 or 8 or 32 along with an offset. So one message might be sent every 16 SYNC FLAGs offset by 3. So on 3, 19, 35, ... Another might also be every 16 but offset by 5. So 5, 21, 37,... The system architect designs and allocates the messages in such a way that the messages never really arbitrate so they never need to retry and if they are corrupted they wait until the next SYNC FLAG. What you have then is each device receiving a SYNC FLAG and if it matches it immediately sends what's it's programmed to send. The system architect must not pack in too many messages in one SYNC FLAG interval. That's because you also need to deal with ASYNC messages like alarms. But even those are throttle by the SYNC FLAGS. They are only allowed onto the bus after a SYNC flag is received. That prevents the SYNC FLAG message from ever being arbitrated or held off because another message has control of the bus. The CS part of the Carrier Sense isn't really required for the SYNC MASTER. And that's why the ERROR flags and retries aren't allowed. Under this protocol it would be illegal for a message to show up at the end of the SYNC FLAG period and overlap into the next. Either by being sent or being retried. On one project I was require to delay the synchronous messages after a SYNC FLAG by about 1/3 of the SYNC Period. That was to allow no arbitration for the ASYNC messages that might show up at the beginning of the interval. Not only that, I had to track where I was within the SYNC FLAG frame and if asynchronous messages had shifted my starting point for my synchronous message I wasn't allowed to transmit any that might overlap the time point where the next SYNC FLAG would be sent. So CANopen is way different. Far more jitter. If you figure that the average 8 byte CAN message is really closer to 135 bits with bit stuffing and CRC each message at 1Mbps is 135 uS. That's only 7.4khz. Even if you used less data and managed to keep the bit stuffed messages under 64 bits that's still 64 microseconds and 15.6kHz. Not fast enough for step/direction messages. John Dammeyer http://www.autoartisans.com > -Original Message- > From: Nicklas Karlsson [mailto:nicklas.karlsso...@gmail.com] > Sent: March-09-19 8:37 AM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] CANopen: SOEM/SOES, CANfestival, anything > more? > > > ... > > For more hard real time applications the MilCAN protocol is more ideal > because all the messages are synchronized to SYNC FLAG messages and the > arbitration is limited to within a SYNC FLAG period avoiding jitter on > messages. But there's pretty well nothing available commercially for > MilCAN unfortunately. > > CANopen have a SYNC message, this is not as good as SYNC FLAG? > > > > > Where CAN bus systems really excel in automation is for things like tool > changers and part loaders/unloaders, control of coolant and other devices > etc. > > Sound reasonable. I plan to use it over Ethercat, it
Re: [Emc-users] CANopen: SOEM/SOES, CANfestival, anything more? --> Configuration
On Sat, 9 Mar 2019 08:42:12 -0800 "John Dammeyer" wrote: > There is a way to configure CANopen modules on power up. The CANopen master > (or some other node delegated to do this) configures locations in a devices > object dictionary. This is all done before the CANopen master changes the > system from PRE-OPERATIONAL to OPERATIONAL. Yes I know about it. I am thinkging about how to communicate information in between configuration files and HAL. Make available mapping entries as HAL parameters might be an option. Then parameters may be used to configure device during startup and HAL would add pins configuration expect should be available. Then I look into my driver code parameters are read then pins are added so this should be OK. There is an error if pins are not found but running linuxcnc and scanning for devices before configuration with pin connnections are done should also be possible. Nicklas Karlsson ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] CANopen: SOEM/SOES, CANfestival, anything more? --> Configuration
There is a way to configure CANopen modules on power up. The CANopen master (or some other node delegated to do this) configures locations in a devices object dictionary. This is all done before the CANopen master changes the system from PRE-OPERATIONAL to OPERATIONAL. So a device can be configured to place encoder values into TPDO1 at bytes 3..6 and report that periodically and/or only when changed. Once set OPERATIONAL that device now broadcasts the information. It can also have a suppression value that prevents massive numbers of messages from overrunning the bus. Like report on change but no more often than every 10mS. On the receive side it's much the same. Now called an RPDO1 the configuration for that PDO is set up to direct bytes 3..6 from that message into a specific memory location of the Object Dictionary (OD). The Object Dictionary is configured as an Index:SubIndex. Generally in Hex format as say 4000:12 where the index is 16 bits and the subindex is 8 bits. The size of the object is also defined in the Object Dictionary so it could be as simple as one byte or 4 bytes or even be a pointer to a string or array and require multiple byte PDO messages to transfer data. Since this could all be configured on power up it there could be a translation program from HAL to OD. And as per my previous posting this is where I start to get lost as to how the HAL ultimately is configured and used to abstract hardware from the software. BTW, CANopen also has a Service Data Object message (SDO) which is used as a request/answer protocol. In either case when the value is written into the OD it doesn't just have to be data written to a location. It can also be a function that is called with that data. Or to read from the OD the read doesn't actually access a location but calls a function that perhaps generates an I2C message to hardware to pull out an A/D value. That value is then returned as the SDO reply. John Dammeyer http://www.autoartisans.com > -Original Message- > From: Nicklas Karlsson [mailto:nicklas.karlsso...@gmail.com] > Sent: March-09-19 8:05 AM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] CANopen: SOEM/SOES, CANfestival, anything > more? --> Configuration > > During configuration there are no possibility to pass a string from the *.ini > or > *.hal file? Only possibility is parameters and hal pins? > > > > > Several library options, some tests done by Luminize in Machinekit. > > > > > > https://github.com/machinekit/machinekit/issues/589 > > > > https://github.com/luminize/canopen-machinekit > > > > ___ > > 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 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] CANopen: SOEM/SOES, CANfestival, anything more?
> ... > For more hard real time applications the MilCAN protocol is more ideal > because all the messages are synchronized to SYNC FLAG messages and the > arbitration is limited to within a SYNC FLAG period avoiding jitter on > messages. But there's pretty well nothing available commercially for MilCAN > unfortunately. CANopen have a SYNC message, this is not as good as SYNC FLAG? > > Where CAN bus systems really excel in automation is for things like tool > changers and part loaders/unloaders, control of coolant and other devices etc. Sound reasonable. I plan to use it over Ethercat, its just to get some kind of standarized message for configuration or whenever there is a need to communicate with the device. > Still one of the best books on CANopen is this one. Looks like it's back in > print too. I've used it to create a master CANopen Stack. > https://www.canopenbook.com/ Nice picture, I will try to look at it. Regards Nicklas Karlsson ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] CANopen: SOEM/SOES, CANfestival, anything more?
On 03/09/2019 07:05 AM, Nicklas Karlsson wrote: I will look at it, Machinekit use older version of Linuxcnc? or have caught up? Machinekit has diverged from LinuxCNC a bit, but it is not all that old. It has many of the important updates from a few years ago, like the trajectory planner. Jon ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] CANopen: SOEM/SOES, CANfestival, anything more?
I've been working with CANopen for the last 20 years or so and with CAN from 1992. Microchip has a CANopen slave stack that you look at although it's optimized for space and speed which means it's not optimized for readability. CANopen isn't really great a real time due to the arbitration CSMA/CR approach. But having said that I've written programs that turn both CANopen DC Servos and get feedback from Absolute encoders. Also ran a small CANopen Step Servo a while ago and pulled data from inclinometers. For more hard real time applications the MilCAN protocol is more ideal because all the messages are synchronized to SYNC FLAG messages and the arbitration is limited to within a SYNC FLAG period avoiding jitter on messages. But there's pretty well nothing available commercially for MilCAN unfortunately. Where CAN bus systems really excel in automation is for things like tool changers and part loaders/unloaders, control of coolant and other devices etc. Still one of the best books on CANopen is this one. Looks like it's back in print too. I've used it to create a master CANopen Stack. https://www.canopenbook.com/ John Dammeyer www.autoartisans.com > -Original Message- > From: Nicklas Karlsson [mailto:nicklas.karlsso...@gmail.com] > Sent: March-09-19 2:59 AM > To: emc-users@lists.sourceforge.net > Subject: [Emc-users] CANopen: SOEM/SOES, CANfestival, anything more? > > DS402 profile is common for motion control both on ordinary CAN networks > and CANopen over Ethercat. It would most certainly be of great use to have > support for it and other communication profiles like encoder in Linuxcnc. > > I am currently looking on implementation on Ethercat there SOEM/SOES as > is used for CANopen over Ethercat. I also found CAN festival. Do anybody > know about more freely available CANopen implementations? > > > 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
Re: [Emc-users] CANopen: SOEM/SOES, CANfestival, anything more?
There certainly seems to be some more to get. I have also done some tests with
Ethercat and ordinary Ethernet but no ordinary CAN. I also made a small
currently hard coded configuration utility and a partial implementation of CiA
309-3 as a gateway integrated in Linuxcnc.
Implementation of CiA 309-3 integrated in Linuxcnc for configuration feels like
a relatively good solution.
As is now i Hardcoded available variables/signals available in PDO messages
sent periodically. Which variables/signals available in PDO is available need
to come from configuration file as well as mapping (COB-ID, type, position,
length) or probably better expressed as during PDO mapping.
This is the structure I currently say should be available via Ethercat there I
hardcoded message format.
typedef struct{
hal_s32_t* positionCnt;
hal_float_t* positionPos;
hal_s32_t* encoderCnt;
hal_float_t* encoderPos;
hal_float_t scale;
hal_u32_t* control;
hal_bit_t* control_enable;
hal_bit_t* control_out1;
hal_bit_t* status_home;
hal_bit_t* status_switch1;
hal_bit_t* status_switch2;
hal_bit_t* status_switch3;
hal_u32_t* status;
} hal_mem_type;
static hal_mem_type* hal_mem = NULL;
I guess I could fix mapping and hal_malloc(...) is used to allocate memory. Any
good idea howto build a list of available variables from configuration file?
On Sat, 9 Mar 2019 09:03:07 -0300
Daniel Scheeren wrote:
> Several library options, some tests done by Luminize in Machinekit.
>
>
> https://github.com/machinekit/machinekit/issues/589
>
> https://github.com/luminize/canopen-machinekit
>
> ___
> 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
Re: [Emc-users] CANopen: SOEM/SOES, CANfestival, anything more?
I will look at it, Machinekit use older version of Linuxcnc? or have caught up? > Several library options, some tests done by Luminize in Machinekit. > > > https://github.com/machinekit/machinekit/issues/589 > > https://github.com/luminize/canopen-machinekit > > ___ > 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
