Jump to content

Datasocket network of Applets - advice on message comms?


Recommended Posts

Using Labview 7.1 in Windows XP, I'd like to create a toolbox of small applications (exe's)...

1. Each application would perform a small task e.g. Step frequency, Set frequency generator, measure power output, measure field strength etc.

2. Applications could be strung together to perform a complete product compliance test

3. To achieve this, I would prefer applications to pass control messages and data via datasocket

4. Applications would register with a Registrar application on start up, and unregister on Exit. The registration would include data input / output details etc. that could be saved off as an ini file as the complete test set.

5. Applications would pass control messages between each other over a common 'message bus' variable on data socket

6. Applications might be written in Labview or other languages supporting datasocket like C

I've got most of it planned out, but not being a programmer by profession, I'm a bit stumped when it comes to the proposed 'message bus'.

1. How to prevent messages being lost when several applications send a message 'simultaneously'?

2. How to ensure all applications have 'read the mail'?

I'd appreciate a few suggestions on achieving the 'message bus' that doesn't involve the creation of a multitude of individual links. Anyone solved this one with datasocket? I'm toying with time slewing messages based on registry entry, or arbitration on the part of the registrar, or some kind of handshaking suited to datasocket. Can't put my finger on a 'KISS' method at the moment. Doesn't help that datasocket server behaviour isn't that well documented.

All suggestions welcome,

Cheers, Bob Edwards (EMC test engineer)

Link to post
Share on other sites

QUOTE (Bob Edwards @ Mar 11 2008, 12:55 PM)

I'd appreciate a few suggestions on achieving the 'message bus' that doesn't involve the creation of a multitude of individual links. Anyone solved this one with datasocket? I'm toying with time slewing messages based on registry entry, or arbitration on the part of the registrar, or some kind of handshaking suited to datasocket. Can't put my finger on a 'KISS' method at the moment. Doesn't help that datasocket server behaviour isn't that well documented.

All suggestions welcome,

Cheers, Bob Edwards (EMC test engineer)

Datasocket is a "catch-all" for communicating, so it has a fair number of quirks (besides the limited documentation). Datasocket is good for small numbers of variables (I believe the number I've heard is 200 as the upper end); large numbers of variables cause performance (mainly delay) issues. This is something to keep in mind with your design.

You may want to consider something such as TCP, though if you have multiple listeners it seems that UDP would be more appropriate (UDP is not as reception robust which may not be an issue on one machine).

As a thought, it sounds like you're creating a plugin-like archetecture. You may want to consider alternative design structures, all of which depends on your design constraints. You may even want to consider something off-the-shelf such as TestStand if you need to integrate in C code as well as LabVIEW code.

Tim

Link to post
Share on other sites

Thanks for the advice - I won't pursue datasocket further for this application.

I've come across the DIM comms system within CS framework here: http://wiki.gsi.de/cgi-bin/view/CSframewor...a022989f3b0b04c. I'll see if I can set up a minimal CS framework as a possible backbone for a system.

Regards, Bob

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.