Device switch themselves automatically to pre-operational when they detect a loss of a heartbeat that they are consuming. In the past this was application code specific, but as the conformance test requires it, we moved this function into the stack. In CiA 447 this is only done for the loss of the gateway’s heartbeat. Reaction to other heartbeat losses remains application code specific.

For CiA 447 devices, the shut down sequence is now also initiated if a gateway is not present. As before, devices wait for the next wake-up message before they try to communicate again.

Micro CANopen customers with a current maintenance and support contract may download this latest version from our servers as described on the delivery note for each product.

It is our understanding that the reliability requirements for CiA 443 sub-sea applications are very high. Bootloaders are written and tested in a way that even power failures at any time or severe communication errors can not break the system. In worst case, an application is not programmed and a device remains in bootloader mode and is simply re-programmed again.

However, allowing the CAN bit rate to change with the currently specified mechanisms bears the risk of one or multiple devices failing. If in a CAN network devices are not configured to use the same bit rate, communication fails at a very low level. Devices will recognize that there are errors on the bus and potentially take themselves offline (bus off). If the devices are configured to use these different bit rates, then this error state can not be resolved.

How could such a situation occur?

The Layer Setting Services (LSS, see CiA 305) allow the setup of a bit rate, if all devices connected to a network support these services. Although the method of when exactly to do the bit rate change is very well specified and synchronized, the actual storing of this information (nodes copying this information to their local non-volatile memory) is not. It happens “one-by-one” and as no timings specified, this could be within seconds or even minutes. If there are severe bus communication errors during this time or even a power failure, then all devices will not have the same bit rate configured.

Possible solutions:

1.) Do not use switching of CAN bit rates by LSS, only use it for node ID assignments

2.) Use a power-on default bit rate. Any change to the bit rates is not stored in non-volatile memory, it is only temporary. With each reset or power cycle all devices fall back to their initial default bit rate.

3.) Use auto detect. Note: this only works if not all nodes are doing it, there must be at least one node communicating for the others to be able to do an auto detection. This feature is not available with all CAN controllers (requires passive listen-only mode).

4.) Check with CiA 305 group what else can be done to make the bit rate switch safer, for example by not only synchronizing the time of the physical switch, but also the time when this information is stored into non-volatile memory.

Until this is solved we recommend all existing systems to not make use of the bit rate switching by LSS.

• Messages can now be grouped together allowing for more logical viewing and keeping messages with similar uses together
• Cut, copy and paste supports moving and copying messages between the groups
• The order of the messages in a group can be manipulated to allow quicker and easier identification
• All messages in a group can be transmitted at once
• Sequential message transmission

In particular the sequential message transmission is a useful new feature. Repeatedly clicking on a button causes the next message in the group to be transmitted. When the last message in the group has been reached transmission resumes with the first message in the group. This allows complex sequences of messages to be constructed and then transmitted, for example to provide input stimuli to a node under test at a specific point in it’s operation or to mimic transmissions from a node that has not yet been developed.

Available in CANopen Magic Standard, Professional and Ultimate starting with version 6.10. Download the evaluation version.

08:30 to 09:30 Everything CAN and NXP CAN Controller Intro
A 30 year old technology, here to stay for another 30 years

An overview of the almost 30 year old CAN technology, where it came from and where it goes. CAN is used in many new electronic designs, also thanks to continuous advancements in CAN controller technology. Comparison of various CAN controller technologies.

09:45 to 10:30 CANopen Essence
New to CANopen? Learn the key features in just 45 Minutes

With its 4000+ pages the CANopen drafts and standards are overwhelming to newcomers. Join this class to get an overview of the common technical key features that make CANopen work.

11:30 to 13:00  Introduction to NXP CAN microcontrollers and Co-Processors
CAN controllers, CANopen Co-Processor, J1939 Co-Processor

Specialties of NXP CAN controllers and how an LPC11C24 can be used as a communication Co-Processor. Using the LPC11C24 with integrated CAN transceivers to implement a Co-Processor to implement and handle a higher-layer protocol, offloading this task from a host processor system. The host system communicates with the gateway via
UART, I2C or SPI.

Participants may qualify for a free NXP Evaluation Kit (must be present to qualify, 50 kits available).

For more information about the international CAN conference visit: www.can-cia.org

Recently CiA447’s functionality was enhanced and especially the new power-down and wake-up procedures required a version step upwards, as they are not backward compatible.

Today, Daimler is the only manufacturer already offering cars with CiA447 interface. However, several other car manufacturers have already shown prototypes.

One of the biggest benefits of CiA447 is, that it offers add-on electronics access to some of the cars displays and buttons. In modern cars, there is typically no physical room to add electronics near the dashboard, as all space is used up. CiA447 allows “sharing” some of the cars displays and buttons, so that the electronic components themselves do not need to be mounted near the dashboard.

We at ESAcademy have now updated all our CANopen products for CiA447 to implement the latest V2.0 enhancements and changes. This includes our Micro CANopen source code solutions, our CANopen Magic line of analyzers and our CiA447 gateway simulator. Contact us, if you need to bring CiA447 to your electronics.

The limits of speed vs. cable length comes from the requirement, that in CAN a bit needs to be stable on the entire bus, before the next bit may start. Some bits can be over-written, a feature which is used for arbitration, acknowledgments and error handling.

Bosch, the inventor of CAN, now introduced a white paper “CAN with Flexible Data-Rate” showing how a higher data rate can be achieved. The main suggested feature here is to allow switching between a low (backward compatible) bit rate and a much higher bit rate within a single message.

In short, a single CAN message consist of control data at the beginning and the end of a message with the data field “in the middle”. The core idea is to use the lower bit rate for the control data and the higher bit rate for the data field only. In addition the maximum data field size is increased from previously 8 bytes to now 64 bytes.

If the higher bit rate is 8 times higher than that of the base rate it would be possible to achieve an 8 times higher data-throughput WITHOUT changing the real-time behavior.

For more info, see the white paper at:
www.semiconductors.bosch.de/media/pdf/canliteratur/can_fd.pdf

• More clarity and easier maintenance in user-configurable files by dividing call back functions into multiple files
• More flexibility by adding many more data call backs for SDO accesses
• Framework support to guard Object Dictionary entries with auto-generated minimum and maximum values from EDS/DCF file

Customers with ongoing maintenance agreement with us are entitled to a free upgrade. In this case, please download the new version from

CANopenStore.com/support.php

using the activation code(s). For those projects using auto-generated code, also update CANopen Architect EDS to the latest version.

The process to update embedded firmware libraries that become part of a bigger project can be complicated. For that reason, we have developed tools and to ease this on-time task.

Contact us if you are interested in obtaining or need assistance in performing the update.

The standard supports electronic devices used in taxis, emergency response vehicles and other governmental service vehicles. Typical components include roof bars (light & sound), radios, control units, taximeters, printers and similar devices.

Using a CiA447 gateway, automotive manufacturers like Daimler already provide access to the vehicles internal data today. The standard allows sharing some of the car’s resources like switches and displays with CiA447 devices. A steering wheel button can be used as the PTT (push to talk) button for a radio, which in return can use the car’s display to show channel numbers, volume settings or such.

ESAcademy now provides a CiA447 gateway simulation software, which greatly eases the development of CiA447 compatible devices. Engineers no longer need the car or a physical mock-up of the gateway to work on their developments. The gateway simulation is based on the same software that is used in the gateways of various automotive manufacturers. It allows CiA447 compatible devices to access the cars’ data, like dashboard components (buttons, displays).

The simulation can also ‘re-play’ tours, which are simulations of drives along a specific route. The tour data visible on the network includes engine and location (GPS) data.

The software is available at http://www.canopenstore.eu/CiA447GatewaySim (European Union) and http://www.canopenstore.com/pip/cia-447-gateway-simulation.html (rest of the world).

Visit the Texas Instruments site MSP430 LaunchPad (MSP-EXP430G2) to learn more.