Daemon application

[WiMAX_Eng]

Hi,

I'd like to create a background (daemon) application that can display messages from either another Labview application and .net assembly.  Both the Labview and .NET assembly parts should be able to 'connect' to the debug window to display the messages they want, all parts are on the same PC.  The idea is to log/show any debug messages to a user/developer.  Help really appreciated if anyone knows how to do.

Cheers,

LV 8.6.1

[F._Schubert]

To be language/platform independent, I would use TCP. The demon can be a normal exe, that is either started manually or placed in the autostart folder. The main issue would be to design the state machine that handles one or multiple connections to the demon.

Felix

[smercurio_fc]

TCP/IP is a good way to do it.

An alternative is to use the ActiveX server capabilities. You can enable the ActiveX server for your build LabVIEW application, and access it from either LabVIEW or .NET. Not as platform-independent as the TCP/IP solution, though, and there are versioning issues involved with this method.

[WiMAX_Eng]

Hi,

Thanks for the quick replies.  So do I build a standalone app that listens to TCP connections on a specific port (and address localhost), then any other application (non-specific) can connect to that same address?  Sounds almost too easy, are there any examples you could me to?

Thanks,

[MarcoMauri]

Hi!

There are examples provided with labview (search for TCP/IP).

In particular give a look to the multi-client server example.

Marco

[WiMAX_Eng]

Hi,


Possibly being dumb here so forgive me.  I've looked at the examples starting with the simple server/client VIs and then the multiple connections VIs.  In each case the server is sending data back to the client which is not something I want to do, I want the server to accept multiple clients which send only strings to be displayed in the server front panel, building a concatented log from each client's operations.

When I try to replace the write (existing VI in the example) to a read (plus other changes to this effect) it stops working.  I've attached my VIs if someone could shove me in the right direction.

The problem I think is in the server part, where I'm trying to listen to all clients and then display their posted string messages should they have one to post.

Best Regards

[JackDunaway]

1. It appears the client is running all-out in an unclocked loop. This needs to be metered in some way, such as adding a "Wait until Next ms Multiple". Or potentially, you only intend on sending the message once, which would mean you could get rid of the loop altogether (if you don't intend to set up a 'retry' scenario)
2. The server is reading a fixed 1 byte, then a fixed 4 bytes. This is atypical. For fixed-width transfers (5 bytes, in your case) you could get away with a single TCP read. What it seems like you're shooting for is the first byte to be the variable-width number of bytes for the second TCP read (ideally, use 4 bytes instead of 1 byte to adhere to the native I32 string length header). It seems like you want to be able to transmit variable width messages, so a fixed-byte read followed by the variable-byte read should be the way to go.
3. Using two controls, both called 'empty', is atypical. You should be able to reduce the two arrays of ref's into one wire and no FP controls.
4. Side note, just a syntax issue: on the server, wire the string directly into the case selector. Use 'Default' for the case with the string append, and "" for the empty case. This allows you to wire the case selector from the inside of the case structure without needing to branch the wire outside the case structure.
5. (I presume you've been reading Darren's nuggets about the infinity scroll position... cool!)

[WiMAX_Eng]

Hi Jack,

Thank you for your comments - and how patiently they came across!

I've attached the latest VIs for anyone who might be interested.

It's not ideal by any means but it sort of works.  One issue is that it seems to only increment the '# of connections' counter either after about ~15s (of the client supposedly establishing a connection) or a client sending a message (it doesn't seem to lose messages sent to it).  I probably have to change the wait timers but I'm not sure what the optimum values might need to be.

Thanks again.

[JackDunaway · Accepted solution]

Rather than using the "Number to Decimal String" (which is a lossy conversion), use either "Typecast" or "Flatten to String" found under the "Programming >> Numeric >> Data Manipulation" palette. This will conserve the integrity, bit for bit, of the string length header. Likewise, unflatten from string on the server side, or typecast again to the correct I32 datatype. Currently, you're going to run into problems, especially if the message length exceeds 4 decimal numerals! (10k bytes and above)