Components

cancel
Showing results for 
Search instead for 
Did you mean: 

Simple TCP Messaging (STM)

hi guys

I'm starting to use the STM libraries as multi tasking system with more than one server.

Following the example from Christian for multitasking, I have modified it. However I have a lot of problems, but as I do not want to use the shared network variables (not compatible with linux), I would like to fix it.

As it is a multitasking system, it is not simply to add the files here (they are within a project for controlling a laboratory). By the way, there is someone of the STM group that can help me? is it possible to communicate directly by email in order to send the project? 

Obviously, after fixing my bugs we can report it here for the community...

my email is

dariush.hampai@lnf.infn.it

 

thank you in advance

 

dh

0 Kudos
Message 151 of 174
(3,345 Views)

Hi guys,
I have extracted the control of STM from my global project.
The project is composed by:
1) shadow_main: this vi start all the demons (servers) vi. It has two subvi:
1.a) vi for stop (with a front panel)
1.b) demon_com to comunicate from the main with a selected demon (similar to the example of multitasking STM example that I found in STM examples)
2) Global_device: it contains all the device that I want to use. The only vi that are implemented are the test ones (test_1 and test_2)
3) demon_com_no_front_panel: a separate vi that comunicate without a front panel
4) sub_demon_for_test_1 and sub_demon_for_test_2: two different server with two different port (from the Global_device)

I found the following problems (that should be are all correlated)
1) the stop variable from main dose not work
2) the local switch for stop does not work
through a timeout on the wait listener (and the correlated clear error) I have solved (in particular for the second point)
3) it seems that I have only one connection, while I need (in this case that I have 2 servers) 2 different connections. In some way, it seems that I have a cross-talking between the two servers. I found that the TCP manager (before all the loops for the initialization) is not running as preallocate, but as normal vi, and it seems strange.
Moreover, I cannot reinitialize each time the server, due to the fact that the only external variable is reinitialized as well.

Have you any idea or example of two different servers in order to implement in my project?
Or have you any idea where is my error?

awaiting replies

dh

0 Kudos
Message 152 of 174
(3,319 Views)

Running your test example on one machine, the main problem I see is the use of the TCP Connection Manager vi in multiple sub_demons. The connection manager is designed as a single non-reentrant VI designed to keep track of all connection in one server or client, but I think in your case each sub_demon is intended to be a separate server and the TCP Manager is getting crosstalk between the multiple instances of the sub_demon, returning the TCP connection created in one server to the code in the other server.

 

You should probably create a separate instance of the TCP Connection Manager for each server instance to avoid this cross talk. I don't know if this is the only problem, but it is something to start with and see if that fixes your problem.

authored by
Christian L, CLA
Systems Engineering Manager - Automotive and Transportation
NI - Austin, TX


  
0 Kudos
Message 153 of 174
(3,302 Views)

Hi Christian,

I think that is exactly my problem!

but, due to the fact that I'm using the vi from the palette (so from the libraries in NI and not local),how can I do? simply save as a new vi locally in the project?

0 Kudos
Message 154 of 174
(3,298 Views)

In your sub_demon code, open up the TCP Connection Manager VI, and then save it (make a copy) under a different name in your project folder. Make multiple copies using different names, with one copy for each sub_demon. You may want to change the icon for each copy to be able to tell the difference in each sub_demon. 

 

In each sub demon you will need to replace each copy of the TCP Connection Manager VI with the new Connection Manager VI specific to that sub demon. 

authored by
Christian L, CLA
Systems Engineering Manager - Automotive and Transportation
NI - Austin, TX


  
0 Kudos
Message 155 of 174
(3,289 Views)

hi christian 

unfortunately it is not so simple, due to the fact that the new file would be included in the library STM, but it is not possible (it interferes with the original one).

So, I have to disconnect it from the library and make "public" all the vi that are "private" (as the STM error)

0 Kudos
Message 156 of 174
(3,282 Views)

You should save the new Connection Manager VIs outside of the STM library, and the only VI in the library that you should need to make public is Generate STM Error.vi.

 

Looking at your sub demon code, in addition to the TCP Connection Manager VI, you will also need to make unique copies of the TCP Check Connection.vi for each sub demon. Each unique TCP Check Connection vi needs to call its corresponding TCP Connection Manager vi.

authored by
Christian L, CLA
Systems Engineering Manager - Automotive and Transportation
NI - Austin, TX


  
0 Kudos
Message 157 of 174
(3,273 Views)

Thank you Christian!!! I will try and then I will report here...

0 Kudos
Message 158 of 174
(3,268 Views)

Hi Christian,

I’m commissioning the front end project, but it seems works in the right way!!!

now it is about one week working without any crashing...

 

I think that now STM may work in multitasking-multiserver, taking account the two vi’s should be replaced for each server

 

thank you again

 

dh

0 Kudos
Message 159 of 174
(3,187 Views)

Can anyone tell me why I'm getting error code 537650?

 

I have a cRIO-9030 talking to a Windows 7 PC using the NI Multi-Client Server Application Design Pattern Using Simple Messaging Library (STM) scheme.

http://www.ni.com/tutorial/53679/en/

 

In my host VI I open the STM connection, send STM message, receive STM response and then close the STM connection (yes I know it's not good to open and close constantly but it shouldn't cause a problem).  I found if I loop on this after exactly 228 messages, no matter how fast I go, I get the 537650 error.  If I monitor the CPU usage of the cRIO it never goes above 10% and the memory never goes above 20%.  The flattened data string I'm sending has a length of 67060.  I found if I send shorter strings I can send more message but eventually get the same error code.  Is there some sort of Windows TCPIP buffer that is not getting cleared? Right up until I get the error messages are getting through on time so it doesn't seem like a buffer is filling up.  It's like the buffer is not being cleared after I read it.  Is there someway to flush the TCPIP buffer on Windows or real time?  Is there a way to view the buffer?

 

 Any help or suggestion would be greatly appreciated.

0 Kudos
Message 160 of 174
(3,135 Views)