As David suggested, the ECNT channel is the way to go.
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.
I changed category from question to idea, as this could perhaps be a good improvement to the built-in TSC1 channel?
No, in current versions the built-in TSC1 channel has SPN 3350 fixed at 31 (original TSC1 usage / temporary powertrain control)
So to solve your application, you would need to build your own TSC1 channel using a JFOUT.
Here is an example file showing how to use one master (display module SA 40) for making the request (sending PGN 59904 with a request for a PGN ), using the "poll trigger" property on a JFIN, and another master (controller SA 39) responding with the JFOUT on-request:
Request PGN example.idsx
The CAN trace with IQANanalyze shows how the traffic looks like:
The difference between IQAN-MC3 and IQAN-MC31 is that the IQAN-MC3 is design for safety related machine controls, and thus needs to have calculation of the probability of dangerous failure. This calculation is only valid within the specified lifetime, after that time there will at some point be a higher probability of failure.
So in practice, the modules (MC3 and MC31) will last longer than this, that is a reason not to specify it for MC31, while for the IQAN-MC3 application, the lifetime has to be specified and considered in the application, so that the module can be replaced or the machine decommissioned before random hardware failures become more frequent.
For the MD4, there is a component that is more subject to aging than the others, the backlight. Its intensity will be dropping as it is aging, but it is not easy to give an accurate statement.
The component specs says brightness >50% at 40.000 hours for MD4-5 backlights and >50% brightness at 70.000 hours for MD4-7 and MD4-10 backlight, but this data given for 25°C, and with 100% backlight the temperatures will be higher, say 40-45°C.
The selection of VREF-A, VREF-B or None on the VIN property for VREF is used in case there is a VREF error.
The VIN:s are automatically assigned error value and the status VREF error if its associated VREF has an error on it.
When you use the module VREF to supply a radiometric sensor, errors in absolute accuracy of the reference voltage is cancelled out. It is not a software function, it is just an effect of using the same 5 V reference for the VREF supply as for the AD conversion.
That is why you on in the Appendix A information on the VIN:s can read that the absolute accuracy differs between using the module VREF and an external reference.
If the adjust item for the TMR channel is placed in an adjust group, then would be possible to reset it via the menu system.
If an update is sent to the master where the component ID of the TMR channel is different it would be cleared (as it is no longer the same channel)
If an update is sent via IQANdesign with the send option for overwriting stored values, it would be reset.
Sending a settings file would also overwrite it, unless the adjust item has been placed in an adjust group and protected by a higher access level.
The IQAN-MC3 has a specified liftime of 10 years or 40 000 hours, whichever comes first.
This is not to say that this is the technical life of the product, this is the limit that is necessary to set to know how long the PFHd values are applicable. Because this is a precondition for calculating the PFHd, it also means that the SIL2 certification that depends on it is not valid after this time expired.
The information is found in the safety manual for the IQAN-MC3 (instruction book)
For the IQAN-MD4 modules, we have not given any statement about the lifetime.
Customer support service by UserEcho