Executing several StateDiagram VIs in Parallel

[geirove]

Hello,

I have searched and read up on the topic until mye eyes go red.

I have the following scenario: I have several (5 to be exact) StateDiagram Processes that I need to execute in Parallel.  Each StateDiagram is created using the StateDiagram Toolkit and reside in its own VI.

For the sake of structure and reuse, I do not want to break up this structure!

I have a cFP 2120 and I have the VI's executing in Parallel using High Priority for each VI. So what's the problem?

The problem is to ensure deterministic response times. I need about 5 ms response time; it's not a fast system.

Each VI is running its own loop that never ends. I have a 5 ms wait in the loop in each VI.

I cannot set Time Critical Priority to each of these loops, as the RTOS do not do any Round Robin among Time Critical Priority VIs even though they relinquish prosessing time by calling Wait. (see: http://forums.ni.com/ni/board/message?board.id=170&message.id=62696&requireLogin=False)

If I set High Priority to each VI, the code seems to run fine, but I have not measured any Response Times yet.

The goal of the whole project is to write Control Systems in a more structured way, which I feel I have managed. But will the Priority system of the Phar Lap (RTOS)

Unfortunately I do not find any articles on how to structure code and at the same time achieve deterministic response times. And I mean deterministic within 5 msec!

Please , I am not prepared to throw all code into one Time Critical Priority loop, as this tears down the structure I have been working hard to develop.

What is the general way to do this?

Can I expect very long response times due to other High Priority System tasks run by the RTOS?

[RobCole]

We quite regularly run multiple VIs in parallel on our RT systems (PXI and cFP). We run all of them at normal priority and use an elapsed time VI that measures how long it takes to get back to the timer (basically measuring loop time). Using this number, we can dynamically adjust our loop delay to keep each loop running at a set rate. We use this instead of Wait Until Next ms Multiple so that if we happen to miss the timing, the loop then runs again immediately. This is as close to deterministic as we can get when waiting for various systems and dealing with humans (who are notoriously non-deterministic).  Also, you can feed the loop time to the front panel and measure system performance (well, one part of performance anyway).

So... Running multiple VIs in parallel is not a problem. We, however, are running our loops at 333ms in most cases.

I would be interested to hear what you finally come up with to get this system working deterministic (or close to).

     Rob

[geirove]

Hello Robert,

I cannot tell you how much I appreciate your answer and the fact that you are doing what I am doing 🙂

It is very late in Norway now, and I am tired. I am sitting here running a test that I wrote where I measure the "determinism" of the system using 6 parallel processes:

- Process 1 Pulse DO-0 high for 100 msec, then go low for 1500 msec: DO-0 is hooked up to DI-0 (High Prior)
- Process 2 reads DI-0 and writes its value to DO-1 in a loop that pauses for 5 msec. (High Prior)
- The 4 other processes do similar stuff with other channels, but are only there to pose more load on the system (High Prior)
- I also have a communication process that using Shared Variables communicate som status to the Host every 500 msec. (Normal Prior)

I measure the time delay from DO-0 Hight to DO-1 High. I subtract these two signals on my Digital Yokogawa DL 1620 scope and ask it to calculate max, min and stdv of the signal: So far it says 12.46 min and 12.55 max so the jitter is small.

I am currenty using "Wait until next MS" and set up the timings so that everything tries to rund at the same time. This gives more consistent timings it turns out.

I tried to use just Wait which would tend to scatter the run of each process out over the cycle time: This however effectively "locked out" communication process and also caused much more jitter: from 6.5 msec to 10 msec.

I will let the test run tonight and continue testing tomorrow. Will keep you updated.

Would also appreciate if an NI Engineer could comment on this !

[geirove]

Rob,

I have posted a message with a link to a white paper on the subject.

See this post: http://forums.ni.com/ni/board/message?board.id=110&message.id=5535