LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Dr. Damien's Development - Running Top Level VIs IV - A Tale of Two Servers

Continuing from my previous 

 

My FAILED solution!

The Command queue was easy since I could create the queue before launching the Template. This let me pass the Command Que reference when Iwrote the Class control (see #2 above).

 

Cmnd_Q_b4_Lanch.PNG


This works great in LV 8.5 as far as I have tested.

 

The Response queues were more complicated because

1) the Server (Active Object) has to talk to multiple clients

2) The Server may already be running (the Active Object may already exist) when the client attempts to "Open" a connection (hmmm create a

method-invokation facility, path? I don't know what to call it in LVOOP-speak. Do you?).

 

I handled issue #1 by using a queue created by each client, so each client has its own queue to receive responses (method data).

 

This is were things got complicated!

I wanted to pass a reference to the Response Queue for cliant_A in the "Open" command (enqueued by Client_A) and recieved by the Server (template.VIT, Instance of the Class "Active_Object" ) via the Command queue. From what I can tell the Response Queue ref makes it through fine but will not let me put it into my LVOOP data! This image shows the probes after stepping through the VI that bundles up the Que reference.

 

Why_Not_Valid.PNG

I have thrre probes showing
the class data in ([15]),
an array of clusters of "AO StatusQue" and "Open" ([17]), and
Class data out ([16])

 

Notes;

A) Shows the content of the Command that was recieved by the Template via the command queue. Note the command is "Open" and the "AO StatusQue" has a ref to "Unamed -0xE5400000".

 

B) This value in the probe is a bit of a mystery to me. It is never written in the context of this Template or on the class wire before the Template was

instaciated. This value is used in another wire of this same claass used in the Client (Tester), but not in the Template. Could this be an artifact that

the Template is running as Re-entrant? This value is not used in the Template, so I only point this out as a curiosity.

 

C)  This value is an array of clusters. Each array element records the connection information for each client. As shown here the array is empty because

we have not opened any connections yet. This is as expected.

 

D) This probe shows the array of connection clusters I am trying to put into the LVOOP class data. The array has one element which is a cluster that has

the "AO StatusQue" set equal to the value shown in the "AO_Command" (see A above) and the "Open" flag is set true indicating this should be a live

connection. This is also as expcted.

 

E) Is this Dr. D's tiem #3 in action?
The probe clearly states "Refnum not valid in this conext" but goes on to state which reference is not valid!

Why does everything work right up to stuffing it in the class data?

Anyone have clue what is going on?

I have an idea for a work-around but this issue has me perplexed.

 

Ben

 

The above applies to LV 8.5

Message Edited by Ben on 01-02-2010 10:35 AM
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 11 of 37
(1,951 Views)

Anyone have any ideas about the invalid reference?

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 12 of 37
(1,902 Views)
I don't have an answer (you seem to do all the work in the Active_Object.lvproj context), but can you post a simplified example?

___________________
Try to take over the world!
Message 13 of 37
(1,876 Views)

I don't have that version with me. A simplified example consists of a Tester.VI with two VI called from the Class Open and "Close" along with about 105 VIs in the class to pull it off.

 

I will try to remember to post my buggy version when I get home.

 

BTW My work-around fixed the issue with accessing the queue from the Template. All I have to do is fix the intermitant crashing when the app is shut-down. Smiley Mad

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 14 of 37
(1,869 Views)

Hi Yair,

 

Again thanks for your reply. Attached is the LV8.5 version of this app with the work-around in-place.

 

tester is called "Test_AO.vi"

 

From the project the weird stuff happens inside

 

Active_Object.lvlib\...\Public\States\Run_States\Do_Open and its callee.

 

That version crashes when you stop the Test_AO.VI and I'm not sure why yet.

 

I'm guessing its a programming error on my part.

 

That code is a work-progress that I have been doing on my own time and does not indicate waht I develop for a living (at least not until after I get the carshing figured out Smiley Wink )

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 15 of 37
(1,860 Views)

Have you tried to use the refnum?

It could be that the refnum is invalid in the 'Probe' workspace.

 

Ton

Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
Message 16 of 37
(1,861 Views)

TCPlomp wrote:

Have you tried to use the refnum?

It could be that the refnum is invalid in the 'Probe' workspace.

 

Ton


Yes, before I noticed what it said in the probe I watched the code "execute" an enqueue operation without an error. I say "execute" in quotes because the entry never showed up in the queue on the recieving end (which got me looking at the enqueue end of teh game).

 

Although your insight into the "probes context" could explain part of it but would explain why it looks OK in the array of clusters.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 17 of 37
(1,856 Views)

Are you sending a reference from one application instance to the next?

 

You could get the name of the active App.Instance

 

If so, you will (and probably allready have) fail.

 

Is the VI that openend the queue still active?

 

One question, why do you open a .vit with option 8?

 

Ton

Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
0 Kudos
Message 18 of 37
(1,848 Views)

TCPlomp wrote:

Are you sending a reference from one application instance to the next?

 

You could get the name of the active App.Instance

 

If so, you will (and probably allready have) fail.

 

Is the VI that openend the queue still active?

 

One question, why do you open a .vit with option 8?

 

Ton


The VIT is marked as re-entrant to allow for more than one instance to be used in latter versions.

 

In this version there will be only one "server" but I hope to be able to use this same construct to instaciate multiple servers, which could be of the same class or possibly a related sibling class.

 

The bottom line on what I am trying to achieve is to have a single standard Class who's children inherit the ability to instaciate a new instance of a Class as well as create the queues for communicating between them. If I get this right (please please, I hope, I hope) I will only have to code up what makes each class special and never have to write the "crate the queue.... again.

 

I do appreciate your thoughts since now that the vaaction is finished I will not have much time to think about this project for a while.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 19 of 37
(1,835 Views)

Awesome! About a year ago, I made an error HANDler (emphasis on the hand) that is variant of this concept. It has a server.vi that keeps a list of errors in memory. The user has the option to save them to a file, display them to the user and/or repeat them to a queue for miscellaneous use. I do agree that this is the way to go as it lets you build generic task-specific tools and quickly add them to applications. 

 

2010-01-13_112447.png 

 

 I do have a few comments on DFGray's design

1) Make sure that you set option 8 (reentrantcy) when launching server.vi.  Not only does it allow you to run multiple instances, it gets you a fresh reinitialized copy of the VI.

2) I question the need for the "STOP" user event if server.vi is terminated in the finalize.vi. This could cause issues if you still need to process things after the user hits stop but before the server is closed. (this could be unique to error handlers)

3) When the parent VI stops, the server.vi is automatically terminated due to the way the VI ref is handled. To make sure that server.vi finishes processing its tasks, watch for its reference to go invalid before continuing.(as shown below)

 

2010-01-13_111138.png

 

4) One issue I've had with thismethod is accessing the data inside of server.vi without creating race conditions. I think the solution may lie in using OOP or LV2009 Data References but I have not had time to investigate them. Any ideas?

Message 20 of 37
(1,580 Views)