- Software
- IQANdesign
-
Ideas
Generic CAN Channels Using Resolution and Offset from DBC File
IQANDesign seems to ignore the resolution and offset information from DBC files on import (these parameters appear to only be used if you are using the internal J1939 database and not an imported one). Its seems odd not to utilize this information for generic CAN modules when its already provided in the DBC file. I could use a math channel to manually scale the values, but it seems like an opportunity for error when those factors were defined when the database was originally created and should just carry through.
I checked both 5.04 and 6.01 and they both present the same behavior. I feel like this kind of straddles the line between bug report and feature request. If there are practical reasons this is not done (e.g. wildly wrong values were put in the DBC file and IQAN would be forced to use them causing an error, the CAN database dialog would have to do some imported data validation, etc), I can understand, but a reasonable fallback strategy would seem to be default to resolution of 1 and offset of 0.
Thanks for your help.
Customer support service by UserEcho
Hi,
Effectively the Generic parameter do not support Offset and Resolution. I personally think this is very good as it allows non standard treatment of the information.
If you want to make use of the Offset and resolution you have to use the J1939 parameter type. This can be done even if the message is defined as a generic message. You can mismatch parameter types in the same message.
I do not see the need for modifying the behavior
JMarc
@JMarc: this makes total sense when you are designing the system or DBC, but when you are importing a non J1939 DBC to talk to a devices that has tens or hundreds of CAN signals with non unitarien resolution, it really sucks to manually add a math channel for each and do the operation. This should be done during the import process, and user modified afterward if you want to do some non standard treatment.
I don't see any reason that it wouldn't be possible to support both methods. If you want to apply your own interpretation to the data, you could just use a scale factor of 1 and an offset of 0 in the DBC itself. If for some reason those values didn't exist for the channel (which I don't know is possible with a valid DBC), IQANdesign could assume on import that no scaling is applied and you still have the raw value to use however you wish.
I think there are two ways this could be done.
Either automatically adding a math channel for every GPIN that have scaling and offset set.
Or import these as JPIN with J1939 error check set to zero. The later method would have the advantage of generating fewer channels, saving memory and cycle time for the application.
I like the idea of saving memory. But I personally believe the issue is how to handle error. In J1939 certain values are defined as error code. 255 for a byte. When dealing with generic, this might not be the case. Thus the use of a generic parameter allow you to decide what to do about it...
When the JPIN property for J1939 Error check is set to No, the full value range is used. When set to Yes, it uses the default J1939 range for indicating not available and error.
Changed topic category to feature request. Under review.
Basic question: why does the J parameters in/out support offset and scaling but no signage, and G parameters in/out support signage but no scaling or offset? It's like none of the 2 flavors of CAN parameters support the full deal... and has always been like that! Why?
The properties of the GPIN/GPOUT has looked like this since the introduction in IQANdesign 3.00 in 2012
Before this, in versions 1 and 2, there was one set of channel types, PIN and POUT, used for both J1939 and Generic. The properties of that channel were identical to those of the JPIN/JPOUT (when old applications were updated it was automatically converted to JPIN/JPOUT).
With GPIN/GPOUT supporting signed values it seemed strange to also have a separate offset property to deal with the sign.
But resolution still makes sense when the value type is integer or unsigned integer.
yes we do used signed number. I had forgotten that the standard only allows for positive numbers.