Hello Mike,
The starting point is that the System in question can accept max 20 ms of Jitter (uncertainty in response time). It is a 100% Digital Control (only on / off) and no analog controls,
We wanted to use 15 ms Loop Time (== 15 ms Scan Time if we talk PLC language)
The issues we had with cFP & NI's documentation of Realtime where:
a) Reading of cFP Digital Inputs (DI-301 cards) takes way to long compared to our needed response time: 0.5 ms per read.
In one Cycle we needed to read from 20 - 30 inputs, consuming 10 - 15 ms alone, giving no headroom for computations ....
b) All NI litterature we could dig up talk up one and ***one*** determenistic loop only. They also document this as if determenism is something absolute, which it of course not isn't. Even with the Deterministic loops they talk about, you will have jitter, being in the uS or nS range, but there will be jitter !
The only difference with our system, is that we accept 20 ms Jitter.
c) There are no documents that talks about how to run several Parallell Loops with a guaranteed Max Jitter as we wanted. NI said: Either you have jitter, or you don't which is wrong as I argued above.
d) We found no documentation on how to achieve our goal. No documentation on the Realtime system and what system processes where running at which prioriry levels and could interfer with user processes at different Priority levels.
However, I had a picture in my mind how this was going to work. When we eventually got it working, this is exactly how things worked as proven by the Execution Trace Tool.
e) There where no documentation on what priority levels to run the parallell loops at. However, one NI employee tipped us that wrapping a Timed Sequence around code (or as we found; a VI) will make it run at a Priority Level > High Priority and < Time Critical Priority.
That was the first step towards a solution
f) Obviously, we needed to cache the Inputs from our 64 input channels and then distribute the cached values to meet our 15 ms Loop Time deadline.
This is needed to:
i) Be able read IO fast enough throughout the 8 different State Diagrams
ii) Make the system behave in a stable way throughout one Loop: All Logic needed to base decisions on the same cached values.
(This is what is called the Image in a PLC: The PLC reads all inputs at the beginning of a Scan and uses these cached values for speed and stability !)
The problem was how to distribute cached values: Distribituing boolean values throughout the system into many While Loops will of course not work and would defy reuse of modules. We invented a way to solve this problem and it works very well.
The conclusion is that even a 188 Mhz cFP 2120 may be able to control 80 channels using high level logic developped using State Diagrams.
We have used ideas from the PLC world to achieve speed and stability, but LV gave us the flexibility to produce a system that is highly modular and easy to maintain and change. It is also easy to agree with the customer on how each process works using State Diagrams.
However, we wonder why NI don't equip their RT Systems with speedier processors: 188 Mhz is a laid back performance these days and puts a lot of unnecessary limitations on the system.
We have tested the system in its real environment and it works well. Full deployment is due in August.
Message Edited by geirove on 06-22-2007 09:41 AM
Geir Ove
