- Software
- IQANdesign
-
Bugs
4 byte JPOUT not functioning as expected.
I have seen a few posts on this issue, but did not see anything as far as a resolution or that it is being worked on. Given that the JPOUT channel has a 4 byte option and I didn't see anything in documentation in regards to special conditions for its use. The 4byte option does not function as I would expect on a JPOUT.
Encountered this on IQAN 4 when we wanted a quick a dirty re-transmit of a block of J1939 data.
There seems to be an issue with handling the LSB nibble. Also seems that I can't use the 2 MSB when other fields are set to 1. Not sure if this is due to error handling?
With a very simple function of a 'frame in' to 'parameter in' to 'parameter out' to 'frame out'. The simulation will not allow the parameter in to be filled with 1's. It does allow 0x3FFF FFF0.
On a system, the parameter in receives the expected value but when passed to the parameter out bits get truncated.
For example, sending 0x1F2 DBE0 is handled as expected by the JPIN but when passed to JPOUT the data is 0x1F2 DBD0. Placed real and int math channels in between the JPIN and JPOUT to verity the received value is being passed to other channels as expected, and it is. So the issue seems to be with the JPOUT.
This occurs on IQAN Design 4 as well as IQAN Design 7.
Customer support service by UserEcho
There is a behavior of the JPOUT that makes it so that the input is always handled as a real value.
This makes it limited to the real value type in IQAN.
A real number (floating point) in IQAN is in the range 1.5·10-45 - 3.4·1038 (negative and
positive) with 7 significant digits.
This behavior is only applicable for 4 byte JPOUT.
This comes from the resolution and offset on the JPUT channel even if it is configured as a integer.
An option can be to try using the GPOUT channel instead.