0
Not a bug

Cycle time effects timer counting 3.18

Kevin 9 years ago in IQANsimulate updated by Gustav Widén (System support) 8 years ago 5
I have an application (1 MC3) that uses a timer which seems to count 10000 ms correctly with real time when the cycle time is set to 50ms. This is how I would expect it to behave.

When I reduce the cycle time of the application down to 5ms the time taken to get to 10000ms in the MC3 application takes approx. 20000ms in real time. Its almost as if the timer counting has slowed down when I reduce the cycle time.

I have tried as a new application file with simply just a timer counter in and no other logic as I wondered if I was approaching the processing limit but the inaccuracy still appears present?


I haven't tried previous versions of software and been unable to test in a real application so I can only assume this could be an issue with simulate and not IQAN Design?

Not a bug
Yes, this is an issue only in IQANsimulate since it runs on Windows, which is not a real-time operating system. Many factors can affect the time counting in the simulators, especially if you use short cycle times.

I am having a possibly related issue in 4.03: when I run my project in IQANsimulate, the timer counts in real time but when I send it to an MC3, it counts ~2.5x slower, meaning it cannot cope with a real time input stream. The project is mainly written in QCode and comprises ~60 math functions i.e. not an obscene number of calculations, running with a cycle time of 50 ms.

If the timer is not running as expected on the real master module, you should measure the System information channel cycle utilization to check that it is not exceeding 100%.

The application you are describing does not seem to be very large, at 50 ms cycle time it would take a quite large application to exceed 100 % cycle utilization.

When 100% cycle utilzation is exceeded, the first consequence is that the module will skip the next cycle, and this affects the timer. But if it takes even longer, then the next thing that will happen is that the module will stop due to a watchdog reset.

Is an MC3 slow at processing because of its safety checking? We have an MD4 connected to the system that could do the processing, but I would imagine the values calculated and transmitted via APPIN/OUT couldn't be validated because its not a safety controller? The only other real solution is to have a second MC3 and share the calculations to bring the cycle utilisation down?


Is there an alternative module that could allow calculations quickly and safely besides the MC3?

Yes, the IQAN-MC3 is slowed down by the cyclic checks it has to go through to meet the requirements on diagnostic coverage. The IQAN-MC31 uses the same hardware and is faster because it does not run the same set of tests as the MC3 does. But that also means that the MC31 does not have any SIL level, so it is not really an option for European machines.


Correct, if you want to maintain the SIL2 integrity level of the IQAN-MC3, you should not do any safety critical calculations on the MD4 either, the entire chain from input to output must be on modules that meets your required PL/SIL. Sending over APPOUT/APPIN between IQAN-MC3 modules is fine, but if you involve another module that is not certified, that will limit the level you can claim on your safety function.


I did a small test to see what it would take to get an IQAN-MC3 running at 50 ms to exceed 100% cycle utilization and get to the point where it skips cycles, but still completes before the watchdog timeout. It will vary depending on the type of channels and objects used, but I got my test application to a component count of abut 5000 before reaching the 100% error level.

The IQAN-MC4x-FS modules that were shown at Bauma fair earlier this year will become an alternative to IQAN-MC3 that has both safety certification and improved calculation capacity. But these modules are still in development.