Difference between revisions of "CAN Control Release Notes"

From OpenMotics
Jump to navigation Jump to search
 
(3 intermediate revisions by the same user not shown)
Line 10: Line 10:
  
 
Please also note that the OpenMotics Core and Core+ uses a different firmware version, see [[CAN Control Release Notes Core/Core+]]
 
Please also note that the OpenMotics Core and Core+ uses a different firmware version, see [[CAN Control Release Notes Core/Core+]]
 +
 +
== V4.1.24 ==
 +
Date: 22/5/2020
 +
 +
=== Resolved bugs ===
 +
* Too many messages (and too fast) send by the Can Control on the Dali Bus (for example all lights off) could lead to missing Dali messages on the Bus:
 +
** Improved non-blocking Dali send mechanism added
 +
** Before sending a new Dali message, the Can Control will wait until the slave Dali device responded or a timeout occurred
 +
** During DALI sending, sometime RS485 Bus error occurred, this is also resolved by the above solution
 +
** RAM is re-organised to free up memory for the DALI Transmit queue
 +
 +
=== Added functionality ===
 +
* RS485 improved switching between send and receive
  
 
== V4.1.21 ==
 
== V4.1.21 ==

Latest revision as of 13:28, 22 May 2020

Contents

General

The CAN Control module firmware is published as Open Source since firmware release V1.3.20. Below you'll find all the changes since that release.

The firmware updates happening in the Openmotics Cloud (Settings - Update) contain not only the firmware update of the Master, but also the firmware of other modules as well as the updates for the Beagle Bone Black. All these different firmware updates are assembled in a package which gets a general version number. This version number which you see in the portal is not the same as the Firmware Version of the CAN Control module.

Interested to know how to use the CAN Control module? See the CAN Control Installation pages and Hardware Installation Guide

  • "sensor indicate" and "input indicate" did not work properly for Micro CAN modules connected to the CAN Control. This release solves this issue

Please also note that the OpenMotics Core and Core+ uses a different firmware version, see CAN Control Release Notes Core/Core+

V4.1.24

Date: 22/5/2020

Resolved bugs

  • Too many messages (and too fast) send by the Can Control on the Dali Bus (for example all lights off) could lead to missing Dali messages on the Bus:
    • Improved non-blocking Dali send mechanism added
    • Before sending a new Dali message, the Can Control will wait until the slave Dali device responded or a timeout occurred
    • During DALI sending, sometime RS485 Bus error occurred, this is also resolved by the above solution
    • RAM is re-organised to free up memory for the DALI Transmit queue

Added functionality

  • RS485 improved switching between send and receive

V4.1.21

Date: 13/4/2020

Resolved bugs

  • Improved detection of new modules virtual modules has been added
  • Improved Dali decoding
  • RS232 RX led indicate any receiving Dali information
  • Improved indication of new virtual modules: The status CAN led would not always flash when a new virtual module was detected.
  • The firmware supports the use of an external debug test print to troubleshoot Dali

Added functionality

V4.1.19

Date: 7/4/2020

Resolved bugs

  • UART2 is used for all Dali communication. In this version, better error handling is added for this UART port in case of UART Frame and UART overrun errors.

Added functionality

V4.1.18

Date: 11/3/2020

Resolved bugs

  • Helvar Dali motion sensors didn't work, this release solves this issue.
  • Motion sensors didn't always report their changes to the master, this release also solves this issue

Added functionality

V4.1.15

Date: 4/2/2020

Resolved bugs

Added functionality

  • Additional CAN self healing routines have been added to improve CAN 1.2 and 2.0 stability. When temperature sensors are not responding for a certain amount of time, the CAN stack is restarted, when this doesn't resolve the issue, the module will perform a reset.

V4.1.7

Date: 18/11/2019

Resolved bugs

Added functionality

  • The hardware V3 (new hardware with new connectors) will have a button on the top panel. This firmware supports the extra button.

V4.1.6

Date: 1/11/2019

Resolved bugs

Added functionality

V4.1.5

Date: 21/10/2019

Resolved bugs

Added functionality

  • The necessary instructions and support is added to boatload a Micro CAN over the CAN Control
  • Automatic Error detection and resolving of the CAN bus is added to improve stability
  • CAN protocol 2.0 is added which supports the new Micro CAN
    • CAN protocol 1.2: Micro CAN's with firmware version 1.x.x works with CAN protocol 1.2 and can only be connected on the CAN Control.
    • CAN protocol 2.0: Micro CAN's with firmware version 2.x.x works with CAN protocol 2.0 and can be connected on the CAN Control AND the AIO. Micro CAN's in CAN protocol 2.0 have a unique address so the double addressing issue is solved.
  • Automatic detection of CAN protocol 1.2 and CAN protocol 2.0 is added. A mix of Micro CAN's 1.2 and 2.0 is not supported.
  • Dali Inputs (like motion sensors) are supported in this release, see Setup Individual DALI Inputs

V3.1.37

Date: 1/11/2019

Resolved bugs

Added functionality

V3.1.36

Date: 3/7/2019

Resolved bugs

  • Sometimes, the uCAN leds gets the wrong minimum/maximum brightness resulting in uCAN leds that doesn't work properly anymore. This version adds additional checks before applying a change in led brightness.

Added functionality

V3.1.35

Date: 15/5/2019

Resolved bugs

  • When a uCAN is removed from the bus without resetting the CAN control, the last sensor values remained in memory. This release will check the number of failed sensor requested and remove the sensor when the number of failures is above the threshold programmed in eeprom (see Memory mode Page 0 Byte 58)

Added functionality

V3.1.34

Date: 10/3/2019

Resolved bugs

  • "sensor indicate" and "input indicate" did not work properly for Micro CAN modules connected to the CAN Control. This release solves this issue

Added functionality

V3.1.33

Date: 31/12/2018

Resolved bugs

  • Sometimes, during initialisation, double inputs and sensors could be detected. This version resolves this issue.
  • This version also improves the use of the sending CAN queue

Added functionality

V3.1.30

Date: 19/10/2018

Resolved bugs

  • The RS485 bus instruction "FX" gave CRC errors. This release resolves this bug.

Added functionality

  • The RS485 bus instruction "FX" has been extended with also a partial erase (only inputs or sensors)

V3.1.27

Date: 7/10/2018

Resolved bugs

  • This version improves the CAN led behaviour. In some circumstances, the CAN leds did not follow the programmed outputs.

Added functionality

V3.1.25

Date: 23/8/2018

Resolved bugs

  • Some none existing sensors could appear with fake values. This is resolved in this version.

Added functionality

V3.1.24

Date: 21/8/2018

Resolved bugs

Added functionality

  • RS485 instruction "FX" has been added which performs a factory reset including the erase of the internal and external eeprom.

V3.1.23

Date: 27/7/2018

Resolved bugs

  • With a higher amount of micro CAN modules, the programmed leds did not always follow the programmed outputs resulting in a wrong state of the leds. This is resolved in this release.

Added functionality

V3.1.22

Date: 3/3/2018

Resolved bugs

Added functionality

  • Functionality is added so all leds can be updated by receiving a broadcast message of the Master (F3.143.34 or higher)
  • When a micro CAN has reported a watchdog timer reset, all CAN leds will be updated automatically

Known Issues

  • The factory reset isn't working: When the init button is pressed at startup, the bootloader detect this and keeps the processor in bootloader and will not erase the eeprom of the CAN control.

V3.1.20

Date: 15/11/2017

Resolved bugs

Added functionality

  • CAN protocol is extended with messages for the watchdog timer of the micro CAN modules

Known Issues

  • The factory reset isn't working: When the init button is pressed at startup, the bootloader detect this and keeps the processor in bootloader and will not erase the eeprom of the CAN control.

V3.1.18

Date: 18/9/2017

Resolved bugs

  • Sometimes, the temperature is available on the micro CAN (green led) but the CAN control refuses the value. This version resolves this problem

Added functionality

  • None

Known Issues

  • The factory reset isn't working: When the init button is pressed at startup, the bootloader detect this and keeps the processor in bootloader and will not erase the eeprom of the CAN control.

V3.1.17

Date: 8/6/2017

Resolved bugs

  • None

Added functionality

  • The messages of the input modules sent by the master (which are captured by the CAN Control) will also contain output data which allows better consistency of the micro CAN leds. In order to work, the Master needs at least Firmware version 3.143.28

Known Issues

  • The factory reset isn't working: When the init button is pressed at startup, the bootloader detect this and keeps the processor in bootloader and will not erase the eeprom of the CAN control.
  • Sometimes, the temperature is available on the micro CAN (green led) but the CAN control refuses the value.

V3.1.15

Date: 7/5/2017

Resolved bugs

  • DALI outputs didn't, in some rare circumstances, generate virtual outputs
  • The CAN control generates less error messages on the bus

Added functionality

  • The CLI instruction "discover can control" is supported by this version
  • The CLI instruction "eeprom activate" and the corresponding API instruction will also activate the copy of the latest eeprom values to RAM in the CAN control. This allows the gateway to faster activate functions after eeprom copying of certain pages.

Known Issues

  • The factory reset isn't working: When the init button is pressed at startup, the bootloader detect this and keeps the processor in bootloader and will not erase the eeprom of the CAN control.

V3.1.11

Date: 30/4/2017

Resolved bugs

  • When 3 or 4 CAN controls were used in large environments, a timing issue could occur resulting the last discovered virtual modules not to be added in eeprom memory of the CAN module. When power reset occurred, the virtual module was not known anymore by the CAN control so the master would not get any information back from that virtual module and this generated errors on the bus. This version resolves this bug.

Added functionality

  • This version is used together with the Openmotics Bootloader

Known Issues

  • The factory reset isn't working: When the init button is pressed at startup, the bootloader detect this and keeps the processor in bootloader and will not erase the eeprom of the CAN control.

V1.4.45

Date: 28/2/2017

Resolved bugs

  • When adding CAN micro modules, less then 8 inputs were not visible in the system. This bug has been resolved.

Added functionality

  • The code has been enhanced to support the Openmotics boot loader
  • The code has been modified so the CAN Control will behave as an input module so even when no micro CAN modules are connected, the synchronisation of the eeprom already starts after adding the CAN Control module.
  • The code has been enhanced so Output modules (Relay, Dim and Roller/Shutter) can be easily added later on
  • Support for DALI output modules has been added, see DALI Installation Guide

Known Issues

  • None

V1.3.44

Date: 17/1/2017

Resolved bugs

  • The input indicate led function works in any circumstance now

Added functionality

  • The CAN controller will, when communication stalls, reset the power of the CAN slaves.

Known Issues

  • None

V1.3.42

Date: 24/12/2016

Resolved bugs

  • None

Added functionality

  • During initialization, the input type is also transmitted to the master so in other words, the Master knows the difference between a normal input and temperature module and a module that's been generated by the CAN control. In the Memory Model, Page 2-31 on byte 252, the module type is programmed.
  • Faster synchronization between the Master and the CAN control so the Led functionality should already work within 1 to 2 minutes after initialization (depending on the number of output modules that needs to be synchronized).

Known Issues

  • In some circumstance, the input indicate function doesn't work properly

V1.3.40

Date: 21/11/2016

Resolved bugs

  • Virtual outputs can trigger CAN leds now

Added functionality

  • The CAN control supports the Master Basic Actions 212 to 219 (works with Master Firmware F3.142.18 or higher):
    • Switch on/off individual CAN leds by using Basic Actions
    • Set the Minimum and Maximum brightness of all CAN leds by using Basic Actions
  • The led functionality on the front panel has been corrected, see Leds CAN Control
  • The factory reset function (press the init button for more then 5 seconds) has been modified so both the processor eeprom as the external eeprom (in the CAN control module) will be erased
  • This firmware also supports multiple CAN control modules

Known Issues

  • None

V1.3.33

Date: 4/11/2016

Resolved bugs

  • The buffer allocation routine has been adapted so the All off functionality (and the leds that needs to follow) works

Added functionality

  • The Minimum and Maximum Brightness can be adapted by changing the eeprom values Page0/Byte31 (Minimum Brightness Level) and Byte32 (Maximum Brightness Level). For more information, see Memory Model Eeprom Page0/Byte31-32.

Known Issues

  • Virtual outputs can't trigger CAN leds yet

V1.3.32

Date: 7/10/2016

Resolved bugs

  • The led output follow bug of Release V1.3.28 has been solved

Added functionality

  • This firmware will add led functionality linked to the number of lights or the number of outputs that are ON (see Memory Model eeprom page 229)

Known Issues

  • When many lights are ON and the All off functionality is used, some leds may not follow the output due to a buffer limitation
  • Virtual outputs can't trigger CAN leds yet

V1.3.28

Date: 5/9/2016

Resolved bugs

  • The Slow, Medium and fast flashing of the leds is working now

Added functionality

  • This firmware will support the new CAN Micro
  • The CAN control will now sent keep alive messages on the CAN bus

Known Issues

  • A bug in the led functionality is reported so not all programmed leds follow the output
  • Virtual outputs can't trigger CAN leds yet

V1.3.20

Date: 21/8/2016

Resolved bugs

  • Errors on the Bus: In this release, the number of errors on the bus is brought down to zero by modifying the I2C Master routines in to state machines

Added functionality

  • Eeprom function: The Master will sent over all the eeprom data which will be stored in the eeprom of the CAN gateway (Master Firmware V3.142.13 or higher is needed)
  • Sniffer function: The CAN Gateway will interprete all the RS485 messages and will keep track of all input, output and sensor states. This information can be used to trigger several CAN bus actions (Master Firmware V3.142.13 or higher is needed).
  • CAN Led function: Each output can trigger up to 4 leds. These leds can be programmed in the Eeprom of the Master starting at Page 221, see Memory Model for the the details.
  • CAN Led indicate function: By using the "input indicate" function, the leds can give an indication which input is linked to the switch and led.
  • CAN sensor indicate function: By using the "sensor indicate" function, the leds can give an indication which sensor is linked to module (all leds of that module will start flashing for more than a minute).

Known Issues

  • The Slow, Medium and fast flashing of the leds is not yet working. Also the flashing of leds doesn't occur at the same speed.
  • Virtual outputs can't trigger CAN leds yet