-
Notifications
You must be signed in to change notification settings - Fork 22
Home
-
The lock file for shared memory is cbSharedDataMutex.lock, that is how multiple processes may access the same data, the first access becomes master (with UDP connection), the rest become client. This is useful only if multiple processes want to connect to the same NSP, for example a Python, an Octave, a MATLAB and a C SDK based application. Each process may have up to 4 active connections as master by providing the instance number. Lock files are crated in $TMPDIR (/tmp if not specified) and library will not run if the locks are not accessible to the user.
-
There are 6 shared memory files use “ipcs -ma” shows memory segments, then one can use “ipcrm” to remove them. I am going to put specific names of those files here to explain in the wiki
- I started cbpy with a CPython implementation; at the time I had only seen the poor (and ugly) way MATLAB extensions are written as mex. The CPython implementation here is NOT recommended for use, it is too convoluted. I have kept it just to have a frame of reference to copy docstrings from.
Instead the Cython implementation here should be used, it is working and has a familiar setup.py install.
- Use this to increase the socket buffer length
The 16MB buffer is the recommended value
sysctl -w net.core.rmem_max = 16777216
sysctl -w net.core.rmem_default = 8388608
You can alternatively try to specify the buffer length via 'receive-buffer-size' but it is not recommended, and may not work or may time out.
Please read this before using the SDK on OSX, otherwise cbmex/cbpy will warn and basically tell you what you are reading in this file.
- If you are running OS X Mountain Lion tell Gatekeeper that you own the device, and are not planning to use it like a big iPod. You’ll find Gatekeeper inside the Security and Privacy pane in System Preferences, select 'anywhere' there.
Open a terminal to issue some commands required for performance tuning, remember the data rate is potentially high. You probably need to use 'sudo' for these commands. (Alternatively, see the Blackrock KB article on this topic)
- To increase the shared memory buffer
These commands increase the sys-v shared memory (I may fix this requirement in the future by avoiding QSharedMemory that uses sys-v)
sudo sysctl -w kern.sysv.shmmax=33554432
sudo sysctl -w kern.sysv.shmall=4194304
- To increase UDP memory buffer (default value on OSX is much lower than other OSes)
First try our luck and see if you can set maxsockbuf without changing boot parameter.
sudo sysctl -w kern.ipc.maxsockbuf=8388608
If the above complains, your RAM is low try the following: First see what the current value is: The first command here requires reboot and changes the boot parameter
nvram boot-args="ncl=65536"
shutdown -r now
sysctl -w kern.ipc.maxsockbuf=8388608
If the above complains (your RAM is low) or if you do not want to change boot parameters, try the following. First see what the current value is:
sysctl kern.ipc.maxsockbuf
Mine is 6291456, but if yours is lower than 4194304 try this:
sysctl -w kern.ipc.maxsockbuf=4194304
If the above complains, your RAM is low try lower values (but it is not recommended), remember the value you set. If the value is anything but 8388608, when opening the library provide it like this:
cbmex('open', 'receive-buffer-size', value_above)
These sysctl values that you found can be put in /etc/sysctl.conf (create one if it does not exist), next time OSX boots it will read the values from there and you won't need to set them again. Something like this:
kern.sysv.shmmax=33554432
kern.sysv.shmall=4194304
kern.ipc.maxsockbuf=8388608
- Since 6.03 uses low port numbers we have to run MATLAB as root, or allow low port numbers, sorry but this is fixed in 6.04 onwards.
If you wish to write an application to link to cbsdk and you are using an Express or Community edition of MSVC then you must set compiler definition NO_AFX. For example, use cmake target_compile_definitions: target_compile_definitions(my_app PRIVATE NO_AFX).
Pleas go to the build folder and do this:
cmake .
It will shows which Python or MATLAB or Octave (if found) will be used to build cbpy and cbmex. You need to install the development sources of Python. MATLAB headers and libraries can be copied to Matlab placeholder directory too. If MATLAB is not found, try the placeholder approach (manually copy libmex, libmx, libmat, and all the headers). If Python and NumPy are found a target to build cbpy is added. If MATLAB headers and libraries are found a target for cbmex is added. Similarly if Octave development is installed cbmex for Octave will be built.
To make all targets:
make all
And finally to install
make install
The Python modules will be installed in site-packages directory, the cbsdk goes to the lib folder of install prefix, and cbmex will have a dedicated directory in the prefix.
You can install the cmake executable from cmake binaries. Open a Visual Studio command prompt, and perform the commands there. Qt needs to be installed, Python and MATLAB (libraries and headers only) are optional for cbmex and cbpy. I recommend to install Python in the default location so that it can be found easier, you should also install NumPy.
I have tried the Homebrew installation, and its Python and Qt, and everything should work out of the box. Remember that cbpy is an extension and needs shared library version of Python libraries to work. The officially installed Python may not be suitable.
If you are using Homebrew version of Qt5 then you may have to append the following to your cmake command: -DCMAKE_PREFIX_PATH=$(brew --prefix qt5).
If the target system does not have HomeBrew installation you should make the binaries as a bundle. Effectively bundles substitute the hard-linked dependency paths to relative paths. First check current dependencies:
otool -L /usr/local/CereLink/cbmex.mexmaci64
And if QtCore and QtXML are not relative perfom this:
install_name_tool -change /usr/local/lib/QtCore.framework/Versions/4/QtCore @rpath/QtCore /usr/local/CereLink/cbmex.mexmaci64
install_name_tool -change /usr/local/lib/QtXml.framework/Versions/4/QtXml @rpath/QtXml /usr/local/CereLink/cbmex.mexmaci64
then verify again:
otool -L /usr/local/CereLink/cbmex.mexmaci64
To make sure inter-dependencies are also relative, first copy QtCore and QtXml to '/usr/local/CereLink' then:
otool -L /usr/local/CereLink/Qt*
install_name_tool -change /usr/local/Cellar/qt/4.8.4/lib/QtCore.framework/Versions/4/QtCore @rpath/QtCore /usr/local/CereLink/QtXml
Now you can copy the files in “/usr/local/CereLink” as a bundle.
No special note, Linux is perfect for development. Just remember to install the development versions of Python and Qt if binaries and development are separated.
- We need Qt 4.6 and above because of QSharedMemory and QtConcurrentRun, older distros may not ship this version, (one may try some backport software channel, or just build newer libraries). If CCF capabilities are stripped we cna use Qt4.4 as well.
- If you use prebuilt binaries built for specific version of a distro, or if required libraries are not in your ususal distro location you can use
export LD_LIBRARY_PATH=/path/to/.so/files/before running the SDK.
To test this method do this: LD_LIBRARY_PATH=/path/to/new/qt/so/files ldd /path/to/libcbsdk.so and it should show that Qt libraries are resolved with the path you mentioned instead of system path in /usr/lib.
Remember that some applications such as MATLAB may change LD_LIBRARY_PATH, and also may be shipped with their own versions of Qt shared libraries, so you should check their version to see if that is right.
- Prior to 6.04 port numbers 1001 and 1002 are used. Accessing or binding to low port numbers requires root permission (since v6.04 they are changed to 51001 and 51002).
Either run the binaries as root, or do
setcap 'cap_net_bind_service=+ep' /path/to/program
In which you should give the capability to MATLAB, or Python interpreter, or your application using the sdk (neither root nor capability is not a good idea because of security reasons).
You can also use iptables to route the ports. Make sure sdk uses 51001 and 51002 bys specifying inst-port and client-port and route ports:
iptables -t nat -A PREROUTING -p udp --dport 51001 -j REDIRECT --to-port 1001
iptables -t nat -A PREROUTING -p udp --dport 51002 -j REDIRECT --to-port 1002
To delete above routing: iptables -t nat --line-numbers -n -L Then iptables -t nat -D PREROUTING $num
The Multi-Byte Character Set (MBCS) version of MFC is marked as deprecated starting with VS 2013 and therefore no longer included. When trying to build the SDKSample against the now default Unicode version, there are a bunch of LPCTSTR related casting errors.
Installing the MFC MBCS DLL Add-on and building against the MBSC version works fine, so this is probably a good workaround for now.