TCP/IP is "fire and forget", does not wait for an answer to your packets, etc. It is only a "best effort" way of communication, and as such, links/communication is not guaranteed. You may want to look into using a different protocol, maybe UDP, in your implementation.   But I may be wrong, and barking at the wrong place in your code.

@Ion

Thanks fro your suggestion. In fact, I am using both tcp/ip and udp. I have an image processing waiting for framesAvailable events from a camera, which is triggered externally, and have to send some results via Modbus/tcp. On the other hand, I have a simple control of the process via udp. I have assumed that the callback processing for both the videoinput object and the udp (onDatagram) would run on a separate thread, even when deploying as a console application, so that I could just pause() at the end of my main function, and terminate the execution only when signaled to via udp message.

Sample code:

function test()

% nested functions:

function ctlsocket=CtlSocket(host,base_port)

ctlsocket=udp(host,2*num+base_port,'LocalPort',2*num-1+base_port);

% TODO: implement proper handling of messages received.

% ctlsocket.DatagramReceivedFcn=@(obj,evt)...

% cellfun(@disp,{obj,evt.Type,evt.Data,fscanf(obj)});

ctlsocket.DatagramReceivedFcn=@onDatagramRcvd;

fopen(ctlsocket);

end % CtlSocket

function onDatagramRcvd(obj,evt)

%cellfun(@disp,{obj,evt.Type,evt.Data});

s=fscanf(obj);

s=s(1:end-2);

cmd_done=false;

if cmd_done||isempty(s),return,end

% TODO: We could handle aditional arguments, by splitting s on

% whitespace (or use a proper regexp). This could be useful for

% setting the prior probabilities on-the-fly.

handleCommand();

end % onDatagramRcvd

function handleCommand

switch s

case 'start'

disp('started')

case 'stop'

disp('stopping...')

delete(ctl)

clear

end

cmd_done=true

end % handleCommand

% Initialization:

num=1

s='start';

cmd_done=false

ctl=CtlSocket('localhost',9090)

system(['start nc -v -c -u ','localhost',' ',num2str(9090+2*num-1)])

disp('starting...')

%wait(ctl) % no such method...

pause

disp('exit')

end % test

@Peter

Thanks for your comments. They made me think a bit more about how to formulate questions, the multiple diverse audiences a question might have, and what purpose they serve (only for the original poster, or for other people?). Still, I think your answer is polluting this thread with many questions unrelated to the original post.

I realize the code above might be difficult to decode for those who are not familiar with Matlab. My question is pretty much specific to Matlab. I don't need help with what I want my code to do, it already does exactly what I want. The question is about a feature or internal working of Matlab Compiler Runtime.

Still, although it is getting a bit off-topic, I will try to explain the code in previous comment, and make it a bit more understandable for those who might not be familiar with Matlab.

You are right in your comments about tcp versus udp. That is precisely why I am using tcp for some communications and udp for other (and also because the tcp listening in Matlab is blocking, i.e., it doesn't return control until a connection is opened remotely).

My workflow is as follows:

I have three image processing tasks that need to grab frames from three cameras. They should run indefinitely, waiting for frames being acquired, processing them, and producing a result. This result is sent to an PLC that controls some equipment according to the result for each frame. This is time critical, so I want to avoid having to initialize the video input object repeatedly. So, I initialize three workers, possibly on different processor cores, each one attached to a camera. This is event-driven, in that there is a callback routine that is called when a camera has a frame available. After processing, a result is sent via tcp using modbus protocol.

Those workers are console applications, with no gui, so that I don't need to load a java virtual machine. So I want to be able to control them using simple udp messages (no need to have guaranteed delivery, and also don't want to block waiting for a connection - I want it to be event-driven).

Normaly, when running code under Matlab workspace (with or without the Matlab IDE ), there is a base workspace that isn't destroyed even after your code has returned, and keeps your callbacks running. So, your app just sets the proper callbacks, and exits, but the objects that use your callbacks, and in fact all their context, is still available until you terminate Matlab environment. That is somewhat like a closure.

But when you compile your app into an executable, it starts a Matlab environment via Matlab Compiler Runtime (MCR), which only lives until the main app exits. Of course I don't want to do busy waiting, so I tried to use pause to prevent the main function from exiting. But that pauses also the callback processing, because it seems there is only a thread (whereas in normal Matlab usage there will be a main ui thread).

// Pseudo-code:

function worker(number)

// create a udp object, equivalent to nc -u localhost -p

controlSocket=udp('localhost',,'localPort',)

// set an event handler (@handleCommand is a reference to a function, not depicted here) to respond to external commands sent via udp.

controlSocket.onDatagramReceived=@handleCommand;

end

The code above would work as intended under Matlab environment; if I start netcat with

system('nc -u localhost ')

I will be able to send commands to my 'zombie' application, which will invoke the handleCommand callback I defined.

If it is compiled, no luck.

There is one solution I didn't try yet, that consists of using wait(vid), which blocks the current context until the object vid is stopped (vid being a videoInput object).

This is getting too long, I will try some solutions and will report the results later.

P.S. I removed the topic Code Development becaus I think it is too broad a scope for this question.

Hello,

Just a quick update on this issue... I finally fixed it. It was a very stupid error - I forgot the -c flag in the nc invocation (to send CR/LF), so Matlab wasn't processing my commands at all, even though everything was ok regarding the communication. I have assumed a fairly complicated reason for it not working, instead of thoroughly check the simple things...

Hi, Peter,

The version of netcat I'm using is a port to windows, and it uses a slightly different syntax from the *nix version.

Anyway, for the benefit of anyone that might look at this thread, I attached a minimal example of the structure of the code I have working.

http://pastebin.com/n42XCy36

Thanks for pointing out those flaws. I reckon my example may be a bit flawed/buggy. It was not my intent to present a textbook example of how to implement a communication protocol. This is only intended for non-critical stuff. The critical part is handled via modbus tcp, and altough that might also be buggy (I just skimmed through the specification, and implemented only what I needed), it is inherently more robust. I am no specialist in networking, and in fact it is the first time I have used network connections in matlab.