core 2 duo XPC target video not working
in [Matlab]
|
Prev: Divergence application
Next: Reading a Header txt file
From: Stephen on 26 Jul 2010 17:29 Even in single core mode, I find I am unable to download data over TCP/IP from the target (even very small amounts of data). I always get a "TCP/IP timeout while receiving data" error. I've even upgraded to R2009bSP1. Is this also an issue with the hardware I am using? Since my application would significantly benefit from utilizing the second core to download data while the model continues to run on the first core, I am still very interested in upgrading my hardware to make this possible. Can someone provide part #'s for motherboards that do support xpc's duo core capabilities? Maybe the names of motherboard manufacturers that people have had success with leveraging xpc's duo core functionality. Gordon Weast <gweast(a)mathworks.com> wrote in message <htoi8q$r2o$1(a)fred.mathworks.com>... > Stephen, > > Unfortunately, there are differences in how the multi core hardware > is implemented that we have trouble working with. > > Since your machine does work in single core mode, you could continue > using it that way. For many models, single core mode turns out to > be just as fast as multi core mode for current releases. > > Because of the difficulty in finding machines that work well in > multi core mode, we've just announced a new partnership with > Speedgoat GmbH called xPC Target Turnkey. See: > > http://www.mathworks.com/products/xpctarget/supported-hardware/index.html > > for a discussion of this. We are working with this vendor to > guarantee that these machines will work well with xPC Target. > > Too many new PC class machines are optimized for Windows with > no regard to being able to be used in real time mode the way > we need them. > > Gordon Weast > xPC Target Development > The MathWorks > > Stephen wrote: > > I'm building a new XPC target with an Intel Core 2 Duo E8500 3.16G > > processor with a SUPERMICRO MBD-C2SBC-Q-O motherboard. I'm using Matlab > > R2009b and when the "enable multicore support" option is disabled, the > > XPC target boots up as expected with working video and communication > > with the host. However, when the multicore support is enabled, the XPC > > target goes through the boot process (as indicated on the XPC target > > boot up screen), then video is lost as well as communication with the > > host. I've gone through the BIOS settings and matched what is suggestion > > on the Matlab website (disabled USB, disable hyper-threading, etc) and > > it still doesn't work. Any suggestions?
From: Walter Roberson on 26 Jul 2010 18:32 Stephen wrote: > Even in single core mode, I find I am unable to download data over > TCP/IP from the target (even very small amounts of data). I always get a > "TCP/IP timeout while receiving data" error. I've even upgraded to > R2009bSP1. Is this also an issue with the hardware I am using? Possibly, possibly not. Did you define a specific destination port for the server so that the client knows how to reach it? Those consumer-level "switches" you can buy these days are often repeaters rather than switches. If you toss a 3 or 5 port consumer switch into the mix, you should be able to add in another machine running a program such as "netsnoop" to monitor the IP traffic and see what makes it to where.
From: Stephen on 29 Jul 2010 14:52 Walter Roberson <roberson(a)hushmail.com> wrote in message > > Did you define a specific destination port for the server so that the client > knows how to reach it? I simply ran "data = target.outputLog;" from the command prompt of the host machine. I was just using the TCP/IP connection that the host uses to communicate with the XPC target to get data off the target. I specified the target IP address in "xpcexplr". I didn't think I had to provide the host IP and port to the xpc target. > Those consumer-level "switches" you can buy these days are often repeaters > rather than switches. If you toss a 3 or 5 port consumer switch into the mix, > you should be able to add in another machine running a program such as > "netsnoop" to monitor the IP traffic and see what makes it to where. This is a good idea because I haven't really looked into the details of the switch we're using. I'll look into this. Thanks!
From: Walter Roberson on 29 Jul 2010 15:15 Stephen wrote: > Walter Roberson <roberson(a)hushmail.com> wrote in message >> >> Did you define a specific destination port for the server so that the >> client knows how to reach it? > > I simply ran "data = target.outputLog;" from the command prompt of the > host machine. I was just using the TCP/IP connection that the host uses > to communicate with the XPC target to get data off the target. I > specified the target IP address in "xpcexplr". I didn't think I had to > provide the host IP and port to the xpc target. Ah, I do not have any knowledge of the host / target communication for that functionality. My reference to server ports was under the assumption that you were creating a TCP connection while the target was running the target program (a facility which is possibly not implemented yet, though UDP is supported.)
From: Gordon Weast on 29 Jul 2010 16:35
Stephen, How big is your outputlog? There can be issues with very large log transfers. You can split it up by transferring smaller ranges. data1 = target.outputlog(1:10000); data2 = target.outputlog(10001:20000); etc. Then put them all together. Do you have trouble getting smaller pieces of the outputlog? If this workaround doesn't work, then please contact tech support and we'll look deeper into it. Gordon Weast xPC Target Development The MathWorks Stephen wrote: > Walter Roberson <roberson(a)hushmail.com> wrote in message >> >> Did you define a specific destination port for the server so that the >> client knows how to reach it? > > I simply ran "data = target.outputLog;" from the command prompt of the > host machine. I was just using the TCP/IP connection that the host uses > to communicate with the XPC target to get data off the target. I > specified the target IP address in "xpcexplr". I didn't think I had to > provide the host IP and port to the xpc target. > >> Those consumer-level "switches" you can buy these days are often >> repeaters rather than switches. If you toss a 3 or 5 port consumer >> switch into the mix, you should be able to add in another machine >> running a program such as "netsnoop" to monitor the IP traffic and see >> what makes it to where. > > This is a good idea because I haven't really looked into the details of > the switch we're using. I'll look into this. Thanks! |