Using LOADLIBRARY to load 'visa32.dll' and 'visa.h' in 64-bit Matlab R2017b - matlab

With Matlab R2015b on 32-bit Windows 7, LOADLIBRARY was working fine:
library = 'C:\Windows\System32\visa32.dll';
headerFile = 'C:\Program Files\IVI Foundation\VISA\WinNT\include\visa_Matlab.h';
loadlibrary(library, headerFile, 'alias','visa32');
and I can use functions in 'visa32.dll', such as,
defaultRm = 0;
[err, defaultRm] = calllib('visa32', 'viOpenDefaultRM', defaultRm);
vi = 0;
InstrAddr = 'GPIB0::29::INSTR';
pInstrAddr = libpointer('int8Ptr', [int8( InstrAddr ) 0] );
[err, tempVar, vi] = calllib('visa32', 'viOpen', defaultRm, pInstrAddr, 0, 0, vi);
to open instrument's communication port...
But after I have upgraded to 64-bit Windows 7 and Matlab R2017b, LOADLIBRARY won't work any more, even I have use 62-bit versions of 'visa32.dll' and 'visa.h'. There are two problems:
(1) Firstly, Matlab complaints about not have the right compiler installed and can't even run LOADLIBRAY. Follow their online instruction to install the MinGW-w64 Compiler addon. This problem seems to have revolved.
(2) LOADLIBRAY seems to be able to run, but then it has the following error:
Failed to parse type '( fastcall )) viOpenDefaultRM ( ViPSession vi' original input '( fastcall )) viOpenDefaultRM ( ViPSession vi '
Found on line 217 of input from line 93 of file C:\Program Files (x86)\IVI Foundation\VISA\WinNT\Include\visa.h
Error parsing argument for function attribute function may be invalid.
...
I wonder if somebody could help please. Many thanks in advance!

The advantages of using VISA library in MATLAB for instrument control are: direct (i.e. faster) access to ports, be able to use GTL (go-to-local) and handles communication error better, etc. Use LOADLIBRARY to load the VISA library and CALLLIB to access the functions in the loaded library, e.g.
loadlibrary('visa32.dll','visa.h','alias','visa32');
[err, defaultRm] = calllib('visa32', 'viOpenDefaultRM', defaultRm);
However, limitations in LOADLIBRARY have caused a lot of trouble, and it works differently for different Windows architecture. Here is the solution that has been tested on 32- and 64-bit Windows:
  1. C++ compiler in MATLAB:
    a. This only affects 64-bit MATLAB;
    b. A MATLAB add-on called ‘MinGW-w64 Compiler’ must be installed:
      i. this is relatively easy for R2017b, just use MATLAB’s Add-Ons Manager;
      ii. for MATLAB version prior to R2017b, it is very difficult:
       Download and install 'MinGW-w64' from:
       tdm-gcc.tdragon.net/download
       sourceforge.net/projects/tdm-gcc/postdownload?source=dlp
       sourceforge.net/projects/mingw/files/
       Then configure MATLAB as described in:
       de.mathworks.com/help/matlab/matlab_external/compiling-c-mex-files-with-mingw.html
       de.mathworks.com/help/matlab/matlab_external/install-mingw-support-package.html
       de.mathworks.com/matlabcentral/answers/313298-i-already-have-mingw-on-my-computer-how-do-i-configure-it-to-work-with-matlab
  2. VISA library file:
    a. Different DLL file for different Windows architecture;
    b. The library file is available after the installation of NI-488.2 driver (the latest version to date is 'NI4882_1760f0.exe';
    c. For 32-bit Windows and 32-bit MATLAB:
      i. Library file: ‘visa32.dll’
      ii. Location: ‘C:\Windows\System32\’
    d. For 64-bit Windows and 64-bit MATLAB:
      i. Library file: ‘visa64.dll’
      ii. Location: ‘C:\Windows\System32\’
      iii. Notes:
       1. According to NI’s website, the 64-bit VISA DLL is ‘visa32.dll’ that resides in 'C:\Windows\SysWOW64. This is not right;
       2. Alternatively, a 64-bit version of ‘visa32.dll’, which is smaller than ‘visa64.dll’ installed by NI-488.2 driver, can be downloaded from: https://www.azdll.net/files/visa32-dll.html.
  3. Header files:
    a. Two headers files are needed to load the VISA library: ‘visa.h’ and ‘visatype.h’;
    b. Both are available after the installation of NI-488.2 driver;
    c. For 32-bit Windows, both files are in:
‘C:\Program Files\IVI Foundation\VISA\Win64\include’
    d. For 64-bit Windows, both files are in:
‘C:\Program Files (x86)\IVI Foundation\VISA\WinNT\include’
    e. ‘visatype.h’ can be used as it is;
    f. ‘visa.h’ must be modified for MATLAB’s LOADLIBRARY. Changes made on ‘visa.h’ are:
      i. Add the following at the beginning of the header file:
#ifdef _WIN64
#define __fastcall
#endif
      ii. Mask out 'viInstallHandler' and 'viUninstallHandler', as they are not commonly used;
      iii. Remove ', ...' from the following functions as it’s not supported by LOADLIBRARY (https://de.mathworks.com/matlabcentral/answers/103180-why-do-i-get-warnings-when-loading-a-dll-with-loadlibrary-in-matlab-7-13-r2011b):
        viPrintf, viSPrintf, viScanf, viSScanf, viQueryf
      iv. Replace 'ViVAList' with 'ViConstBuf' in the following functions:
        viVPrintf, viVSPrintf, viVScanf, viVSScanf, viVQueryf
      v. Replace the 'viVxiServantResponse' function with the following:
#ifndef _WIN64
ViStatus _VI_FUNC viVxiServantResponse(ViSession vi, ViInt16 mode, ViUInt32 resp);
#endif
      g. The modified ‘visa.h’, renamed as ‘visa_Matlab.h’, can be downloaded from visa_Matlab.h.
Example:
% ‘visa32.dl’ or ‘visa64.dll’, ‘visa_Matlab.h’ and ‘visatype.h’ must be
% available in the local directory
archstr = computer('arch');
if ~isempty(strfind(archstr, 'PCWIN64')) || ~isempty(strfind(archstr, 'win64'))
dllName = 'visa64';
else
dllName = 'visa32';
end
headerFileName = 'visa_Matlab.h';
loadlibrary ([dllName '.dll'], 'visa_Matlab.h','alias',dllName);
visaFunctions = libfunctions(dllName,'-full');

Related

What is the calling convention difference between LAPACKE_zgetrf() and zgetrf_() in OpenBLAS?

I'm trying to support zgetrf() in both Ubuntu 18.04 and CentOS 7 by using dlopen() against the .so and opening the function in each version, but the calling convention is different. In CentOS it works using LAPACKE_zgetrf() but in Ubuntu 18.04 they do not export as LAPACKE_zgetrf, the only option is zgetrf_:
# objdump -T /usr/lib/i386-linux-gnu/libopenblas.so.0 |grep zgetrf
[...]
000c3a60 g DF .text 00000191 Base zgetrf_
I can make an LAPACKE_zgetrf() call as follows, this works:
LAPACKE_zgetrf(order, m, n, a, ndim, (int32_t*)ip);
How do I convert it to call zgetrf_(...) ?
The LAPACKE_ functions will call the linked openblas.so.0 library, so no need to link to openblas.so.0 directly.
For ATLAS, you can call the clapack_ functions exported by liblapack_atlas.so.3 which are nearly the same format (same order, same type) except that the transform argument is different. For example, in zgetrs() in ATLAS might take the standard BLAS CblasTrans enum for the transform argument. However, in OpenBLAS (and MKL) this argument should be converted from ATLAS to OpenBLAS as follows:
openblas_trans = ((trans) == CblasConjTrans ? 'C' : ((trans) == CblasTrans ? 'T' : 'N'))

OpenCobol & PostgreSQL on Windows with Visual Studio

I'm currently facing a problem with this team of 4.
Using binaries I downloaded on kiska's site. I'm able to compile cobol to C and run it with cobcrun or compile it to an executable. However I can 't get opencobol to find the postgres commands.
Here is the strat of my cobol script :
identification division.
program-id. pgcob.
data division.
working-storage section.
01 pgconn usage pointer.
01 pgres usage pointer.
01 resptr usage pointer.
01 resstr pic x(80) based.
01 result usage binary-long.
01 answer pic x(80).
procedure division.
display "Before connect:" pgconn end-display
call "PQconnectdb" using
by reference "dbname = postgres" & x"00"
by reference "host = 10.37.180.146" & "00"
returning pgconn
end-call
...
the call PQconnectdb fail with module ont found : PQconnectdb
I noticed that if i rename the libpq.dll the error message change to can't find entry point. So at least I'm sure it can get my dll.
After digging into the code of the call method of the libcob library. I found it it was possible to pre load some dll using an environment variable COB_PRE_LOAD but sitll no results.
Here is what look the script to compile the cobol :
call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64\vcvarsamd64.bat"
set COB_CONFIG_DIR=C:\OpenCobol\config
set COB_COPY_DIR=C:\OpenCobol\Copy
set COB_LIBS=%COB_LIBS% c:\OpenCobol\libpq.lib
set COB_LIBRARY_PATH=C:\OpenCobol\bin
set COB_PRE_LOAD=C:\OpenCobol\libpq.dll
#echo on
cobc -info
cobc -free -o pgcob -L:"C:\OpenCobol" -llibpq.lib test_cobol\postgres.cob
call cobcrun pgcob
I don't see anything missing, I'm using the 64-bit binaries from kiska's site and use the 64-bit cl.exe from Visual Studio, Postgres is a 64 bit version too (checked with dependencyChecker).
I even tryed to compile the generated C from Visual Studio, same result, but I may miss something, I'm pretty rotten in C and never really had to manage DLL or use Visual Studio.
What am I missing ?
COB_PRE_LOAD doesn't take any path or extension, see the short documentation for the available runtime configurations. I guess
set COB_LIBRARY_PATH=C:\OpenCobol\bin;C:\OpenCobol
set COB_PRE_LOAD=libpq
Will work. You can omit the C:\OpenCobol\bin if you did not placed any additional executables there.
If it doesn't work (even if it does) I'd try to get the C functions resolved at compile time. Either use
CALL STATIC "PQconnectdb" using ...
or an appropriate CALL-CONVENTION or leave the program as-is and use
cobc -free -o pgcob -L"C:\OpenCobol" -llibpq -K PQconnectdb test_cobol\postgres.cob
From cobc --help:
-K generate CALL to <entry> as static
In general: the binaries from kiska.net are quite outdated. I highly suggest getting newer ones from the official download site or ideally build them on your own from source, see the documentation for building GnuCOBOL with VisualStudio.

How Can I use my GPU on Ipython Notebook?

OS : Ubuntu 14.04LTS
Language : Python Anaconda 2.7 (keras, theano)
GPU : GTX980Ti
CUDA : CUDA 7.5
I wanna run keras python code on IPython Notebook by using my GPU(GTX980Ti)
But I can't find it.
I want to test below code. When I run it on to Ubuntu terminal,
I command as below (It uses GPU well. It doesn't have any problem)
First I set the path like below
export PATH=/usr/local/cuda/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH
Second I run the code as below
THEANO_FLAGS='floatX=float32,device=gpu0,nvcc.fastmath=True' python myscript.py
And it runs well.
But when i run the code on pycharm(python IDE) or
When I run it on Ipython Notebook, It doesn't use gpu.
It only uses CPU
myscript.py code is as below.
from theano import function, config, shared, sandbox
import theano.tensor as T
import numpy
import time
vlen = 10 * 30 * 768 # 10 x #cores x # threads per core
iters = 1000
rng = numpy.random.RandomState(22)
x = shared(numpy.asarray(rng.rand(vlen), config.floatX))
f = function([], T.exp(x))
print(f.maker.fgraph.toposort())
t0 = time.time()
for i in xrange(iters):
r = f()
t1 = time.time()
print("Looping %d times took %f seconds" % (iters, t1 - t0))
print("Result is %s" % (r,))
if numpy.any([isinstance(x.op, T.Elemwise) for x in f.maker.fgraph.toposort()]):
print('Used the cpu')
else:
print('Used the gpu')
To solve it, I force the code use gpu as below
(Insert two lines more on myscript.py)
import theano.sandbox.cuda
theano.sandbox.cuda.use("gpu0")
Then It generate the error like below
ERROR (theano.sandbox.cuda): nvcc compiler not found on $PATH. Check your nvcc installation and try again.
how to do it??? I spent two days..
And I surely did the way of using '.theanorc' file at home directory.
I'm using theano on an ipython notebook making use of my system's GPU. This configuration seems to work fine on my system.(Macbook Pro with GTX 750M)
My ~/.theanorc file :
[global]
cnmem = True
floatX = float32
device = gpu0
Various environment variables (I use a virtual environment(macvnev):
echo $LD_LIBRARY_PATH
/opt/local/lib:
echo $PATH
/Developer/NVIDIA/CUDA-7.5/bin:/opt/local/bin:/opt/local/sbin:/Developer/NVIDIA/CUDA-7.0/bin:/Users/Ramana/projects/macvnev/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
echo $DYLD_LIBRARY_PATH
/Developer/NVIDIA/CUDA-7.5/lib:/Developer/NVIDIA/CUDA-7.0/lib:
How I run ipython notebook (For me, the device is gpu0) :
$THEANO_FLAGS=mode=FAST_RUN,device=gpu0,floatX=float32 ipython notebook
Output of $nvcc -V :
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2015 NVIDIA Corporation
Built on Thu_Sep_24_00:26:39_CDT_2015
Cuda compilation tools, release 7.5, V7.5.19
From your post, probably you've set the $PATH variable wrong.

Compile the C-file in MATLAB

Description
I got a Mathematica Symbolic Toolbox for MATLAB--Version 2.0 here
Then I using the documentation it cotained to compile in MATLAB enviroment
Installation steps:
1)Go to your Mathematica directory and locate the file mathlink.h in
E:\math\Mathematica\5.\AddOns\MathLink\DeveloperKit\Windows\CompilerAdditions\mldev32\include'
and also the file ml32i1m.lib in
E:\math\Mathematica\5.\AddOns\MathLink\DeveloperKit\Windows\CompilerAdditions\mldev32\lib. Copy both files to a predetermined directory (we will refer to this directory as C:\xxx).
2) Copy the content of compressed file math.tar into C:\xxx.
3) Open Matlab command window and execute mex –setup. Choose “Microsoft Visual C/C++ version 6.0 in C:\Program Files\Microsoft Visual Studio”. This tells Matlab that it needs to use a C compiler (as opposed to Fortran compiler). You’ll need Microsoft Visual C/C++ installed. Do not choose the “Lcc C version 2.4 in C:\MATLAB6P1\sys\lcc” option.
4) Open Matlab command window and run mathrun.m. This program will compile the C-file math.c.
The file I got shown as belew:
Then I do step by step
(1) Find the mathlink.h and ml32i1m.lib in the following path
D:\WolframResearch\Mathematica\8.0\SystemFiles\Links\MathLink\DeveloperKit\Windows\CompilerAdditions\mldev32\include
D:\Wolfram Research\Mathematica\8.0\SystemFiles\Links\MathLink\DeveloperKit\Windows\CompilerAdditions\mldev32\lib
(2)Copy the content of compressed file math.zip into C:\XXX
(3) Compile in MATLAB
mex -setup
(4)last setp
addpath C:\XXX
run mathrun.m
I don't know why?
Update
The matlab code in mathrun.m
addpath C:\XXX;
% adds the directory C:\XXX to the list of directories which Matlab "sees" (referred to as paths)
mlpath='C:\XXX' % The directory where mathlink.h is
mllib='C:\XXX\ml32i1m.lib' % The library ml32i1m.lib
% make command
command=sprintf('mex -D__STDC __ -I % s % s % s', mlpath, 'math.c', mllib);
% compile
eval(command)
Seems like the path is not correctly passed to mex, so it cannot find math.c. Comment the original line:
%command=sprintf('mex -D__STDC __ -I % s % s % s', mlpath, 'math.c', mllib);
and add this one instead:
command=sprintf('mex -D__STDC __ -I%s %s %s', mlpath, 'math.c', mllib);
because the mex documentation specifies that there should be no space between the -I switch and the input path. To be really on the safe side, you can even write:
command=sprintf('mex -D__STDC __ -I%s %s %s', mlpath, fullfile(mlpath,'math.c'), mllib);

Matlab Distributed Server parfor can't find mex opencv files

everyone!
I'm trying to parallelize an algorithm that uses mex files from mexopencv (KNearest.m, KNearest_.mexw32).
The program is based vlfeat (vlsift.mex32) + mexopencv (KNearest.m and KNearest_.mexw32).I classify descriptors obtained from images.
All the code is located on the fileshare
\\ LAB-07 \ untitled \ DISTRIB \ (this is the program code)
\\ LAB-07 \ untitled \ + cv (mexopencv)
When I run the program with matlabpool close everything works well.
Then I make matlabpool open (2 computers on 2 cores each. ultimately 4 worker, but now I use for testing only 2 workers on the computer and run the program which)
PathDependencises from fileshare -> \LAB-07\untitled\DISTRIB\ , \LAB-07\untitled+cv
Before parfor loop I train classifier on the local machine
classifiers = cv.KNearest
classifiers.train(Descriptors',Labels','MaxK',1)
Then run parfor
descr=vlsift(img);
PredictClasses = classifiers.predict(descr');
Error
Error in ==> KNearest>KNearest.find_nearest at 173
Invalid MEX-file '\\LAB-07\untitled\+cv\private\KNearest_.mexw32':
The specified module could not be found.
That is KNearest.m finds, but no KNearest_.mexw32. Because KNearest_.mexw32 located in private folder, I changed the code KNearest.m (everywhere where it appeal KNearest_ () changed to cv.KNearest_ (). Example: this.id = сv.KNearest_ ()) and placed in a folder with KNearest_.mexw32 KNearest.m. As a result, get the same error
Immediately after matlabpool open file search on workers
pctRunOnAll which ('KNearest.m')
'KNearest.m' not found.
'KNearest.m' not found.
'KNearest.m' not found.
pctRunOnAll which ('KNearest_.mexw32')
'KNearest_.mexw32' not found.
'KNearest_.mexw32' not found.
'KNearest_.mexw32' not found.
after cd \LAB-07\untitled+cv
pctRunOnAll which ('KNearest.m')
\\LAB-07\untitled\+cv\KNearest.m
\\LAB-07\untitled\+cv\KNearest.m % cv.KNearest constructor
\\LAB-07\untitled\+cv\KNearest.m
>> pctRunOnAll which ('KNearest_.mexw32')
\\LAB-07\untitled\+cv\KNearest_.mexw32
\\LAB-07\untitled\+cv\KNearest_.mexw32
\\LAB-07\untitled\+cv\KNearest_.mexw32
I ran and FileDependecies, but the same result.
I do not know this is related or not, I display during the execution of the program classifiers
after training and before parfor
classifiers =
cv.KNearest handle
Package: cv
Properties:
id: 5
MaxK: 1
VarCount: 128
SampleCount: 9162
IsRegression: 0
Methods, Events, Superclasses
Within parfor before classifiers.predict
classifiers =
cv.KNearest handle
Package: cv
Properties:
id: 5
I tested the file cvtColor.mexw32. I left in a folder only 2 files cvtColor.mexw32 and vl_sift
parfor i=1:2
im1=imread('Copy_of_start40.png');
im_vl = im2single(rgb2gray(im1));
desc=vl_sift(im_vl);
im1 = cvtColor(im1,'RGB2GRAY');
end
The same error, and vl_sift work, cvtColor no...
If the worker machines can see the code in your shared filesystem, you should not need FileDependencies or PathDependencies at all. It looks like you're using Windows. It seems to me that the most likely problem is file permissions. MDCS workers running under a jobmanager on Windows by default run not using your own account (they run using the "LocalSystem" account I think), and so may well simply not have access to files on a shared filesystem. You could try making sure your code is world-readable.
Otherwise, you can add the files to the pool by using something like
matlabpool('addfiledependencies', {'\\LAB-07\untitled\+cv'})
Note that MATLAB interprets directories with a + in as defining "packages", not sure if this is intentional in your case.
EDIT
Ah, re-reading your original post, and your comments below - I suspect the problem is that the workers cannot see the libraries on which your MEX file depends. (That's what the "Invalid MEX-file" message is indicating). You could use http://www.dependencywalker.com/ to work out what are the dependencies of your MEX file, and make sure they're available on the workers (I think they need to be on %PATH%, or in the current directory).
Edric thanks. There was a problem in the PATH for parfor. With http://www.dependencywalker.com/ looked missing files and put them in a folder +cv. Only this method works in parfor.
But predict in parfor gives an error
PredictClasses = classifiers.predict(descr');
??? Error using ==> parallel_function at 598
Error in ==> KNearest>KNearest.find_nearest at 173
Unexpected Standard exception from MEX file.
What() is:..\..\..\src\opencv\modules\ml\src\knearest.cpp:365: error: (-2) The search
tree must be constructed first using train method
I solved this problem by calling each time within parfor train
classifiers = cv.KNearest
classifiers.train(Descriptors',Labels','MaxK',1)
But it's an ugly solution :)