xpc target error: xpcgate

[Cho]

Dear all:

Hello,
I'm posting a message to report/ask a strange error that I
am having with xpctarget set ups.

Okay, I've boot up xpC Target 3.4 kerenl on Micro-box and
connection works just fine. I can connect, ping works and
everything.

But once I try to download the built model(dlm files), it
gives me error saying:

Error using => xpcgate
TCP/IP timeout while recieving data

then connection errors & freeze up.

I tried to increase the timeout value and tried with
different boot up methods(dosloader,boot floppy), but it
still gives me error.

I've tried xpctest also, and
Test#1,2,3 shows 'ok' , but

Test#4.Build and download application - Failed.

shows up.

Does anybody know what causes these errors and
solution/suggestion?

Any help is appreciated. Thanks.

[Cho]

Add on:

Target and Host are connected through TCP/IP.
Board: R8139 using PCI-BUS

Builiding Correctly.
Comunicating Correctly.

But Downloading Not working. Is it possible?

I am also attaching exact error message in details.

Thanks in advance.

==================ERROR LOG==========================

Error building Real-Time Workshop targe for block
diagarm 'xxx'.

Matlab err message:

Error using ==> RTW.makertw.callMakeHook at 49
The call to xpctarget_make_rtw_hook, during the exit hook
generated the following error.

Error using ==> xpcgate
TCP/IP Connect Error

The build process will therminate as a result.
======================================================

Any suggestion will be highly appreciated.

[Cho]

Add on:

I am attaching actual error log for details.

Thanks in advance

------------------ERROR LOG-------------------

Error builing RTW for block diagarm 'xx'

Error using ==> RTW.makertw.callMakeHook at 49.
The call to xpctarget_rtw_hook, during the exit hook
generated the the following error.

Error using ==> xpcgate
TCP/IP connecterror

------------------------------------------------

[Gordon Weast]

Cho,

This error message on the host is just telling you that the
target isn't responding to commands.

What do you see on the target display?
Does it get to the 'System: initializing application finished' message?
What's the last thing printed in the text window?

To debug this, you really should contact tech support. That will
open a trouble report so we can track it.

Gordon Weast
xPC Target Development
The MathWorks

[Cho]

Thanks for the kind reply, Gordon.

The last things that I see on the display is:

"System: download started ..."
"System: download finished"

Then boom, it gives error message and gets really slow down.
I am using xPC target 3.4 with 2008a.

We are getting new hardware for the target today, so I
guess I should contact tech support if the new one still
gives me same problem. The hardware company that we're
contacting uses xPC target 3.2 and says they had no such a
problem. I don't know if that affect so much.

Anyways, thanks again for your help and I'll keep posted.

Regards,
cho

Gordon Weast <gwe...@mathworks.com> wrote in message
<g8k28l$rjb$1...@fred.mathworks.com>...

[Anish]

Hi Cho,

What compiler are you using? Have you tired a different
compiler?

AA

"Cho " <woonhy...@gmail.com> wrote in message
<g8j689$ot5$1...@fred.mathworks.com>...

[Gordon Weast]

Cho,

As Anish points out in his response, the compiler choice matters here.

In 2008a we encountered a problem with the startup code that MSDEV 8.0
(.NET 2005) brings in. With some models, we see a null pointer
dereference during the startup code execution. We finally found the
cause and fixed it for 2008b. The problem doesn't show up all of the
time, but depends on the particular model you're building. Downloading
immediately after a target reboot usually works, but then repeating
the same download may work or fail. The intermittent nature of the
crash made it very hard to find. Even a small change to a model may
cause a working model to crash.

Older MSDEV compilers (6.0 and 7.1) and the Open Watcom 1.3 compiler
don't have the problem. In R2008b, we also support Open Watcom 1.7
and MSDEV 9.0 (.NET 2008) professional.

[Cho]

Gordon, Anish,

Thanks so much for your help!!!

Yes, it was a compiler problem.
I was using watcom 1.7 and switched to 1.3 and
finally it works fine.

I really appreciate it and this was acutally my first time
posting a message on newsgroup and so impressed.

Thanks gordon,anish.

Have a nice weekend!

Cho

"Cho " <woonhy...@gmail.com> wrote in message

<g8ipja$not$1...@fred.mathworks.com>...

[Thorsten]

Hello Gordon,

I have nearly the same problem as Cho.
My setup:
Windows XP SP2
Matlab Version: R2007a
Tested Compiler: Watcom 1.3 / Watcom 1.7 / Watcom 1.7a / Visual Studio 2005

At first I have had no problems with Visual Studio Compiler, the basic xpc demos ran quit well, but the more complex rs232 demos like xpcserialbinarysplit.mdl causes everytime a timeout error as Cho wrote above.

------------------ERROR LOG-------------------

Error builing RTW for block diagarm 'xx'

Error using ==> callMakeHook.p>callMakeHook at 47
The call to xpctarget_rtw_hook, during the exit hook generated the the following error:

Error using ==> xpctarget.xpc.load at 38
TCP/IP timeout while receiving data

------------------------------------------------

Following your suggestions, I tried to use Watcom 1.3 - no succsess.. also tested version 1.7 / 1.7a looks like there are not supported in R2007a.

Any further ideas?

thx
Thorsten

[Thorsten]

add information:

I found this article:
-----------------------------------------------------------
Subject:
Why do I receive a TCP/IP timeout error while receiving data using xPC Target 3.3 (R2007b)?

Problem Description:
When I use xPC target to send data from the target to a host machine, I receive the following error message at the MATLAB command prompt, when the packet size is large:
'TCPIP timeout error while receiving data'

Solution:
This behaviour is not due to a bug in xPC Target, 3.3 (R2007b) but is related to the default TCP/IP timeout settings on a user machine.

In order to change the default TCP/IP timeout value prior to executing a MATLAB program, execute the following script at the MATLAB command prompt:

[status, result]= system('ping -w timeout_millisec destination_host');
%Changes the default timeout to 'timeout_millisec'
if(status~=0)
disp('The timeout settings could not be changed from MATLAB, please try changing the timeout manually');
end

The above script can also be added to the MATLAB startup options.

------------------------------------------------------
source: http://www.mathworks.com/support/solutions/data/1-4YJCXT.html?product=XP&solution=1-4YJCXT

by execution at the command prompt:
"The timeout settings could not be changed from MATLAB, please try changing the timeout manually"

Where to modify the timeout settings manually?

[Thorsten]

I got it!

Solution: increasing timeout value..

just follow this article:

Increasing the Time-Out Value

By default, if the host PC does not get a response from the target PC after downloading a target application and waiting about 5 seconds, the host PC software times out. On the other hand, the target PC responds only after downloading and initializing the target application.
Usually 5 seconds is enough time to download a target application, but in some cases it may not be sufficient. The time to download a target application mostly depends on your I/O hardware. For example, thermocouple hardware takes longer to initialize. In this case, even though the target PC is fine, a false time-out is reported.
To increase the time-out value, use the following procedure:

In your MATLAB working directory, create a file called xpcdltimeout.dat.
In this file, put a single integer. For example, enter
20
In this case, the host PC waits for about 20 seconds before declaring that a time-out has occurred. Note that it does not take 20 seconds for every download. The host PC polls the target PC about once every second, and if a response is returned, declares success. Only in the case where a download really fails it does take the full 20 seconds.
If the file xpcdltimeout.dat exists, it is read once before every download. To change the time-out value, change the number in this file. Setting the time-out to 5 is the same as the default. Note also that simply removing the file does not change the time-out to the default value. xPC Target uses the last value you entered until you restart MATLAB.

greets
Thorsten

[Anish]

In order to increase the host-target communication period you can also use the following command:

xpcgate('settimeout',10); %this will increase the timeout period to 10 seconds

AA

"Thorsten " <prot...@gmx.de> wrote in message <gaauli$e3p$1...@fred.mathworks.com>...

[Gordon Weast]

Also, starting in R2008a, you can set a model specific communication
timeout.

On the xPC Target options page of the model's configuration parameters,
you will see a checkbox in the 'Target options' section with the label
'Use default communication timeout'. If you uncheck that box, then you
can specify a different timeout value.

Creating an xpcdltimeout.dat file continues towork for all models as
long as the file is visible on the path.

Gordon Weast
xPC Target Development
The MathWorks

[mikel]

where is the working folder.. where my *.mdl is located?

[Gordon Weast]

The working folder is the current working directory for MATLAB.

You can display that using the pwd command at the MATLAB prompt.
That doesn't have to be the directory where the mdl file is, but
often is. It's also the directory displayed in the directory
browser window.

Gordon Weast
xPC Target Development
The MathWorks

[mikel]

i did increase the timing but still the same timeout error persists. Is there any other reason why this error shows. Im actually connecting to xpc target to a PCI-CTR05 card. I have another card, the humusoft MF614 but that has no problems. I get a timeout error with the pci card. When i decide to specify the slot its located, xpc shows that there is no device installed. I use the "getxpcpci" command to get the slot no. of the card installed.

[Gordon Weast]

I really can't give a definite answer with the information you've
given so far. I suspect a configuration problem, but without
more information, I can't be sure.

Are you taking both bus and slot from getxpcpci and inserting that
in the PCI-CTR05 block, [bus,slot]? If you just put in a slot number
without bus, it assumes bus 0.

After you get one of the timeout errors, if you wait a bit, can you
issue xpctargetping and get success? If not, then the target has
crashed and no timeout increase will help. If this is the case,
then contact tech support and they will collect more detailed information
from you and we can work through the problem.

Gordon Weast
xPC Target Development
The MathWorks

[Jonathan Kuniholm]

Hi all -

I've been having the same trouble and currently have a trouble ticket in on it. Peculiar to my situation, xpctest works fine, and some models load and run fine some of the time, but the xpcgate error appears inconsistently and affects performance. Sometimes, there's a comm error on build, but the model runs anyway.

Most frequently, target comm is lost when a model is loaded or run, and can be restored sometimes with a target reboot. Sometimes, the model can be run or stopped through xpcexplr, but then not stopped or started after that. In this case, occasionally comm can be restored by disconnecting and then reconnecting to the target, after which the state (running or stopped) is recognized and can be reversed.

Occasionally, target ping fails and !ping succeeds.

Sometimes, these errors are so significant that the only way to fix them is to force quit matlab. When this happens, before the quit is complete, a whole bunch of unfinished processes seem to run through the command window. I've so far been unsuccessful in copying them before the quit is done, but they look like build output.

I've tried Visual 2003, 2005, Watcom 1.3 1.7, Matlab 2008a,b, and all combinations of these, but haven't been able to pin it down. Debugging embedded stuff is hard enough without these problems, and I'd love to see a solution. We'd go back to 2006, but we've incorporated a bunch of features in 2008 and can't go back, it appears.

Thanks for the help.

Jon

Gordon Weast <gwe...@mathworks.com> wrote in message <gghft3$npd$1...@fred.mathworks.com>...