NI Home > Community > NI Discussion Forums

Components

Showing results for 
Search instead for 
Do you mean 
Reply
Active Participant
Jack_A.
Posts: 245
0 Kudos

Re: Simple TCP Messaging (STM)

Thanks for the additional feedback...I'll take a look at it.

 

Regarding classes, I agree that they can be a very powerful tool and that STM could benefit from the extensibility of it.  One of our goals with STM is to much sure that it remains as simple and straight forward as possible so that it not considered a 'black box'.  We encourage users to modify it for their own specific applications if necessary just like you have done with optimizations.  I think if we built STM out of classes, it would become a 'black box' to many LabVIEW users.

 

-Jack

Member
Marc Blumentritt
Posts: 121
0 Kudos

Re: Simple TCP Messaging (STM)


Jack A. wrote:

 

Regarding classes, I agree that they can be a very powerful tool and that STM could benefit from the extensibility of it.  One of our goals with STM is to much sure that it remains as simple and straight forward as possible so that it not considered a 'black box'.  We encourage users to modify it for their own specific applications if necessary just like you have done with optimizations.  I think if we built STM out of classes, it would become a 'black box' to many LabVIEW users.

 

-Jack


You are right regarding the black box. This way STM is much more transparent for most users, since most users have not worked with classes, yet. Still, classes are very nice ;-)

 

Marc

CLD
Active Participant
Christian_L
Posts: 662
0 Kudos

Re: Simple TCP Messaging (STM)

Another reason that STM does not use classes is that one of the main targets for STM is LabVIEW Real-Time, which currently does not support LabVIEW classes.
Christian Loew, CLA
Principal Systems Engineer, National Instruments
Please tip your answer providers with kudos.

Any attached Code is provided As Is. It has not been tested or validated as a product, for use in a deployed application or system,
or for use in hazardous environments. You assume all risks for use of the Code and use of the Code is subject
to the Sample Code License Terms which can be found at: http://ni.com/samplecodelicense
Member
Marc Blumentritt
Posts: 121
0 Kudos

Re: Simple TCP Messaging (STM)

Oh, I didn't know, that LV RT does not support classes. But this support is planned in the (near?) future? (sorry for out of thread question)

 

Marc

CLD
Member
Evan R.
Posts: 6
0 Kudos

Re: Simple TCP Messaging (STM)

[ Edited ]

I feel like this is the cool kids' post. I really like the STM API! I have a few questions about the design decisions. I am very new to this, so my questions may have already been debated and decided against. If so, I am definitely curious to hear your rationale.

 

1. a) Does the use of strings for the message type introduce serious potential programmer error which may not even be diagnosed until well until later design stages?

For example let's say I have a message called "GPSTranceiverData", but I make a typo at one spot in my program: "GPSTranscieverData", this may not be caught as an error until well until late-stage testings.

 

b) Have you considered using a Strict Typedef to define the message name?

 

2. Each message handler must exist inside the client's or server's case structure. I appreciate that we could use a separate subVI for each handler, but have you considered the use of an OOP design? With OOP the polymorphism inherent would automatically dispatch a command to the appropriate handler.

 

Cheers,

 

Evan R.

 

 

Message Edited by Christian L on 03-05-2009 09:43 AM
Member
ssingh1
Posts: 73
0 Kudos

Re: Simple TCP Messaging (STM)

I am unable to install stm_1.0.32 on my LV 8.2.1 Version using installer.

 

Can you please provide the zipped files for download.

Member
joernheit
Posts: 46
0 Kudos

Re: Simple TCP Messaging (STM)

[ Edited ]

In the STM Read Message (UDP).vi in the inner case where the received udp data is parsed, the error cluster is checked for 'connection timed out' error. Does it make any sense or got I something wrong ?.

 

Jörn

Message Edited by JohnHighlander on 11-11-2009 06:26 AM
Member
sdouglas
Posts: 4
0 Kudos

Re: Simple TCP Messaging (STM)

I have looked at the newest rev of the STM VIs (as well as several previous versions) and have noticed one significant difference...the use of UDP pinging to serve as the primary means of establishing connections vs. just simply creating and waiting on a listener.  Does this method work better with regard to reestablishing communications in the event of a cable disconnection or are there other advantages?

 

Scott

Active Participant
Jack_A.
Posts: 245
0 Kudos

Re: Simple TCP Messaging (STM)

Hey Scott -

 

Using UDP is especially convenient in the situation where you do not know the IP addresses of the systems out there that you want to talk with.  By using UDP, you can broadcast a "who's out there?" message to detect the systems you'll be working with.  They would in turn respond with an IP address that you could open a session with. 

 

UDP is a lossy connectionless protocol so there isn't the notion of reestablishing a connection.  If the cable is broken, the data would be lost unless you implement some handshaking on top of UDP.

 

Hope that helps.

-Jack

Member
sdouglas
Posts: 4
0 Kudos

Re: Simple TCP Messaging (STM)

Hi Jack,

 

Thanks for the reply.  Makes perfect sense.  I am currently using this method, except that the client sends it's own IP address and listening port to the server during the UDP "ping" so that when the server sees the message, it knows who is not connected and the connection parameters.

 

I also think that this method is improved over the classic create listener and wait in that it doesn't matter which system is started first.  Either system can be rebooted and connection is reestablished without having to boot the systems in the proper order (i.e. RT box running first then host PC).

 

Best regards,

 

Scott