LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

[W2k, LV7]: debugging reentrant executions

Hi there,

I've entered unexplored territory in LabVIEW7 (at least for me).

My project involves the start of some daemons watching USB comm lines.
Those daemons are reentrant vis started using VI server: 'Run VI'. So far so good.
There seems, however, to be a bug in my code that prevents the self-termination of those daemons under specified circumstances. So now I need some help
debugging reentrant executions. Maybe someone of you can give me some hints and answer my Qs:
1. Those reentrant daemons have a non-reentrant subvi as a LV2-style global (USR to store 'global' data). Will this LV2Global run just in one instance as expected, e.g. can I rely on it displaying the results of all daemons?
2. I've created a little too
l that shows all running processes and if those are reentrant or not. But i can not figure out how to get the number of instances running of a reentrant VI. Any ideas?
3. If, as in my case, a reentrant daemon does not stop as expected, is there a save way to shut it down? I had to shut down LV using W2ks task manager to kill that processes. Any better ideas?

TIA and
Greetings from Germany!

--
Uwe Frenz
0 Kudos
Message 1 of 6
(3,098 Views)
I'm pretty sure the answer to number one yes, all the reentrant VIs should call the same instance of any non-reentrant sub-vi they contain.

Number two, I don't is possible the way you are doing it. Since all the called VIs have the same name, there's no way to figure out the number that are currently running. Try this instead. Create a .vit out of the VI you currently have running reentrant. Now each time it is called, a new instance of it will be opened with a new name. This way your toll should be able to display all the instances of it.

Number three, and trouble shooting reentrant VIs in general. Temporarily drop an extra stop button on the front panel to stop the VI if it gets hung. Also, you can drop extra indicators on the front panel where you wou
ld normally place a probe to see what�s going on.

Hope this helps a bit.

Ed


Ed Dickens - Certified LabVIEW Architect
Lockheed Martin Space
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
0 Kudos
Message 2 of 6
(3,098 Views)
Ed,

I am still trying to avoid the template solution. As I said, this is going to be a daemon. The users on production floor are not going to see this little status monitors - they might want to play and damage 'em.

You answer on #3 is invalid - a reentrant vi is not necessarily coupled with its FP objects (as there is just one FP, but might be several instances of the code). So the only obvious way I see is some kind of system mechanisms like notifiers, queues or so that stop single or all instances of that daemon. Thats what I did, but there seems to be a bug (in my code I think).

I hoped to get other ideas.

Anyway, thanx for your reply.

--
Uwe
0 Kudos
Message 3 of 6
(3,098 Views)

Hi Uwe!

I am used to seeing you on info-LabVIEW becuase I kunk on that list.

Yes, Ed's #3 is invalid for the reason you cited.

I do not think you should rule the VIT approach so quickly.

I have used VIT's to do this type of thing on a number of occations. Let me share my approach.

I will use an action engine that I use as a messanger to communicate Start/Stop/Exit messages to the VI instanciated from VIT's. It is a simple VI that uses the VI name to post messages from the daemon to the VI(VIT) and report status back.

How this works;

1) After the VI is instanciated using the invoke node "run do not wait" I use the reference to get the name of the VI that was created. I then use this name when I call my "messenger" to tell the VI to start.

2) The VIT's will first find out what their name is and then check my "messenger" to determine if they should start/stop....

3) The VI that launches the VIT's will use the "messenger" to check if the VI started OK. If not, I can abort and start the shutdown procedure and log an error after a resonable timeout period.

4) If the VI(VIT) started OK, the code will then procede to launch the next instance of that VIT.

5) When it is time shutdown the instanciated VI's, the same "messenger" is used to pass the shutdown message.

6) VIT's are coded to post their state (stopped, running, exit) to the mesenger.

7) When shutting down I can monitor if any of the instanciated VI's fail to shutdown and then log errors to give a clue as to which one was getting stuck.

The cool part of this approach is that all of the instanciated VI's show in the "hiarchy screen" and I can simply double click on the icon and get the FP open for that instance. This lets way I can do execution hightlighting to see what is happening without getting in the way of teh others.

Re#3;
I seem to remeber Rolf Kalbermatter lsiting this as with re-entrant VI's that he did not like.

Trying to repay you for "Info-LabVIEW" contribution,

Ben


Ben Rayner
Certified LabVIEW Developer
www.DSAutomation.com

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 4 of 6
(3,098 Views)
That's what happens when I answer questions so early in morning. For some reason I was thinking troubleshooting built executables instead of reentrant VIs.

I often drop extra indicators and controls to de-bug executables.

No more answers from me before I finish my first coffee and it's after 8:00am

Ed


Ed Dickens - Certified LabVIEW Architect
Lockheed Martin Space
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
0 Kudos
Message 5 of 6
(3,098 Views)
I hope you are kidding!

We need all of the heavy hitters we can get.


While I am replying I should apologize for some rather extreme typos. To quote myself, "Listen to what I meant and not what I said."

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 6 of 6
(3,098 Views)