Components

cancel
Showing results for 
Search instead for 
Did you mean: 

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

0 Kudos
Message 21 of 174
(12,301 Views)

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
0 Kudos
Message 22 of 174
(12,298 Views)
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.
authored by
Christian L, CLA
Systems Engineering Manager - Automotive and Transportation
NI - Austin, TX


  
0 Kudos
Message 23 of 174
(12,294 Views)

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
0 Kudos
Message 24 of 174
(12,283 Views)

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
0 Kudos
Message 25 of 174
(12,201 Views)

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.

0 Kudos
Message 26 of 174
(11,453 Views)

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
0 Kudos
Message 27 of 174
(11,354 Views)

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

0 Kudos
Message 28 of 174
(11,252 Views)

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

0 Kudos
Message 29 of 174
(11,224 Views)

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

0 Kudos
Message 30 of 174
(11,221 Views)