Your comments

Thanks for your help

Tried it, but ran into another problem. Since GPOUT (sending in this case) do not have an offset/scale, I still need to use a (int)Math block first to pack the value. The math block screws up the value as well, probably again because its not a UINT32.

Can't test it with a real IQAN now, but maybe the GPOUT "fixes" this anyway when set to unsigned. But in the simulator, the GPOUT still gets a negative value strange enough.


Good to know!


Well, turns out then we've been a bit too careful with memory writes in the past, programming all kinds of tricks to delay/suspend memory writes that weren't really necessary :)

Got to correct. JPIN blocks actually do allow Page Masking. So that reduces the problem. Still, it would be a handy feature being able to mix them.

What Carl describes is indeed the issue we had as well. Basically we don't always know who is going to request. Or in my particular case, I had 2 displays that could request the same (so I had to catch and process the request manually).


Basically the Source of the requestPGN shouldn't really matter. Just as long the DA matches ours or is set to Global, we should reply.

Thank you for the suggestion, we'll try that as soon as we have a chance.


A more elegant solution for the checksum/count issue would be utilizing the built-in CRC channel. Any idea why that wouldn't work? But from what I read: "Optionally a CVC counter is positioned before the CRC byte in the frame"


it seems it won't work for me because in this particular case the receiver wants the counter as the second(last) byte instead. Any chance this will also become possible?

Reminds me of an issue I had in IQAN 3 with requesting PGN's. It seemed the request mechanism does not fully follow the J1939 guidelines.


Correct me if I'm wrong (maybe it has been fixed in the meanwhile), but the request only works if the Source of the request-PGN matches with ours. But the source shouldn't matter really, the Destination does.


Any source could send the 0xEA00  Request message, where byte1,2,3 contains the PGN we want to get back.

Whether the IQAN should respond or not, depends on the Destination source, the 3rd and 4th hex char. So, 0xEA00 is aimed at Source 0 (engine typically). 0xEA01 would be aimed at any controller with source 1, and so on. Or, if all should respond, we can also use the Global address (255). So if we request using PGN 0xEAFF, all controllers should react on that. From my knowledge, IQAN (3) didn't do that...

Didn't know the system log could be disabled, but that sounds like a soltion, thanks!

There are no additional logs, just the default system one. But I do know there the majority is because if "Division by Zero" events (which would be nice to disable optionally btw). So, it likely has logged that many thousands times through the years. Could it be the memory is just "worn off"? Because in that case... I'm afraid a lot more machines will follow.


Is there a way to fully supress this message? We are still using IQAN 2.6 for that MDL2 -didn't want to take risks migrating old machines. The user complains the pop-up keeps coming back, and the only solution I can think of now is to replace it with a new MDL2. Shouldn't be needed for a log function we don't really use...




"static tmrDelay := 0"


Didn't know you can add variables with qCode that are memorized for the next cycle! Another thing learned.

To my knowledge a (32bit) float can't reach as high as an unsigned int32 because the last bits are "wasted" on the Mantissa & Exponent, so that won't do the trick.


The problem mainly occurs when doing math with Serial numbers, J1939 DTC's or GPS coordinates. At some point, the value gets slightly inaccurate or changes completely. In some cases it can be bypassed by splitting the math into 2 lower-range values, but that's not always possible unfortunately, let alone "readable".