- Software
- IQANdesign
-
Questions
Lost message on master bus ?
We have 3 master modules connected according to image above...
We send a P-brake apply command according to the image above. One goes out through the APPO_PbrakeRelease channel supposedly through the "Master" CAN-connection. The other goes out as a Generic CAN-signal through the "Generic" CAN-connection...
The APPO_PbrakeRelease channel is configured as shown in the image above. 1s transmission rate or on change.
On the receiving side, the input is controlling a digital output. The value of this digital output is also transmitted on the "Generic" bus. In other words, on the "Generic" bus we can see the value that should be sent out through the APPO_PbrakeRelease channel as well as the value that is received on the APPO_PbrakeRelease channel...
The problem is, occasionally we see a glitch as the one above. The value that is sent is constantly HIGH, while the value received goes low for exactly 1s and then goes high again. We have seen this for other digital "Application OUTPUT/INPUT" channels as well.
The fact that the time (1s) perfectly matches the outgoing transmission rate configured at the sender leads to the conclusions that one CAN transmission is corrupted and that the following transmission, 1s later, is correct and again sets the correct value. If it had been an actual change of the input signal, then I assume the APPO_PbrakeRelease signal would have been sent again as soon as the input changed back again?
Also, that the "Generic" CAN-transmissions which has a transmission rate of 20ms, doesn't show any incorrect values limits the error to the "Master" bus only. We have so far not seen any similar behavior on the "Generic" bus.
The "Generic" bus is connected to CAN-bus logging device that records every CAN-bus message transmitted without any filtering or "sampling interval". So, if we can't see any change of the signal here, then no such signal has been sent on the bus.
Is it a known problem "Application OUTPUT/INPUT" signals can get corrupted? And more importantly, how does one handle this?
Customer support service by UserEcho
It sounds as if you are describing the symptom of a lost message.
When the APPOUT/APPIN value type is boolean, the error value (the value the channel takes when an error is detected) is False. Have you checked if there is a timeout on the APPIN channel?
You can check this with
StatusOf(name of application input) = stTimeout
In general, I am not a huge fan of our decision to use "on change" with 1000 ms repetition rate as the default setting for APPOUT, I very much prefer continuous sending.
Thanks four reply.
Ok, so it works as intended then.
Normally one would set a timeout that is e.g. 5 times as long as the transmission rate to reduce the risk of error conditions due to occasional lost messages. This is not possible with your APPOUT/APPIN solution. Your manual says "The timeout of the APPIN channel is calculated automatically as 2 · transmit rate of the selected APPOUT channel." This ensures that, no matter what transmission rate I select, it will always be likely that one lost message will lead to an error condition.
I don't mind that the default error state for a boolean is False. But I would like to be able to use this type of channel without risking error conditions only due to one lost message. Do you have a suggestion for how to achieve this? Or am I better of using Generic CAN-messages?
I am surprised it says 2x transmit rate, I thought we should have put this on 3x transmit rate. Let me check!
For this application, sending the data in proprietary J1939 messages is probably a much better idea. With JFOUT and JFIN, you can set the transmit rate and timeout independently.
The main purpose of APPOUT/APPIN is for exchange of safety-related signals between MC4xFS (and previously MC3) modules. The APPOUT adds a lot of overhead in the data field of each frame with status-info, counter and extra checksum.
In a safety function, the default on-change + 1000 ms repetition is usually no good, as the reaction time until timeout becomes very long. The other use of APPOUT/APPIN is as a quick way of connecting channels between application without spending time on protocols. For that purpose the on-change setting can make sense, to avoid flooding the bus.
I just saw I forgot to respond to this old post. The correct timeout is 3* transmit rate, the user manual has been corrected:
The timeout of the APPIN channel is calculated automatically as 3 * transmit rate of the selected APPOUT channel.