question about Action Engine

[feilong]

I am building a vi which has a few timed loops and there are also some Action Engine vis to protect the critical resources to prevent more than one caller vi access to one resourse. Thanks for waldemar and Gabi for sharing the idea of AE. It's really a good idea to do this job.

But I have encounter some problems though.

My vi reads AI and serial port. There's a 1 pulse per second signal (1PPS) from a GPS receiver to PFI9, and the receiver output a few messages which read and interpreted by vi.one of the message is tell the vi what was the exact time on the last fired 1 PPS signal. This time will be used as a timebase to timestamp the AI readings. I am using two counters to do the job. 

Regarding the AE, I am using a AE to control stopping of the vi (AE_sycnstop.vi), two other AEs to operate disk files to save the serial data and AI readings.  

I was using shard variable to stop the task before but changed to AE after reading a few posts on the forum.

One problem occuring quite often is, when first time load this vi into labview and start it, it freeze the labview. I have to close the vi by click the "X" button in the right up corner of windows application to terminate it. This closes all labview environment. Then second time I start labview and load this vi and start it, it could work properly.

Another problem is, once I stop a running vi by click the stop button in my vi, it stops normally. but when I click "run" button again, it just enters running mode and stay there but do nothing. but the vi stop button still works as I could stop it normally. In this case, I have to close this vi and re-open it, then every thing back to normal.

[feilong]

(continue on my previous post, there's a limit on char count)

What I am thinking is, will the AE lock out all the available threads hence make my vi freeze? Imagine a situation where only one thread is available now, loop A is using this thread to call AE_sycnstop.vi, before it finishes, loop B is scheduled to run hence the loop A stops and yield the thread to loop B. But if loop B also calls this AE so it has to wait, which is lock out situation, none of loop could continue.

I am not very famililar with thread schedule in labview. I wish, when AE is called in loop A, no other loop could interupt it until this AE finishes. But I don't see any such controls in the AE examples given in the forum. So I would think, in a situation where there's many loops calling one AE, then the lock-out of threads is not a small chance,especially for high speed loop.

Any comment is welcome.     

Mark Message as New Add This Message to My Bookmarks Add This Message to My Subscriptions Subscribe to this message's RSS Feed Highlight This Message Print This Message E-Mail this Message to a Friend Report to a Moderator My vi is attached as a zip as it contains a few vis.

[Pnt]

I don't fully understand what you are saying. Maybe you can simplify it, to one more simple vi example.

Although a few comments:

"I wish, when AE is called in loop A, no other loop could interrupt it until this AE finishes"

An AE can NOT be interrupted by another call. It is a sub-vi and it will continue executed until finished. (Note that usually an AE is not a reentrant vi.)

When another loop will call the AE at the same time, then it will wait for the AE to finish it's first call.

Such a problem you describe indicates it is something wrong with your program.

Make sure that no more than one vi at the time, is accessing your communication with the GPS.

[Ben]

AE's should be coded to stop quickly.

It almost sounds like like you have an AE that waits for something and does not return until that thing is detected.

If the code and callers can't be re-arranged to avoid this situation there is an option available if the AE is coded such that it can be set as a sub-routine.

If "Skip if busy" is set for the sub-VI call, LV will skip calling the VI if it is busy doing something already. If the AE is not busy, the AE will be called.

Ben

[feilong]

Thanks Pnt and Ben,

I check the "subroutine" option and found it's something I need as it doesn't allow other part of caller vi (such as execution of timed loop) to interrupt it. I think all the AE should set this property to function properly. This is like the "atomic subsystem" in Matlab/Simulink which execute as a single unit which only give its thread away after its execution.

I will try this and let you know.

In my AEs, there's only file operation and normal variable access which I think shouldn't wait for something else. Please correct me if I am wrong. The purpose of the 2 file access AEs are to control the access to the data files. The purpose of the other AE_syncstop.vi is just to notify all the caller the program is stopping.

Feilong

[feilong]

Just a update.

I found the reason of not starting second time is (one of problems I proposed in my first post) , my AE is still remember the old value when its caller runs last time. So after I add a init action to this AE and call it before other part of caller vi runs, there's no problem for the re-start of caller vi.

but I am still have the problem of run the vi for the first time. I am using Labview 7.1 and doubt if upgrade could help this. ANyway, it's not critical though a bit annoying as you need to close the labview and re-open it.

Feilong

[DFGray]

You need to add an initialize task to your action engine and then call the action engine with this task in the initialization stage of your code.  This will cleanly solve your issue without having to restart LabVIEW.  You should also be able to simply close all VIs, then reopen to temporarily work around the issue.  As soon as the action engine and its callers go out of memory, it loses its data.

[feilong]

Thanks DFGray,

That's true and I just added the init part to my AE.

[johnsold]

File operations can take a long time if the file is fragmented or the OS does something strange with the file access. I did not look at your program structure, but you generally want file operations running in a parallel loop which will have less impact on the timing of the more time critical parts of the program. Use the AE to pass data or commands to the file loop, but do not put the file operation in the AE itself, if it could block part of the program.

Lynn