I am experiencing frequent occurences where the Stop Timed Structure.vi hangs. I found online that issue #42CHH33W used to be a possible cause, but it's supposed to be fixed in LV8.2 and I'm using LV2015! I tried hard to identify a pattern for the hanging, and implemented a system based on semaphore that would guarantee that I only abort the loop if it's sleeping (waiting to start its next iteration). If it's awake, I simply rely on a Boolean to exit the loop. Even now it still hangs sometimes. Getting a little frustrated here
Anybody has experienced such scenario before? Do you think I should try the suggested workaround (putting Stop Timed Structure.vi in a another timed loop that is in sync with the timed loop I want to abort)? What does "in Sync" really mean?
Our data logging engine is based on a timed loop, and the Actual Start left node is used to log the current absolute time. 99% of the time it works perfectly, but once in while it will give the value 11/11/1903 10:57:12.702 PM. Each time it gives an erroneous value, it's this exact value. Has any of you ever seen that? We use LV2011 32bit.
Our CANbus driver contains 3 timed loops:
- #1 prepares and sends outgoing messages
- #2 receives and parses incoming messages
- #3 handles events and check the communication status
Our driver's performance are not satisfying enough (we want it to run at a 10ms rate). It works ok most of the time (11ms, 9ms, 12ms, 10ms, 11ms, and so on) but the gap between loop iterations sometimes jump to 200ms before going back to an acceptable value. Quick tests showed that it is related to a user's request to change what HMI to display in a completely unrelated area of our application.
This logically led me to one obsession: making sure our driver never relies on the UI thread. To achieve that, I set the execution thread to "other 1" and the priority to "time-critical". I know setting the thread to "other 1" is not a full guarantee, so I also tried to get rid of everything that would force the VI to go to the UI thread: I got rid of all the indicators and all the property and invoke nodes.
The performances have already improved a lot, and the HMI activity in other part of our application no longer seem to influence the timed loop iterations.
However I'd like to see what else I could optimize:
- I still have a "stop" Boolean control. When it is set to True from another "manager" VI, the driver has to stop. All 3 timed loops poll this control to know whether to exit (one directly through the terminal, the other 2 through local variables). I know polling is not great, but my main worry is: because this is a control, does the VI still go to the UI thread whenever it is polled? Or only when its value change? I should also mention that I am not ever opening the front panel of the VI.
- Loops #1 and #2 need to be able to notify #3 that a read or write operation failed, so that #3 can take care of resetting the device and restarting the communication. Right now, #1 and #2 simply write the error in a dedicated error cluster (so I actually still have 2 indicators left I guess) and #3 polls those errors through local variables. Does that mean that at each iteration the VI goes to the UI thread since I am writing to those error clusters at each loop iteration?
Any comment on optimization in general is more than welcome!
By Jon Kokott
Un-abortable from VI Server: Start Asynchronous Call Prepare to call and forget 0x80
I'm trying to abort call and forget VIs that don't get shutdown properly.
I'm launching using 0x80 (call and forget)
Problem is, I can't seem to find them in memory using VI server.
If I "trick" labview and just start opening a VI by name, and put in the correctly (guessed) clone name
and it just so happens to be the right name I can find it.
Why isn't it appearing in all VI's in memory?
Is there any way to find clones of a VI through server?
the name of the VI when i hover over the abort button is something like dameon.vi:Hostdaemon:ProxyCaller.234908238:3
wtf? how can I abort call and forget VIs problematically?
Lastly, I'm aware of Abort.vi which I forget who programmed. I got it off lavag at some point, see attached.
Oh yeah, even if I get the right clone name from VI server through my educated guess, I still cant abort it problematically with the abort method.
Showing the front panel with an invoke node does work however (wtf? why?)
I can then hit the abort button on the front panel of the daemon, and it does stop.