I'd like to implement the receiving end of my system in MATLAB - this requires Gigabit Ethernet with sustained speeds of over 200Mb/sec.
Using MATLAB's built-in UDP from the Instrument Control Toolbox does not appear to be sufficient. Are there any good alternatives?
If you know Java, you can write the networking part of your code in Java classes, load those into your Matlab session with javaclasspath(), and invoke them from M-code. This could transform the problem from getting the data through Matlab's udp() function to getting the data across the Java/Matlab boundary.
If the data can be put into batches:
Use an external program to download the data to your computer, and save it to a file. Then, Matlab can read from that file whenever it needs more data. That way you partition the problem into two manageable pieces - and if you're using a decent OS, the file will never leave RAM so you won't have to worry about speed.
Theres an very good Example for the Java UDP implementation on the Mathworks site.
(Link below)
http://www.mathworks.com/matlabcentral/fileexchange/24525-a-simple-udp-communications-application/content/judp.m
Related
Simply put, I need to take results from a DAQ and display them visually in a UI (no interaction needed) that gets information updated in real time. The DAQ I am using has an "utility" to plug into Labview, so it seems that the easiest way is to grab this data from Labview and then transmit that data to some UI using one of these methods.
I am using Windows 10 (although I could boot to Ubuntu), just not sure what UI application would be best / easiest to use.
You can use this National Instrument's tool for DAQ UI visualization. As it is native it should be quite straightforward to use.
You may want to use the DAQExpress VI in LabVIEW as #MateoRandwolf suggested. The neat thing about it is that it almost creates your first programm automatically -- besides the configuration of your NI modules.
There are just two things missing:
a waveform chart, and
a write to a TDMS file
Here is a snippit of a simple program doing this (the stop button is important to actually close the TMDS file before aborting the program)
If you really want to stream the data to a different device, you I suggest to use TCP/IP. There exist good examples in the documentation from which you can start (Help > Find Examples... > Search-tab). If you cannot accept the roughly 40ms buffer that TCP/IP has (because of shake-hands etc.), have a look on UDP.
You can use Dewesoft's DAQ systems which use dual mode capability. They use dual data buses (EtherCAT and USB). USB for high-speed buffered data storage to the PC's SSD hard drive and the EtherCAT bus for low latency real-time stream to any 3rd party EtherCAT master.
The DAQ systems are also capable of visualising data in real-time on the display using various pre-build visual displays like recorders, XY graphs, 3D graphs, osciloscopes, FFTs, GPS, video, and numerous other...
In my practice I faced with the task - visualize some process memory content in real time. The main idea is read arbitrary part of remote process memory, represent it as image, and show in a separate window, then repeat these action with some interval, and in result get dynamic visualization of memory content. For example, it will be useful for view framebuffers/textures that located in process memory. Do exists any tools/software for this purpose? Thanks.
So, I did not find any utilities, and so I created my own tool.
This is mem2pix, program which allows to real-time visualizing some part of remote process memory, supports many pixel format type. Currently works on both Windows and Linux.
Has anyone tried to create a log file of interprocess communications? Could someone give me a little advice on the best way to achieve this?
The question is not quite clear, and comments make it less clear, but anyway...
The two things to try first are ipcs and strace -e trace=ipc.
If you want to log all IPC(seems very intensive), you should consider instrumentation.
Their are a lot of good tools for this, check out PIN in perticular, this section of the manual;
In this example, we show how to do
more selective instrumentation by
examining the instructions. This tool
generates a trace of all memory
addresses referenced by a program.
This is also useful for debugging and
for simulating a data cache in a
processor.
If your doing some heavy weight tuning and analysis, check out TAU (Tuning and analysis utilitiy).
Communication to a kernel driver can take many forms. There is usually a special device file for communication, or there can be a special socket type, like NETLINK. If you are lucky, there's a character device to which read() and write() are the sole means of interaction - if that's the case then those calls are easy to intercept with a variety of methods. If you are unlucky, many things are done with ioctls or something even more difficult.
However, running 'strace' on the program using the kernel driver to communicate can reveal just about all it does - though 'ltrace' might be more readable if there happens to be libraries the program uses for communication. By tuning the arguments to 'strace', you can probably get a dump which contains just the information you need:
First, just eyeball the calls and try to figure out the means of kernel communication
Then, add filters to strace call to log only the kernel communication calls
Finally, make sure strace logs the full strings of all calls, so you don't have to deal with truncated data
The answers which point to IPC debugging probably are not relevant, as communicating with the kernel almost never has anything to do with IPC (atleast not the different UNIX IPC facilities).
I'm looking for some input on witch file transfer protocol to use over a serial line. I want to be able to transfer files of max 200 Mb size over a serial line (RS232) in both directions, but only one of the machines needs to be able to initiate the get/put (think master-slave).
The protocol also needs to be:
Easy/simple to implement since I would need to write both client and server myself (limited, embedded hardware)
Fairly robust, fault checking/recovery etc
At least somewhat standardized, in case I need to get a third party to implement it on some other hardware
Kermit? TFTP? Simplest possible home brew? What do you think?
In the beginning was the Xmodem, which was very simple to implement. Chuck Forsberg looked at the xmodem and decided it was inefficient, so he begat the Ymodem, but it's implementations were buggy and both x and ymodem were replaced with Zmodem.
Kermit followed on later. Kermit would probably be the "Standard" way to implement this. Do you have access to libraries for Kermit that will run on your embedded platform? If not I would probably consider one of the other options.
If ease of implementation is your primary concern then Xmodem wins hands down.
I'll try to be brief, but fully descriptive:
This is Windows-specific. Using the Windows Driver Development Kit (DDK).
I am writing a Kernel Mode Driver (KMD) for the first time, having no prior experience in Kernel Mode. I am playing around currently with the "scanner" mini-filter sample which comes with the DDK, and expanding upon it for practice. The "scanner" mini-filter is a basic outline for a generic "anti-virus" type scanning driver which hooks file creates/closes and operates on the associated file to scan for a "bad word" before approving/denying the requested operation.
The end goal is to scan the file with the user-mode application when it is opened, deciding whether or not the mini-filter should allow the operation to complete, without noticeable slow-down to the process or user which is attempting to open the file. I will also want to scan the entire file again when a save is attempted to decide whether or not to allow the save to complete successfully or deny the save. The mini-filter sample lays out the groundwork for how to hook these calls, but is a bit weak in the actually "scanning" portion.
I am looking at expanding the sample to scan the entire file that has been opened, such as to generate a hash, rather than just the first 1k (the sample's limit). I have modified the sample to read the entirety of the file and send it using the same mechanisms within the original sample. This method uses FltReadFile to read the file within the KMD and FltSendMessage to send the buffer to the user-mode component. The user-mode application is using GetQueuedCompletionStatus to grab the notifications from the KMD and process the buffers.
However, I'm noticing that this process seems to be pretty slow compared to a normal open/read in C++ using the standard library (fstream). This method is taking between approximately 4-8 times longer than simplying opening and reading the file in a simple C++ user app. I have adjusted buffer sizes to see if it makes for a noticeable improvement, and while it can help slightly, the benefits have not appeared to be very significant.
Since I am looking to scan files in 'real-time', this rate of transfer is highly disappointing and prohibitive. Is there a faster way to transfer a file's contents from a Kernel-Mode Driver to a User-Mode Application?
I can suggest several solutions:
Use DeviceIoControl with METHOD_OUT_DIRECT transfer type to pass large amounts of data.
Create memory section and map it to your process (remember about limited address space on 32-bit platforms).
Pass file path to your application and open it there.