Difference between revisions of "Manual CAN Requests"
| Line 35: | Line 35: | ||
# Fill in the correct '''Data mask'''. This field determines which IO elements of the frame the user will receive. As an example, the part of the CAN protocol was taken. Firstly, the user has to locate the data frame, which he wants to read, for this situation, data frame '''„Battery status“''' was taken into account. It holds five I/O parameters of the battery. If we would like to receive all data of the frame, in the configurator the user has to leave the default value in the ''Data mask field'' '''(Selected ALL)''' - which is used in this example. | # Fill in the correct '''Data mask'''. This field determines which IO elements of the frame the user will receive. As an example, the part of the CAN protocol was taken. Firstly, the user has to locate the data frame, which he wants to read, for this situation, data frame '''„Battery status“''' was taken into account. It holds five I/O parameters of the battery. If we would like to receive all data of the frame, in the configurator the user has to leave the default value in the ''Data mask field'' '''(Selected ALL)''' - which is used in this example. | ||
| − | [[Image:Manual_CAN_IO_2.png| | + | [[Image:Manual_CAN_IO_2.png|center]]<br /> |
| − | If the user would like to get everything except, for example, the '''Battery Temperature''' value, some modifications have to be done to the Data mask field. In this case, if the user does not want to get the '''Battery Temperature''' value, he should find where this information stands in the data frame '''(byte orientation)'''. For this example, '''Battery Temperature''' parameter can be found between '''4th''' and '''5th''' byte of the frame. It is explained in the table below how the 8 byte CAN frame breaks down and which part of the frame has to be changed according to this example. | + | <br /> If the user would like to get everything except, for example, the '''Battery Temperature''' value, some modifications have to be done to the Data mask field. In this case, if the user does not want to get the '''Battery Temperature''' value, he should find where this information stands in the data frame '''(byte orientation)'''. For this example, '''Battery Temperature''' parameter can be found between '''4th''' and '''5th''' byte of the frame. It is explained in the table below how the 8 byte CAN frame breaks down and which part of the frame has to be changed according to this example. |
''Protocol example'':<br /> | ''Protocol example'':<br /> | ||
Revision as of 13:48, 31 August 2023
To use Manual CAN request functionality user should select Manual CAN Requests tab in configurator. Afterwards, user will be able to configure CAN parameters in Manual CAN Request settings tab.
Manual CAN Requests
The main benefit of using Manual CAN requests functionality is that the user is able to read data via CAN BUS without requiring additional CAN protocol development from the device's firmware side, if parameters needed to be requested more frequently or vice versa. To read data with this functionality, the user must have:
- FMC650/FMM650/FMB641 device
- 03.01.00.Rev.00 or newer firmware (for FMB641/FMC650/FMM650)
- Transport or equipment with CAN interface which works via J1939 protocol
- Transport or equipment CAN communication protocol (with information about frames, parameters, ID‘s, Baudrate)
Manual CAN requests I/O settings
User can configure up to 70 Manual CAN Request elements by setting CAN ID/Request ID, Request Period, Request Data Length, RTR parameters. Additionally, in Manual CAN I/O tab, user needs to select by configured Manual Request input name – CAN type, Data mask Data Source, CAN ID Each CAN I/O has its own parameters and can be configured independently. Configured CAN request will be shown by Manual CAN IO AVL ID. (CHECK THIS FOR GRAMMAR)
| (!) Functionality will work only when Ignition is ON |
Baudrates are configurable in CAN \ Tachograph tab settings for connected CAN line which could be CAN1 or CAN2.
For Manual CAN request functionality, CAN is selected in Manual CAN IO tab. In Manual CAN IO, the input which should receive value must be enabled.
- Request ID/PGN - depends on CAN Type parameter and defines which CAN ID will be requested by device.
- Payload - defines data bytes, which are send if RTR (Remote Transmission Request) is disabled.
- Request Period - defines how often the request will be send. If 0 is selected - ID will not be requested.
- Request Data Length - defines data length of requested ID.
- RTR - Remote Transmission Request, is the choice if data frame needs to be send (if disabled) and if data frame needs to be requested (if enabled).
Example
In the Tachograph/CAN section the user has to select suitable baudrate. Manual CAN baudrate should be visible in the CAN protocol. If it is not known, the user can try to choose different baudrates to indicate which one works.
- Select CAN Type. Normally, every CAN protocol documentation should mention which CAN type to use. If not, select Extended.
- Fill in the correct Data mask. This field determines which IO elements of the frame the user will receive. As an example, the part of the CAN protocol was taken. Firstly, the user has to locate the data frame, which he wants to read, for this situation, data frame „Battery status“ was taken into account. It holds five I/O parameters of the battery. If we would like to receive all data of the frame, in the configurator the user has to leave the default value in the Data mask field (Selected ALL) - which is used in this example.
If the user would like to get everything except, for example, the Battery Temperature value, some modifications have to be done to the Data mask field. In this case, if the user does not want to get the Battery Temperature value, he should find where this information stands in the data frame (byte orientation). For this example, Battery Temperature parameter can be found between 4th and 5th byte of the frame. It is explained in the table below how the 8 byte CAN frame breaks down and which part of the frame has to be changed according to this example.
Protocol example:
| Frame ID | Name | Period [ms] | Byte orientation | Bit | Description | Scale factor | Source addresses | Priority |
|---|---|---|---|---|---|---|---|---|
| 0x620 | Range Estimation | 1000 | 1 | 7:0 | Estimated range km | 1 km | 17 | 1 |
| 0x300 | Battery status | On request | 0 1 3:2 5:4 7:6 |
7:0 7:0 7:0 7:0 7:0 |
Average of the two batteries SoC % SoC second battery % Battery Current (A) Battery Temperature (C) Battery Voltage (V) |
1 % 1 % 0,0625 A 0,1 C 0,046 V |
18 | 2 |
| 0x451 | Battery fast charging enable/disable | 0:3 4:7 |
7:0 7:0 |
Battery charge enable Battery charge disable |
ON/OFF | 19 | 3 | |
| 0x301 | Battery Status message request | 0:1 | 5:0 | 00001 - request SOC 1st | 18 | 2 | ||
| 00010 - request SOC 2nd | ||||||||
| 00100 - request Current | ||||||||
| 01000 - request temperature | ||||||||
| 10000 - request voltage | ||||||||
| 0x452 | Battery Fast charging mode switch status | 0:1 | 2:0 | 01 - Charge enable 10 - Charge disabled |
19 | 3 | ||
| 0x453 | Battery Fast charging mode switch | 0:1 | 2:0 | 01 - Charge enable | 19 | 3 | ||
| 10 - Charge disable |
