NI Home > Community > NI Discussion Forums

Components

Showing results for 
Search instead for 
Do you mean 
Reply
Trusted Enthusiast
rolfk
Posts: 4,640
0 Kudos

Re: Simple TCP Messaging (STM)

Ahhh that is trickier. The Import Library Wizard does this in a way, but I doubt you can get at the internal methods easily to extract only the structure parsing code. I did in the past something like this, in fact almost a complete C parser, excluding support for function pointers, but that code is not extractable easily to be posted here. It was a challenging thing to do and I learned a lot about C syntax that I never intended to learn :smileywink: Getting the inherently recursive C syntax into an array of data elements was quite some work.

 

I think a better solution would be to find an external C to XML or whatever converter library and then parse that one in LabVIEW and using scripting to create the cluster.

Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
Member
PatFord
Posts: 34
0 Kudos

Re: Simple TCP Messaging (STM)

The flattening and unflattening is trivial, the issue is maintaining a 1 to 1 correspondence between the C header, and a the LV cluster.

Knight of NI
Posts: 18,064
0 Kudos

Re: Simple TCP Messaging (STM)

Installer bug? Installed v2 on Windows 7 64-bit with LabVIEW 2010 64-bit. In the folder installation step I specified the LabVIEW 2010 directory as "C:\Program Files\National Instruments\LabVIEW 2010". The installer promptly ignored me and installed it in the "C:\Program Files (x86)\National Instruments\LabVIEW 2010" directory.

Member
roundish
Posts: 32
0 Kudos

Re: Simple TCP Messaging (STM)

Hi there! i need some help with my project, i have just asked in other post but i guess they didn't find the error, and maybe here in the STM section somebody can help me. Let me introduce the project itself, it consist in making a PC1< ------>PC2----->Projector communication. So i have now everything except communicatin betwen PC2 to PC1 and sending strings readed by RS232 to the PC2. I don't know really what is happening smercurio_fc tried to help me well but i have tried the timeout and i guess is not the problem at all. Maybe i have made some mistakes or maybe i am not doing well something, would you mind seeing my code and try to help me? Thanks in advance and keep up the good work!

 

This is my post: http://forums.ni.com/t5/Instrument-Control-GPIB-Serial/Rs-232-communication-with-a-projector/td-p/15...

Active Participant
ryank
Posts: 312
0 Kudos

Re: Simple TCP Messaging (STM)

smercurio_fc:

We haven't tested the installer on Windows 7 64 bit, so thank you for the feedback.  The next time we revise the library, we may move to a VI Package to avoid having to maintain our own installer.  In the mean time, you should be able to manually install by copying the folder into your user.lib and restarting LabVIEW.

Member
DevtPro
Posts: 6
0 Kudos

Re: Simple TCP Messaging (STM)

I have a RT system that I am setting up and I am replacing shared variables with STM reads / writes. My server is a headless system and will be running most of the time. The client needs to be able to start and stop many times during a test run.

 

The issue that I am having is that once the client reads the metadata, it is no longer available to read upon the next run. 

 

Possible solutions:

 

1: The server could have the ability update the metadata on a on-call basis.

2. The client could read the connection ID / metadata once, store it to a file, and retrieve it on subsequent runs.

 

Any other suggestions?

 

-Ken G

 

Active Participant
ryank
Posts: 312
0 Kudos

Re: Simple TCP Messaging (STM)

Are you getting error 60 when you try to re-open the listener?  If so, this has nothing to do with the meta data, but rather with the fact that you are placing your server-side TCP socket in the TIME_WAIT state.  You can probably remedy the problem by closing the connection from the client side and only closing the connection on the server side once your recieve error 62 or 66.

Member
DevtPro
Posts: 6
0 Kudos

Re: Simple TCP Messaging (STM)

OK, so you are suggesting that I stop the server each time the client stops?

 

BTW, the error on the client-side is 56 (timeout) coming out of the "read MetaData" vi.

 

(after more debugging...) I do now see error 66 on the target-side "STM Write Message" vi .

Knight of NI
Posts: 18,064
0 Kudos

Re: Simple TCP Messaging (STM)


ryank wrote:

smercurio_fc:

We haven't tested the installer on Windows 7 64 bit, so thank you for the feedback.  The next time we revise the library, we may move to a VI Package to avoid having to maintain our own installer.  In the mean time, you should be able to manually install by copying the folder into your user.lib and restarting LabVIEW.


Yup, that's what I did. Figured I'd give some feedback in case the library gets updated along with the installer.

Active Participant
ryank
Posts: 312
0 Kudos

Re: Simple TCP Messaging (STM)

You don't need to stop the server, but each time the client stops you will need to cleanly close out the TCP connections.  TCP is a strictly connection and state based protocol, where both ends of the connection constantly know what the other end is doing, you cannot, for example, re-open a connection from the client without first closing the corresponding connection from the server.  There are a number of ways of handling this, the easiest is to always terminate the connection from the client side and then monitor for error 62 or 66 on the server side, close the connection, and loop back around to a TCP listen.  You'd then re-transmit the meta data each time the server establishes a new connection.

 

A couple of other random thoughts:

1.  While we typically transfer the meta data in order to make it easier to maintain the application, there is actually no requirement to do so, if your meta data isnt determined dynamically (which it rarely is) you can use constants for the Meta Data on both ends of the connection, you just need to remember to update one whenever you update the other.  I don't think this will solve your problem (once the server is returning error 66 nothing is going to re-establish that communication other than closing the connection and listening for a new one); however, it may help to simplify and speed up your re-connect procedure.

 

2.  If you want something that is not connection based, you could just use UDP rather than TCP.  If your data needs to be delivered you'll need to implement an acknowledge, but in some cases that is easier than managing the TCP connections.