CAN data transmission error from xml file


Found incomprehensible behavior when transmitting CAN data from an xml file.

<!--  ID101 transmission test 1 -->
	 <frame id="0x101" writeInterval="1000" size="8">	 
	 <value targetId="test_tx1" offset="0" length="4"  initialValue=123456790></value>
	 <value targetId="test_tx2" offset="4" length="4"  initialValue=223567890></value>

<!--  ID102 transmission test 2 -->
	 <frame id="0x102" writeInterval="1200" size="8">	 
	 <value targetId="test_tx3" offset="0" length="4"  initialValue=0x12345679></value>
	 <value targetId="test_tx4" offset="4" length="4"  initialValue=0x22356789></value>

<!--  ID103 transmission test 3 -->
	 <frame id="0x103" writeInterval="1400" size="8">	 
	 <value targetId="test_tx5" offset="0" length="2"  initialValue=0x1234></value>
	 <value targetId="test_tx6" offset="2" length="2"  initialValue=0x6789></value>
	 <value targetId="test_tx7" offset="4" length="2"  initialValue=0x2235></value>
	 <value targetId="test_tx8" offset="6" length="2"  initialValue=0x6185></value>

 <!--  ID104 transmission test 4 -->
	 <frame id="0x104" writeInterval="1600" size="8">	 
	 <value targetId="test_tx9" offset="0" length="1"  initialValue=0x34></value>
	 <value targetId="test_tx10" offset="1" length="1"  initialValue=0x12></value>
	 <value targetId="test_tx11" offset="2" length="1"  initialValue=0x89></value>
	 <value targetId="test_tx12" offset="3" length="1"  initialValue=0x67></value>
	 <value targetId="test_tx13" offset="4" length="1"  initialValue=0x35></value>
	 <value targetId="test_tx14" offset="5" length="1"  initialValue=0x22></value>
	 <value targetId="test_tx15" offset="6" length="1"  initialValue=0x85></value>
	 <value targetId="test_tx16" offset="7" length="1"  initialValue=0x61></value>

The device for receiving data is your own. Correctly I only get ID104. All others have errors, but the incoming checksum is correct.

  1. By ID101
    Received 44 33 22 11 01 01 00 00 18 cd 5b 07 10 60 53 0d c3
    where 1 value is 0x075bcd18, should be 0x075BCD16 (123456790)
    … 2 value is 0x0d536010, should be 0x0D536012 (223567890)

  2. By ID102
    Received 44 33 22 11 02 01 00 00 80 56 34 12 80 67 35 22 07
    where 1 value is 0x12345680, should be 0x12345679
    … 2 value is 0x22356780, should be 0x22356789

  3. By ID103
    Received 44 33 22 11 03 01 00 00 34 12 89 67 35 22 85 61 21 while the program RD is starting
    … 44 33 22 11 03 01 00 00 00 00 00 00 35 22 00 00 05 when the program RD is running
    where 1 value is 0x0000, should be 0x1234
    … 2 value is 0x0000, should be 0x6789
    … 3 value is 0x2235, should be 0x2235
    … 4 value is 0x0000, should be 0x6185

  4. By ID104 everything comes right.
    Received 44 33 22 11 04 01 00 00 34 12 89 67 35 22 85 61 22

Can you check and fix the issue?

I can check, and hopefully fix. I don’t understand everything you are saying but it could be a translator issue?

Can you tell me what is not clear? I will try to explain in a different way.
My English is not very good.

The problem I encountered is that the transfer of data from the RD to the device via usb does not have the same values that are defined in the xml file. It depends on the data type settings in the xml file.
The checksum of data received from the RD to my device is always correct. Therefore, I assume that the data transfer error in the RD.
In bold, I have highlighted the erroneous data that comes from the RD.

There is couple of things going on.

  1. you need to use ‘name’ attribute instead of ‘targetId’ with your custom values in XML. targetId is used to reference an id-number of RealDash built-in values, listed here: Using targetId=“my custom value” will cause the value to be mapped incorrectly.

  2. There is a problem with initialValue attribute in how RealDash handles it. All values are internally handled as floating-point values and giving a large integer as initial value causes rounding error at that phase. If you try with smaller values as initialValues, it will work correctly. I can try to fix this initialValue problem for next release.

Yes, this is my mistake. Replacing targetId with name for ID103 solved the problem.

An unfortunate feature.
Sorry for being blunt, but it’s a rather strange choice to use integer conversion to float, and then back to integer.
It would be good news if this is fixed in the next release.
Thank you.

It’s not strange, it is necessary to support conversions in XML, like conversion=“V/1000” etc.

If division or operations with fractional numbers are used, then float is indispensable. Although if double is supported by hardware, it is better to use it.
But if there are no signs of working with float in the record, then why use it if it will lead to an error.