- Software
- IQANdesign
-
Questions
IQAN 5 JFout send-order change?
When we updated from IQAN4 to 5, it seems a couple of things didn't work anymore regarding precise timing of when (J1939) CAN messages our sent.
Problem #1: Sending 2 messages at the same time.
We had 2 messages that should be sent at the exact same time. We simply had the send-method fixed on 250 milliseconds or something. But since IQAN5, the receiver wouldn't get both messages at the same time.
Now we fixed that by using a Trigger instead (using an IDC that pulses every x millisec). But is this a bug, or intended behavior? Maybe CAN frames have random send-offsets to spread them over time, reducing peak-loads?
Problem #2: CRC checksum + Counting
It becomes more problematic on another machine. The receiver (ZF transmission) requires the messages we send to have a CRC checksum byte, and a message-counter byte. Back then, IQAN didn't have the Checksum channels yet, so we made it by hand.
Works in IQAN4, didn't work anymore in IQAN5 (ZF says the messageCounter is wrong). I guess it has something to do with the order of counting and actually sending. Again, could there be some offset that wasn't there before?
As for using the IQAN(5) CRC component, we didn't had success yet. Either our specific method isn't supported, or it suffers from the same counting issue. In this case we need
Customer support service by UserEcho
The sending of cyclic messages is intentionally changed, see release notes
Case 36603 Even out CAN bus utilization
JFOUT, GFOUT and APPOUT with send method continuously and a transmit rate > cycle time are automatically distributed in time, reducing bus utilization peaks.
For the other issue, there is a change in how often a JPOUT and GPOUT is calculated:
35976 "Lazy" evaluation of xPOUT
The JPOUT and GPOUT channel will now only be calculated in the cycle when it is sent.
But with the transmit rate set to the same time as the application cycle time, it should be the same as setting it to every cycle, and then I cannot see how this would make a difference.
One thing you could try is to explicitly set transmit rate to every cycle.
It could be worth noting, although it is not the problem here, that cyclic messages sent at a rate faster than the cycle time will get problems with the message counter, only the built-in TSC1 handles that situation.
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?
Yes, with the CRC channel set to the method J1850 CR8 that is possible to select now, the message counter is positioned before the checksum.
To support the CRC you use, it looks like it would also be necessary to add an option for a different CRC.