Serial communication blocks of real-time windows target do not
in [Matlab]
|
From: Jose on 19 May 2010 15:22 Hi Guys, Did you get any way around this problem? I was trying to use the Serial Receive block of the Instrument Control Toolbox on the RTW environment but the block does not receive anything from the serial port. I tried various sampling rates but it just doesnt work. I would like to have it reading at 20ms. I am working with the RTW because I am using some NI DAQ boards at the same time to read encoders. Thank you, Jose "John Woods" <akimgsoc(a)gmail.com> wrote in message <hgs471$1fq$1(a)fred.mathworks.com>... > Hi Jan, > > Thanks for the reply. > > I have a few questions and comments regarding your post. > > 1. You mention that RTWT rs232 interface has a known 2 ms limitation. Where is this documented? > > 2. I agree with your comment about the data throughput. However, what is the use of that throughput if I can not use, for example, an A/D converter (say, 16-bit) with an rs232 interface to send data to Matlab in real-time faster than 100 samples/s. > > 3. It may be 500 bytes/s in your setup but it is 100 bytes/s in mine. > > 4. In a well designed system (hardware + software), the limitation should come from the maximum baud rate of the UART not from Matlab/RTWT or Windows. After all, how long does it take to read/write a byte from/to UART? Perhaps, a few nanoseconds? > > Best regards, > > John > > > Jan Houska <houska(a)humusoft.com> wrote in message <4B2FB646.4020509(a)humusoft.com>... > > Hi John, > > > > currently, the Real-Time Windows Target RS232 interface is unable to > > accept new data in periods shorter than 2 ms. This is a known limitation > > and there's work in progress to remove it. This does not directly relate > > to the data throughput - if you are sending data in packets longer than > > one byte, you can easily get to the full data capacity. But, if you are > > sending just one byte in each sample, it is correct that you currently > > cannot get higher than 500 bytes/s (not 100 bytes/s as you write). > > > > The current solution to get faster than 2 ms sampling period has some > > severe drawbacks on the overall system performance, and is not shipping > > with the product yet. It is important to keep in mind that on that 486, > > you had the whole CPU for your own use. On Windows, you need to let the > > OS and other applications run while still maintaining real-time response > > in Real-Time Windows Target. With devices where Windows strongly > > interfere, like the RS232, this is not easy to do. > > > > If you are interested in more detail and if you want to try some > > preliminary versions of the higher-speed driver, please send me an e-mail. > > > > Best Regards, Jan > > > > > > John Woods wrote: > > > I made a mistake in my previous post. 1/10 should be replaced by 1/100 > > > in my previous post. That is, we can not achieve 1/100 of the available > > > capacity (11520 bytes/s). > > > > > > Sorry about this. > > > > > > John > > > > > > > > > "John Woods" <akimgsoc(a)gmail.com> wrote in message > > > <hgnk4b$s5u$1(a)fred.mathworks.com>... > > >> Hi Frank, > > >> > > >> Thank you very much for your reply. > > >> The bottleneck here is not really the hardware (the relatively slow > > >> speed of rs232) but poor programming (on both Matlab and Windows > > >> side). With 115200 baud (which is the standard maximum speed of the > > >> com port), it is possible to achieve 11520 bytes/s "real-time" > > >> transmission using 8 data + 1 start + 1 stop bit (without even using > > >> the FIFOs). In fact, if I remember correctly, I was achieving this > > >> data rate with an i486 running at 33 MHz. Now, I can not achieve a > > >> rate faster than 100 bytes/s with a 3.2 GHz dual core i586. > > >> > > >> The potential "real-time" transmission rate of the serial port is not > > >> really that bad at all (11520 bytes/s). However, thanks to the > > >> excellent utilization of hardware resources in Matlab and Windows, we > > >> can not even achieve 1/10 of that available capacity. Unfortunately, > > >> buffering the data is not a solution as the communication is supposed > > >> to be "real-time". > > >> > > >> Best regards, > > >> > > >> John > > >> > > >> > > >> > > >> > > >> "Frank W." <yohansan(a)web.de> wrote in message > > >> <hgnfnn$ml1$1(a)fred.mathworks.com>... > > >> > > > I am trying to use real-time windows target to communicate with > > >> another computer >through the serial port. The problem I have is that > > >> the serial communication blocks of >real-time windows target do not > > >> work in real-time. I am using Matlab 2007b but I have >also tried > > >> Matlab 2009a and had exactly the same problem. Is there any way to fix > > >> the >problem? > > >> > > Hi, > > >> > I would first (befoe setting up the project) calculate if the data > > >> really can be transmitted in real time. Depending on the baud rate you > > >> use you know the amount of bytes that can be transmitted. If this > > >> value is too small either increase the baud rate and/or minimize > > >> protocol data (if this is possible). If you use your own protocol > > >> consider buffering data and processing unimportant tasks at a lower rate. > > >> > If there is still too much data you'd have to use ethernet. > > >> > Regards > > >> > Frank > > > > > > -- > > > > -- > > Jan Houska HUMUSOFT s.r.o. > > houska(a)humusoft.com Pobrezni 20 > > http://www.humusoft.com 186 00 Praha 8 > > tel: ++ 420 284 011 730 Czech Republic > > fax: ++ 420 284 011 740
From: Aitor on 19 May 2010 17:49 Hi people, I am trying to do the same as Jose explain in the previous post. I tried with the standard "Serial Receive" block form Simulink but this block doesn't receive anything in the RTW... The next step was the implementation of a S-function to read the serial port. I have chosen C++ to implemented it with the Win32 API, windows.h and the functions that I use are CreateFile, CloseFile, GetCommState, SetCommState and CloseHandle. When I try to execute the model (after compile the cpp, build the model and connect to my target) I get the next error: Error occurred while executing External Mode MEX-file 'quarc_comm': ExtTargetPktPending() call failed while checking for target pkt. After reading a lot about serial port in RTW, I try to solve my problem, I have some questions: 1. Is it possible to read data from the serial port in the RTW? Or Am I trying something impossible? 2. Is the problem the C++ processing time? Should be better to perfom it with C using "File Descriptors" (open, read, ...)? 3. And If I am going in the good direction, why do I get this error? What does it means? Thanks in advance, "Jose " <jose.araujo(a)fe.up.pt> wrote in message <ht1dpb$qq5$1(a)fred.mathworks.com>... > Hi Guys, > > Did you get any way around this problem? I was trying to use the Serial Receive block of the Instrument Control Toolbox on the RTW environment but the block does not receive anything from the serial port. I tried various sampling rates but it just doesnt work. I would like to have it reading at 20ms. I am working with the RTW because I am using some NI DAQ boards at the same time to read encoders. > > Thank you, > Jose >
|
Pages: 1 Prev: naming a .NET component Next: Problem with patch properties |