Typedef value from .ctl file Front panel Control Reference

[T@nvi143]

Hello Everyone !

Overview: I am designing the Client Software System(Temporary I name it as "AMT") for Server Software system (Temporary I name it as "KING"). AMT Software is just a listener through TCP-IP Communication from KING. King send the binary string with specific typedef (Temporary I name it as "Version") and AMT listen that binary string with same typedef. Consider the application are in .exe file and not in Development mode.(Otherwise VI Scripting can be a solution for this problem)

Real problem Scenario: When the Version of KING get changed, AMT has to change the Version in the source and then have to compile again. Basic idea is to make the executable file compilation free. So I am tying to give the typedef(Version) in the AMT through path of .ctl file. But I cant get typedef through .ctl file. I get the Variant value and not Strict-typedef. 

I am attaching the .zip file and I am using Labview 2011 SP1, OS: Windows 7. I tried to explain little more in the Block diagram of the .VI file. Kindly have a look as new learner(myself 😉 ) is waiting here. Sorry for long story. Thanks in advance. 

[paul_cardinale]

Your best bet is to bite the bullet and recompile both apps when the typedef changes.

Other than that, you could try this:  In the code that sends the data, use "Flatten to XML" instead of "Flatten to String".  Then on the receiving end, parse out the XML (that won't be easy).

[JÞB]

Paul.

That sounds like you have done something like that before.  Could you link to an example?

[Blokk]

---

T@nvi143 wrote:

Hello Everyone !

Overview: I am designing the Client Software System(Temporary I name it as "AMT") for Server Software system (Temporary I name it as "KING"). AMT Software is just a listener through TCP-IP Communication from KING. King send the binary string with specific typedef (Temporary I name it as "Version") and AMT listen that binary string with same typedef. Consider the application are in .exe file and not in Development mode.(Otherwise VI Scripting can be a solution for this problem)

Real problem Scenario: When the Version of KING get changed, AMT has to change the Version in the source and then have to compile again. Basic idea is to make the executable file compilation free. So I am tying to give the typedef(Version) in the AMT through path of .ctl file. But I cant get typedef through .ctl file. I get the Variant value and not Strict-typedef. 

---

If you change the data format what you send from the server (KING), how do you change the code part what you use to parse out the info from the new received typdef? And if you can do so, why do you use typdef at all? I do not know the details of your project, but as I understood, you want to recompile time to time the server side code, but NOT the client code? I imagine, this makes only sense, if your client (AMT) code is prepared to parse out data from different typedefs received from different versions of KING(s)? Thus you must have a finit number of "data elements" in the different versions of typedefs? If so, why do not just use a look-up table at the client side, with the finit number of IDs. You simply send a string (or ini file, etc) with ID/value pairs from KING to AMT(s). You can freely change the number of elements in the sent package, if your client recognises an ID, it picks out its value.

Well, I might completely misunderstood the story here, and even I am not sure it makes sense what I described above... 🙂

Other question: why is it a big deal to recompile and re-deploy the client side code (this is what paul_cardinale suggested)? Also, you could just use Network Streams to send data between the client and the server side, and no need for the sometimes tricky flatten/unflatten actions:

http://www.ni.com/white-paper/12267/en/

"However, unlike TCP, network streams directly support transmission of arbitrary data types without the need to first flatten and unflatten the data into an intermediate data type."

[T@nvi143]

Thanks Paul for that suggestion. I already know this Concept but being just an Intern in the company so on Server side(KING) I cant change anything. I can just make changes on the Client side(AMT). So I hope that you understand my limitation. Looking at my example hope you understand that , what i want is typedef from .ctl file ?

[T@nvi143]

Thank you Blokk!

This is exactly my point. 

---

you want to recompile time to time the server side code, but NOT the client code? I imagine, this makes only sense, if your client (AMT) code is prepared to parse out data from different typedefs received from different versions of KING(s)? .

---

Server side(KING) is out of my authorization as being an intern. So when Server side(KING) typedef is changed, I change the typedef on the "TYPE node of Unflatten from String" on the Client side(AMT) and then recompile the implementation. I want to do my implementation in such a way that I dont have to compile every time and when the typedef is change on the SVN of the Server side, through the path of the .ctl file get the typedef and never to compile again and again. 

So can you suggest me a way to get typedef from client side(AMT) implementation ??

[Blokk]

What about if you try not to include dynamically the new typdef control into your EXE, but when the typdef version updates at the SVN, you create a new parsing subVI including this new typdef? Your EXE could call dynamically (and load/reload during runtime) this subVI. This subVI should do the data parsing thus always giving the same data toward the EXE, so the data type should never change between this "parsing subVI" and your main app (the EXE).

Interesting scenario what you are facing. May I ask some more details? So the people at the company change time by time the server side, including the typedef control. I guess they always keep some elements in the typdef control even if they change it, yes? Otherwise your EXE would complain about missing elements it could not parse out from the data package?

Edit: you could even compile a 2nd EXE application, a kind of bridge between the Server and your Client app. So you only need to recompile this client bridge application time by time and no need to deal with the dynamic VI call at your main Client application (I would use LabVIEW Network Stream to pass data from the bridge EXE to the Client EXE)

[T@nvi143]

Thanks again Blokk. 

Your idea of new parsing subVI is the current example which I attached in the post. So I cant be huge fan of your idea. And Bridge app is the other way round of the same idea. I respect your idea and effort but still I cant found answer for my question " Typedef from .ctl file" or Dynamically calling the .ctl file for typedef ". Recompile the application or edit subvi is the only solution I can figure out from your suggestion. I know my scenario is complicated, so thanks everybody. But I consider as the Lab-View limitation for such conditions.

[Blokk]

---

T@nvi143 wrote:

Thanks again Blokk. 

Your idea of new parsing subVI is the current example which I attached in the post. So I cant be huge fan of your idea. And Bridge app is the other way round of the same idea. I respect your idea and effort but still I cant found answer for my question " Typedef from .ctl file" or Dynamically calling the .ctl file for typedef ". Recompile the application or edit subvi is the only solution I can figure out from your suggestion. I know my scenario is complicated, so thanks everybody. But I consider as the Lab-View limitation for such conditions.

---

Yes you are totally right, I just explained the same but this is what you already do 🙂 The main problem is the design of the server-client communication. Since they send a typdef data, and not a general string for example. The TCP communication could be designed in a way, it just sends a simple string, like name-value pairs. So the client would easily parse out all values. This would be a totally flexible method, and no worry about typdefs...

However, I understand you cannot change what you have now, so you try to live with what is the recent situation. So sadly I do not know a method how to unflatten the data without recompiling your client app with the new typdef control...If I find some trick for sure I will post it...

[Blokk]

I have found this very recent link, I feel it is related to what you want:

http://forums.ni.com/t5/LabVIEW/typdef-constant-programmatically-from-it-s-path/m-p/3598639