Health
Health Clamped Maximum Command
Both the temperature monitor and host sentry may impose an internal limit on the incoming i_d, i_q, v_d and v_q signals as they enter the active controllers.
The health clamp scales output of the controllers and is derived as the minimum of the cases described below.
Internal Temperature Limit Case
In the internal temperature limit case the commands are limited once the highest on-board electronics temperature reading goes past temperature_penalty_limit_l.
Once the temperature moves beyond this limit the output scale reduces proportionally from 1.0 to temperature_penalty_scale_l as the temperature increases from temperature_penalty_limit_l to temperature_penalty_limit_h.
The output scale is clamped at temperature_penalty_scale_l if the temperature moves beyond temperature_penalty_limit_h.
Query if the device is temperature clamped by reading boolean parameter temperature_penalty_ctrl_is_clamped.
The op_state warning bit Temperature dependent current clamp flag is asserted if the device is temperature clamped.
Default values are:
| Parameter | Type | Required | Description |
|---|---|---|---|
temperature_penalty_limit_h |
float32 | Optional | Upper temperature at which maximal penalty is applied (degC). Default value: "Hardware maximum temperature" |
temperature_penalty_limit_l |
float32 | Optional | Lower temperature at which minimal penalty is applied (degC). Default value: "Hardware maximum temperature" - 10degC |
temperature_penalty_scale_l |
float32 | Optional | Lower command scale at maximum temperature penalty. Default value: 0.1 |
temperature_penalty_ctrl_is_clamped |
bool | Optional | Read only. True if the controller is temperature clamped, Default value: false |
When in controller mode current_dq the maximum device current multiplied by the scale value is output via JCS signal i_dq_cmd_clamp.
This can be connected to higher level controllers (eg speed) to limit that controllers output or integrator.
External Analog Temperature Limit Case
If enabled the external analog may be used as a penalty source for the health clamped maximum command and it's operation is the same as the internal temperature limit case. An example use of the external temperature feature is to monitor the temperature of the motor under control.
Configure the following parameters to enable and use the external analog port as a temperature penalty source.
| Parameter | Type | Required | Description |
|---|---|---|---|
temperature_penalty_using_ext_an |
bool | Optional | Enables the external analog port as a temperature penalty source. Default value: disabled |
temperature_penalty_ext_an_limit_h |
float32 | Optional | Upper temperature at which maximal penalty is applied (degC). Default value: "Hardware maximum temperature" |
temperature_penalty_ext_an_limit_l |
float32 | Optional | Lower temperature at which minimal penalty is applied (degC). Default value: "Hardware maximum temperature" - 10degC |
temperature_penalty_ext_an_scale_l |
float32 | Optional | Lower command scale at maximum temperature penalty. Default value: 0.1 |
Ensure the external analog port is configured correctly to use this feature.
Host Sentry Case
dev_motor_controller features a host sentry that monitors the arrival of data from the host, to ensure that a valid connection is active.
The sentry becomes enabled only once a call to jcs_host::start() is made and jcs_host enters synchronous mode.
The sentry will not enable if only a parameter call to 'start' is made.
This is to allow the user to perform parameter based tasks without the sentry shutting the motor controller down.
The sentry is disabled when a call to jcs_host::stop() is made.
Sentry timeout while running
When the host sentry is active it can generate a command limiting scale value that is proportional to the time that the device is not in contact with the host.
The host sentry internally uses a filter and as such is tolerant to occasional drops in communication.
The sentry will only expire once the host is unresponsive for the time set in host_sentry_timeout_ms.
Sentry timeout while waiting for first synchronous data
If the sentry is enabled and the user issues a jcs_host::start() (or makes a parameter call to start) the host sentry will start to wait for the first tick of synchronous data from the host to arrive.
The sentry will expire if the time is greater than that configured in host_sentry_wait_start_timeout_ms.
The user may wish to make host_sentry_wait_start_timeout_ms larger if parameters need to be issued after jcs_host::start() (or parameter call to start) and that those parameters may take some time to complete.
An example where this might be useful is zeroing the incremental encoders of many motor controllers.
| Parameter | Type | Required | Description |
|---|---|---|---|
host_sentry_active |
bool | Optional | Set to enable the host sentry. Cleared to disable the sentry. Default value: enabled |
host_sentry_timeout_ms |
uint32 | Optional | Sentry expiry time. Default value: 60ms |
host_sentry_wait_start_timeout_ms |
uint32 | Optional | Wait for first tick expiry time. Default value: 5000ms |
WARNING:
It is important to consider the effects of setting host_sentry_timeout_ms too high. JCS signalling is effectively zero order hold. If the sentry timeout is too long, then power devices can hold their last good command for host_sentry_timeout_ms before shutting down. The consequences of this could be loss of control of robotic links, damaged hardware and other unsafe conditions!
Temperature limits
dev_motor_controller monitors for temperature limit conditions. See Hardware Specifications for values.
A critical estop will be generated if any error limit is exceeded. A start/stop cycle is required to clear the estop.
It is recommended to not adjust the temperature error limits. Warning limits can be set per the application.
The following parameters are available:
| Commands | Type | Required | Description |
|---|---|---|---|
temperature_limit_error_h |
float32 | Optional | Average temperature high error limit. If the device average temperature rises above this value an estop will be generated and the device will shutdown all outputs. Default value: hardware dependent |
temperature_limit_warning_h |
float32 | Optional | Average temperature high warning limit. If the device average temperature rises above this value the temperature warning bit in op_state signal will be asserted.Devices will ensure that temperature_limit_warning_h <= temperature_limit_error_hDefault value: hardware dependent |
temperature_limit_warning_l |
float32 | Optional | Average temperature low warning limit. If the device average temperature falls below this value the analog warning bit in op_state signal will be asserted. Devices will ensure that temperature_limit_warning_l >= temperature_limit_error_lDefault value: device dependent |
temperature_limit_error_l |
float32 | Optional | Average temperature low error limit. If the device average temperature falls below this value an estop will be generated and the device will shutdown all outputs. Default value: device dependent |
temperature_error_on_warning |
bool | Optional | If true then a safe-shutdown estop will be generated if the device average temperature passes temperature_limit_warning_h or temperature_limit_warning_l.Default value: False |
Error on warning
If parameter temperature_error_on_warning is set to true then a safe-shutdown estop will be generated if the average device temperature passes either the high or low warning limits.
This can be used to transition to a safety controller before any hard error limits are reached.
DC bus supply limits
The main power bus voltage is monitored for limit conditions. See Hardware Specifications for values.
An estop will be generated if any error limit is exceeded. A start/stop cycle is required to clear the estop.
It is recommended to not adjust the DC bus error limits. Warning limits can be set per the application.
The following parameters are available:
| Commands | Type | Required | Description |
|---|---|---|---|
v_dc_limit_error_h |
float32 | Optional | DC bus voltage high error limit. If the DC bus voltage rises above this value an estop will be generated and the device will shutdown all outputs. Default value: hardware dependent |
v_dc_limit_warning_h |
float32 | Optional | DC bus voltage high warning limit. Default value: hardware dependent |
v_dc_limit_warning_l |
float32 | Optional | DC bus voltage low warning limit. Default value: device dependent |
v_dc_limit_error_l |
float32 | Optional | DC bus voltage low error limit. Default value: device dependent |
v_dc_error_on_warning |
bool | Optional | If true then a safe-shutdown estop will be generated if the DC bus voltage passes v_dc_limit_warning_h or v_dc_limit_warning_l.Default value: False |
Note: The device will clamp the error and warning limits to hardware dependent limits.
Error on warning
If parameter v_dc_error_on_warning is set to true then a safe-shutdown estop will be generated if the DC bus voltage passes either the high or low warning limits.
This can be used to transition to a safety controller before any hard error limits are reached.
A particular use case of this is to transition to a safety controller in the event of DC bus voltage loss.
See Controller Modes for details.
DC bus low pass filter
A software based 1st order low pass filter is applied to the DC bus voltage signal. If required the filter cutoff may be configured:
| Commands | Type | Required | Description |
|---|---|---|---|
v_dc_filter_fc_hz |
float32 | Optional | DC bus voltage filter cutoff frequency (Hz). Default value: 1kHz |
Note: A hardware antialiasing filter is also installed.
Phase currents limits
Each phase current is monitored for limits. See Hardware Specifications for values.
An estop will be generated if the limit is exceeded. A start/stop cycle is required to clear the estop.
Phase voltage limits
Each phase voltage is monitored for limits. See Hardware Specifications for values.
An estop will be generated if the limit is exceeded. A start/stop cycle is required to clear the estop.
Auxiliary 12V supply limits
The 12V supply rail is monitored for limits. See Hardware Specifications for values.
An estop will be generated if the limit is exceeded. If this error occurs the device electronics may enter an unknown state. It is advisable to power cycle the system if this error presents.
External estop
The action to be taken on receiving an estop from the network is defined by parameter network_estop_config.
The following options are available:
network_estop_config |
Description |
|---|---|
estop_force_shutdown |
Calls the device error handler with a critical estop. The device will force all controllers to the off state and disable all outputs. The motor will likely freewheel.Default |
estop_safe_controller |
Calls the device error handler with a safe estop. The device will attempt to transition to the safety controller defined in parameter controller_estop_safe_mode (See Controller Modes) |
estop_stop |
Calls a stop on the device. The device will transition the active controller to standby and disable all outputs. The motor will likely freewheel. |
estop_do_nothing |
Take no action. |
Note: See Controller Modes to configure the safety controller.
Host behaviour dependency
Motor controller network estop events are dependent on host behaviour.
Host has propagate_estop configured
By default the host has behaviour parameter propagate_estop configured to be true.
Thus in the event of a separate device generating an estop, the host will receive the estop event, then transmit an estop to all devices on the network.
With dev_motor_controller parameter network_estop_config set to the default case of estop_force_shutdown, upon receiving an estop, the motor controller will simply disable the outputs and freewheel the motor.
In this event, our nice walking robot will simply collapse.
Host has propagate_external_estop configured
The default behaviour of host behaviour parameter propagate_external_estop is configured to be true.
This is a good default - we would like all devices to respond to calls from jcs_host::trigger_estop().
However, as above, with dev_motor_controller parameter network_estop_config set to the default case of estop_force_shutdown, upon receiving an estop, the motor controller will simply disable the outputs and freewheel the motor.
What should I do?
A safe course of action is to configure device parameter network_estop_config to estop_safe_controller, then configure an safety estop controller in controller_estop_safe_mode (see Controller Modes).
Parameter network_estop_config is set to estop_force_shutdown as a default, as it requires some configuration that is application dependent.
With this configuration, any network estop received can put the motor controller into a safe control mode.