(How) Can I change vi execution priority at runtime

[Timmar]

Ben,

I think I may have found my beast,

Parrellel Loop Iteration seems to have stung me.

I seem to be an early adopter of many of labview's new features and 9 times out of 10 hit some sort of obscure bug that nobody has seen yet.

Not sure that I can agree with the "everything in normal priority" and time critical stuff in a TC Loop.

This is probably due to lack of understanding on my behalf more than anything else.

If I had designed the architecture, this would more realistic, but i would still be throwing the reporting in background and application consumers in above normal and high.

Normal would be for general houskeeping,

This Module Help shows a treasure trove of impressive RTOS functionality, there is no mention of a reduced architecture for a cFP.  Can you provide a link.

[Ben]

---

@Timmar wrote:

Ben,

I think I may have found my beast,

Parrellel Loop Iteration seems to have stung me.

I seem to be an early adopter of many of labview's new features and 9 times out of 10 hit some sort of obscure bug that nobody has seen yet.

Not sure that I can agree with the "everything in normal priority" and time critical stuff in a TC Loop.

This is probably due to lack of understanding on my behalf more than anything else.

If I had designed the architecture, this would more realistic, but i would still be throwing the reporting in background and application c onsumers in above normal and high.

Normal would be for general houskeeping,

This Module Help shows a treasure trove of impressive RTOS functionality, there is no mention of a reduced architecture for a cFP.  Can you provide a link.

---

That's a good paper.

Re: setting priority lower...

Concider priority inheritance and if file I/ O backsup it can get bumped anyway. An overloaded CPU just will not pull the plow no matter how we arange the arrange the hourses.

Reduce the load by coding in a more efficient way or or try to do something or eveverything less often.

RE: Parrelle Loop iteration...

What beast bit you?

Ben

[Timmar]

RE: Parrelle Loop iteration...

What beast bit you?

Ben

---

The whole thing, The act of including it in a realtime application causes execution to halt, somewhere...

Removing it makes it go again.

My advice is not to use it until NI A: Acknowlege the problem exists B: Fix it.

[Ben]

---

@Timmar wrote:

RE: Parrelle Loop iteration...

What beast bit you?

Ben

---

The whole thing, The act of including it in a realtime application causes execution to halt, somewhere...

Removing it makes it go again.

My advice is not to use it until NI A: Acknowlege the problem exists B: Fix it.

---

I can lean on NI to get things fixed but .... I have to know what to complain about.

I think you are telling me the parallel For loops bit you but I am not sure. Could you post a screen shot of the code construct so I have something solid to complain about, please?

As it stands now I have to read your message like the notes on the edge of a tresure map that read "Dragons be here".

Take care,

Ben

[Timmar]

[Ben]

---

@Timmar wrote:

---

Thank you!

I have pushed the "button" and NI should follow-up.

Is there anything else you would want to tell them to enusre the bug gets fixed?

Just pretend they are very dense when looking at this image. Speaking for myself I try to make it very hard for them to ignore a bug once I find it.

Regardless of any more from you, I still want to thank you for sharing the issue!

Your partner in wire,

Ben

[Ben]

---

@Timmar wrote:

---

Thank you!

I have pushed the "button" and NI should follow-up.

Is there anything else you would want to tell them to enusre the bug gets fixed?

Just pretend they are very dense when looking at this image. Speaking for myself I try to make it very hard for them to ignore a bug once I find it.

Regardless of any more from you, I still want to thank you for sharing the issue!

Your partner in wire,

Ben

[Che_T.]

Hi Timmar,

Can you provide some clarity on what you're seeing?  Here is my understanding of the sequence of events:

(All RTOS)

1) You were wondering about how to change the priority at runtime.  

2) Timed loops with a dynamic priority was suggested

3) Another suggestion was to use parallel loops, since we have more resources now.

4) The timed loops suggestion was put on the back burner

5) You attempted to use parallel loops, but it is freezing

Is this correct?  I may be missing something.  The last screenshot has DAQmx functions, which isn't supported on a cFP.  Can you provide context for the screenshot?  Is it code that you ran on your host?  How was it related to what you're trying to accomplish?

I'm unclear on how the parallel loops caused the problem with priorities, and how it fits in on the original situation.  Can you help me fill in the blanks?  Maybe a summary from start to the point that we're at right now will be helpful.

As a side note, I ran the code in the screenshot with 3 devices and 3 tasks in parallel, and it ran without freezing.  I verified it in LabVIEW 2010 SP1 and LabVIEW 2011.  

If we do discover a bug, I'd be happy to file a bug report and help determine a workaround for you.

Regards,

[Timmar]

Che,

It appears that you have been a little distracted by the thread, There has been a diversion from the topic.

1. I have accepted the use of prioritised timed loops as the solution.

2. Issue #1. In the past I have had problems with timed loops:

I used a timed Loop within a Daemon containing a DAQMx Command would function correctly in the development environment but not in a compiled windows executable.

I was reluctant to re-visit this architecture as I recieved no confirmation that the bug had been removed.  What I can say is that in LV2010 sp1, R/T on a cFP using FP event VI's this problem does not exist. I have been able to impliment Jarrod's great suggestion.

3. Issue #2. I have attempted to use the recently added parralel iteration feature of the for loop structure.

I was experiencing considerable latencies with the Modbus bound Networked Shared Variable writes and thought that wrinting all 55 varables in parralel would mean that I would only have to wait 1 set of timeouts.

My assumption was that as each iteration yeilded, waiting for timeout, the next would execute.

I have found that on a PXI chassis using a realtime environment in debug mode that the loop would never complete execution.

I can't remember the entire code but I was using programatic access to networked shared variables. The initial code used a class override method to automaticaly select the data type but I am pretty sure that I removed that during my debug.

After I identified this as a problem (even when Parralel iteration was set to debug mode) I decided to avoid using it.  I had already wasted several days already chasing the problem.

I returned to my work an the cFP (code I had written prior to the PXI experience) and after deployment the cFP would disappear from the network and required a Power cycle before I could use it again. This code was using config read .vi's. I did not investigate deeply but when I removed the parallel iteration from the for loops, and was then able to continue my work.  I chose not to investigate further as I had accepted that this functionality was not available in the environment that I am working in.

I mocked up the screen grab as an attempt to make clear my practice with a realistic example (Start multiple Daqmx tasks concurrently), My original code is Proprietary, Has been deleted and as it is part of a large aplication is cumbersome to publish.

I have not lodged a support call as to date. I have not had any satisfaction from my other requests, recent ones for example: #78634 and #7469-572529 which remain unresolved. I have made several others in the 6 years I have been using labview and very few have been resolved in a timely fashion.

I belive that the best I can do is to inform other users of my experience and hope that they don't waste their time. I have been forced to develop the workarounds myself.

Kind regards,

Tim L

[Che_T.]

Hi Tim,

Thank you for the clarification.  I'm glad that you were able to implement the suggestion with Timed Loops and have it work for you.  I know it can be frustrating sometimes to run into a corner case bug, but NI normally suggests workarounds once we determine a problem exists.  We also take bug reports seriously -- timed loops are not exhibiting the behavior you were previously experiencing

It's unfortunate that you've had a bad experience with support.  We do have very many satisfied customers that call into support, and I encourage you to try again sometime in the future.

Regards,