PEAK-System Forum

Hello PEAK-Systems Support Team.

I was wondering if the the PPCAN-Editor behavior is correct: I import CAN signals / messages using an existing .dbc file but the PPCAN-Editor doesn't not apply the signal scaling factors. On top the scaling seems to be corrupted when I manually add factors in my case when I use a PCAN-Router IO variable as temporary storage.

I created a small example configuration to check if that's really the case.

I sent a signed signal of -12.0 m/s on CAN channel one (with scaling 0,1) and want to receive that signal in another CAN message on channel two (using scaling of 0.5), instead of receiving the same value of -12.0 m/s I receive a value of -3.0 m/s. The signal is stored in an IO variable inside of the CAN router before re-transmission, other function blocks are not active.

My expected behavior of the router would be as follows:
- Router takes signal scaling factors and applies them to the received CAN message (no manual change in PPCAN-Editor)
1. Router receives CAN message as raw value (--> -12,0 m/s) and applies scaling = physical value
2. Temporary storage of physical value
3. Router applies correct scaling and transmits raw value using the new scaling factor --> -12,0 m/s

I attached a picture of my test setup including PCAN explorer which I used to check the sent/received values:
As well as the configurations I prepared:
Another thin I recognized that my scaling factor was changed automatically in lower digits from 0,1 to 0,1000xxx something. When I moved between the different configuration tabs:

Sorry, but accidentally I posted my reply in the wrong forum. But I'm also currently not really sure if that's a Hardware or Software issue (or both) or if that's not at all an issue...

Hello,

This is most likey the cause for this issue:
Since on transmission the factor of a PCAN-Explorer variable is interpretated as a division, you need to use the factor 2 indstead of 0.5 upon sending from PCAN-Explorer:
The PPCAN-Editor does not differentiate between incoming and outgoing factors, it's always division.


The values you see in your scaling factor are not a glitch,
this is due to the properties of the float data type used here.

Usally you will not see the values represented this way
since rarely is it shown with more than 3 decimal places.


Best Regards

Marvin

Hello Marvin,

Sorry for pulling up old topics but I need to come back to the second part of your answer regarding the scale factors.

You mentioned that this behavior can be seen usually only with more than 3 decimal places. In the example above it is already already changing with one decimal place (even though that little value has no effect on the signal). I am currently working on a project where the signal scaling (two decimal places for scale and a negative offset).

The change of additional decimal places of scale and offset values have now an effect on my output signal value. My yaw-rate signal differs by 1 °/s (from the input) which is of course not much, but I was wondering if you can propose how to correct this (any workaround available?)?

Thank you!

Hello Dominik,

regarding the order how Scale/Offset is used:
With this change you can use the same scale/offset for both transmit and receive frames.
You need a minimum firmware of v1.13 for PCAN-Router pro.
With that firmware v1.13 we also changed the internal representation of the scale value from 16.16 int to float which increases the precision from 4.8 to 7 decimal places.

Could you please verify your firmware version (latest version is 1.15.1), PPCAN Editor Version (2.2.3) and repeat the test if firmware or editor was outdated?

Regards, Gunnar Bohlen