Using the Event Structure in time-critical loops

[dwisti]

Is there any reason not to place a event structure in a time-critical loop?  Can the event structure cause a priority inversions like semaphores?  Is the event structure a shared resource?  Can a non-time-critical loop trigger user-events and the time-critical loop still be deterministic?  Is there any flaw in my thoughts here?

[.avi file]

Greetings!

      Your ideas are correct. Event structures are not supported in RT. LabVIEW RT does not inherently have a "Front Panel," and therefore will not be able to process events from front panel changes or the "Value (signaling)" property node. However, some User events will work. You may have a VI running on a Windows system which responds to events for Shared Variables which are hosted on the Shared Variable Engine on a RT Target. Please keep in mind adding larger number of user interface controls and indicators on the RT VI does effect the determinism on the real-time VI. Your best be is to process as much of user interface on the host side and use Shared Variables to talk to the target using shared variable buffers. You then use the RT FIFO's enabled property to communicate between the loops in the RT target. Take a look for at the following links for explanation.

http://digital.ni.com/public.nsf/websearch/3AE325EECD9A17AD862570BA00625088?OpenDocument

http://digital.ni.com/public.nsf/websearch/3AE325EECD9A17AD862570BA00625088?OpenDocument

http://digital.ni.com/public.nsf/websearch/42B70D2D0C4B568586256E2F0051441D?OpenDocument

http://forums.ni.com/ni/board/message?board.id=110&message.id=1741&requireLogin=False

Thanks and hope this helps
Regards
Avi Harjani

[dwisti]

Avi,
Thanks for your reply.  My RT time-critical vi does not use any front panel controls or indicators.  Event structures are supported in RT.  The key here is user-events. User-events do not require front panel controls or make use of the "value (signaling)" property.  But what I don't know is if the event structure is a shared-resource?  Can a non-time critical loop generate a user-event without causing a priority inversion?

David

[.avi file]

Dear David:

    It will be great if you can try to explain your application in detail and the reason for event structures with user events in RT.  Event structures by nature are asynchronous and using that with RT environment where your loops are programmed to be deterministic is not a recommended approach.

1) Can a non-time-critical loop trigger user-events and the time-critical loop still is deterministic? - No, the loop will not be deterministic because the event structure is waiting on a non deterministic loop to trigger user events. This will cause the priority inversion

 2) if the event structure is a shared-resource? - This might not be the right question, as event structures either wait on front panel events or user events to execute. So it is waiting on something making it a shared resource. 

If you know for sure that an event structure and the user event will happen once every x msecs inside a single loop then that particular loop might be deterministic. Also it will not run in time critical priority if that is what you are hoping for.  You will have to keep in mind your programming approach will determine determinism on your application.  For example if you have two or more VI's that are sharing the same event structure. In this case the first VI will create a mutex around the event structure and make the event structure a shared resource. It appears from what you are attempting to do can easily be done using state machines. More detailed info about your application might help.

Thanks and hope this helps
Best regards
Avi Harjani

[dwisti]

Avi,
Thanks for the reply. I apologize, I'm really not explaining my ideas very clearly.  I realize that event-structure waiting will cause a time-critical loop to become non-deterministic.  But what if this time-critical loop was really a time-critical vi with 2 loops. One loop is deterministic and the other one has the event-structure.  These two loops within a vi set for time-critical priority would communicate to each other vi RT FIFOs. 

David

[NathanT]

David,
      I agree with Avi that it sounds like a state machine would work well for your application.  Please tell us more about your actual application and what is generating the events that you want the event structure to respond to.

Thanks,

NathanT

[dwisti]

I guess what I need is an example vi showing my ideas.  The original question is just thoughts on how I can make a better RT deterministic time-critical vi that can respond to events too. To get rid of the polling in the time-critical process, I'm thinking that the event structure with user-events could be used to accomplish this.

Lets think about semaphores for a second.  Why can I not use semaphores in both the time-critical process and in the non-time-critical process?  The answer is simple, because the semaphore functions use the same vis that call a CIN (a.k.a. shared resource). Therefore, this could cause a priority inversion. For example, the non-time-critical process calls Acquire Semaphore.vi.  At that same time, the thread switches to the time-critical vi and interrupts the non-time critical process.  The time-critical runs its code until it also tries to acquire a semaphore.  It can not because the non-time critical process was in the middle of calling acquire semaphore.vi.  The thread must switch back to the non-time-critical process and finish running acquire semaphore.  Suddenly, you have a lower-priority task preempting a high-priority task.  My deterministic application has now become less deterministic and introduced some jitter. 

The above is an example of a shared resource causing a priority inversion.  Can the same thing be caused by the event structure?

[.avi file]

Dear Dwisti:

   I might not have mentioned the information clear enough. There will not be a priority inversion inside the event structure unless you add a shared resource that could cause the priority inversion. Please refer the details in my previous post previously. Please let me know if you had a chance to run the following VI in a RT target. That would be the quickest check, or if you have a VI in mind please do post it. This is probably the next approach to solving the problem.

http://digital.ni.com/public.nsf/allkb/42B70D2D0C4B568586256E2F0051441D

Thanks much
Avi Harjani