Intelligent way to implement string command parser?

[Olaf_Stetzer]

Hi,

since a while I am thinking about a possibility to improve a LV program that controls Hardware on a RT target.

The current situation: The user interface is a LV program running on a laptop, the instrument is a CRIO target with

its own software controlling the hardware and aquiring data.

Both programs communbicat via TCP/IP, user actions are sent to the RT target as strings (tab delimited with arguments).

Now, since the programs are continuously being improved it is a bit cumbersome to get the set of commands synchronized

with the "parser" which evaluates these commands.

Is there a way to get a command set and the corresponding parser in "sync"?

Maybe I need to explain this a bit more:

Currently, all possible commands are stored in a Type-Def of a combo-field (I am not sure this is the correct term, in german its "Kominationsfeld").

Each command has one entry, the possible arguments separated by tabs and are defined with a placeholder, in my case the string @@@.

I do this to avoid typos and to have an overview of all commands.

Now it would be nice to have a "parser" in the RT software which checks the incomming commands againts this Type-Def combo field and populates

a case structure with all possible commands. So I only have to write the code in the case structure to "do something" with the command and its arguments.

I know the latter is not possible but maybe there is a solution something in between that I did not see so far.

What I would appreciate is at least a mechanism which "synchronizes" the cases in a case structure with my string command "array". But I need srings to be sent

as strings not numbers like with a ring.

Another point is the number of arguments which varies between commands.

Any suggestions?

Olaf

[laurentp]

Hi Olaf,

First of all, you should have created this post in the LabVIEW Real-Time forum, since your question is about RT communication.

Then to summarize, you have a LabVIEW project where you target a cRIO. You use the TCP/IP Protocol for communicating between your Host PC and RT, if I'm correct.

When setting a the Server/Client mechanism, you have a certain synchronization already. TCP functions are only working with strings, however you can define any datatype and convert it into a string, and then read the data back. This way, you could send an enum for the command name and connect it to a case structure, in the same you use it in a state machine (see attachment).

 

Could you clarify some aspects:

- Which LV Version do you use?

- Which mechanism did you implement for the TCP Communication?

- Do you need to control your cRIO from the host or/and read data from your cRIO?

- Are you aware about shared variables? easier way to communicate between Host and RT Target

 I would suggest you have a look at these Tutorials:

Real-Time VI to Host VI Communication Methods

Command-based Communication Using Simple TCP/IP Messaging

Regards,

Laurent P.

Application Engineer - NI Switzerland

[Olaf_Stetzer]

Hi Laurent,

thnaks for the suggestions I will have a look at them in the next days. In answer to your follow-up questions:

We are using LV2009, and the programs use the send and receive TCP functions one port for each direction.

The data is sent in this way as well end there I have all data in one big cluster which is converted using the functions

you suggest (flatten to string). This is already one big improvement I made, the old version of the software did a 

formatting to string and on the other side converting them back into floats. Very slow and unefficient, but with the

advantage that on this step it was relatively easy to implement a loggin feature where commands, data and logging

information was stored into human-readable txt-files. This is still a needed feature and so I thought it mgiht be good

to keep the commands in human-readable self-explaining formato for logging. Otherwise it would be difficult to

write the log-to-file function where the ring enum's are converted into strings of the ring itself.

Yes I had a look at shared variables and decided that these are not what I want or make sanse to me for this application.

Best regards,

Olaf

[laurentp]

Hi Olaf,

you have to keep in mind that for this kind of application, the communication between host and RT-Target hasn't to be and can't be time critical. Moreover, its goal is not to transfer huge amount of data, but keep the operator informed by displaying some information, and allow him to control some commands. To reach better performance, you can store you measurement data in the cRIO's compact Flash and/or in a database.

Do you know about tdms file? It's a binary file supporting by LabVIEW. However you can read clear data with Excel for instance thanks to this Plugin, or use Diadem to manage your data with a very efficient way.

Best regards,

Laurent

[Olaf_Stetzer]

Hi Laurent,

I now had a look at your suggestion and it seems that we can really use this to simplify the maintenance and the code itself.

However, there is one aspect I forgot to mention which makes it again more complicated:

On the RT target, there are two almost independent systems. Each of them have their own commands to control them.

On the UI side it would be beneficial if it was possible to select commands for both system from one "master" ring.

I have no idea so far how this can be accomplished, maybe dynamically merge the command set of both subsystems into one big

ring or enum and then use another case structure to decide which type of command to send?

About TDMS: I will have a look at it. Since we have all data (with physical units) stored in one big cluster with subclusters it would

be nice if it was possible to just wire this cluster to a TDMS vi to store everything (once per second). Does something like this exist?

Olaf

[Olaf_Stetzer]

In order to explain a bit more what I meant, here is a VI that shows my question somehow:

Since I am using tepdefs a lot I would have a (strict) typedef for commandsets (rings) A and B. Does my example still work then? How "intelligent" is the unflatten from string function in recovering the original cluster? Or do I need a second flatten to string function for the "smaller" clusters of your original example and then bundle the string with the subsystem info into the large cluster?

Olaf

[laurentp]

Hi Olaf,

I would suggest we continue our work together through phone calls, it will be much easier. Please contact me under 056 200 51 51 (NI Technical Support)

and ask for Laurent Pollara.

Regards,

Laurent

[Olaf_Stetzer]

After some more thinking I decided to use this new concept as explained above but with some small alterations.

Which brings me to another question, but first I explain what I have so far:

I now have an typedef-ENUM (not a ring, I was mixing the data types up which interact best with case structurese, these are enums not rings...)

defining all commands of one sub-system of my instrument.

I put this enum together with a string which may contain all arguments to that command into one cluster.

This cluster is the whole command, also defined as typedef.

I have now two more sub-systems each with thier own commands which should be defined similaraly.

I want to define another cluster of a similar kind for the "highest" command hierarchy, where the ENUM contains now the sub-system identifier and the string the "flattened" command cluster of the corresponding subsystem.

So far so good. The question I am asking myself at the moment is if this whole stuff wouldn't be something which can be easier defined and worked on in the form of objects and classes? But I am not sure because I dont see the need to have methods within this class it would be more because it may simplify the whole project.

What I could have as an abstract class is a cluster containing an ENUM and a string. For each subsystem I would have one instance where the enum containing all commands is defined.

For the highest hierarchy I could use the same abstract class again. But the interfaces aren't clear to me I have experience with LVOOP. Will it still be possible to flatten this object into a string for TCP-communication and can I use such an object to define a queue for the internat communication with the RT-vi?

Olaf

[Olaf_Stetzer]

Sorry Ihave to correct myself, since I cannot edit the old message anymore. I meant:

---

But the interfaces aren't clear to me I have NO experience with LVOOP.

---

Olaf