As the title shows, this problem occurred when I used ffi to call the dynamic link library in the electron project. It ran fine on this machine, but when I packaged it and built it and put it on another machine, something went wrong.
This problem also made me very confused. If the problem is caused by the path, then just specify the correct path, but the path is also correct, and an error is reported. That should be an environmental issue.
Why should I use ffi to call the dynamic link library? My needs are as follows. I need to program to connect Nord Schwarz instrument equipment cmw500 through tcpip. In fact, it is visa programming. I started to simply implement this function through C language. I thought everything was fine, and then wrote a dynamic link library. , let the electron project call it, because node rarely operates visa. The only link that can be found on the Internet is this one on github: https://github.com/petertorelli/ni-visa . I didn't look carefully at the time, and I wasn't sure if this method was reliable.
Dynamic link library code written by myself:
pch.h
#ifdef PCH_H
#else
#define PCH_H extern "C" _declspec(dllimport)
// add headers that you want to pre-compile here
#include "framework.h"
#endif //PCH_H
PCH_H void QueryMeasureResult(char* source,char* cmd,char* result);pch.cpp
// pch.cpp: source file corresponding to the pre-compiled header
#if defined(_MSC_VER) && !defined(_CRT_SECURE_NO_DEPRECATE)
#define _CRT_SECURE_NO_DEPRECATE
#endif
#define PCH_H extern "C" _declspec(dllexport)
#include "pch.h"
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "visa.h"
static ViSession defaultRM;
static ViSession instr;
static ViUInt32 retCount;
static ViUInt32 writeCount;
static ViStatus status;
static unsigned char buffer[100];
static char stringinput[512];
// When you are using pre-compiled headers, this source file is necessary for compilation to succeed.
void QueryMeasureResult(char* source,char* cmd,char* result) {
status = viOpenDefaultRM(&defaultRM);
if (status < VI_SUCCESS) {
viClose(defaultRM);
strcpy(result, "error");
return;
}
status = viOpen(defaultRM, source,VI_NULL, VI_NULL, &instr);
if (status < VI_SUCCESS) {
viClose(defaultRM);
strcpy(result, "error");
return;
}
status = viSetAttribute(instr, VI_ATTR_TMO_VALUE, 5000);
status = viSetAttribute(instr, VI_ATTR_ASRL_BAUD, 4800);
status = viSetAttribute(instr, VI_ATTR_ASRL_DATA_BITS, 8);
status = viSetAttribute(instr, VI_ATTR_ASRL_PARITY, VI_ASRL_PAR_NONE);
status = viSetAttribute(instr, VI_ATTR_ASRL_STOP_BITS, VI_ASRL_STOP_ONE);
status = viSetAttribute(instr, VI_ATTR_TERMCHAR_EN, VI_TRUE);
status = viSetAttribute(instr, VI_ATTR_TERMCHAR, 0xA);
strcpy(stringinput, cmd);
status = viWrite(instr, (ViBuf)stringinput, (ViUInt32)strlen(stringinput), &writeCount);
if (status < VI_SUCCESS) {
viClose(defaultRM);
strcpy(result, "error");
return;
}
status = viRead(instr, buffer, 100, &retCount);
if (status < VI_SUCCESS) {
strcpy(result, "error");
}
else {
//buffer = "0,2.415445E+001"
strcpy(result, (const char*)buffer);
}
viClose(defaultRM);
}Later, I could use the dynamic library compiled by myself to operate visa, and there was no problem with the local development environment. Then I was very happy to think that the problem was solved, and I packaged it. Later, when I tested it, there was a problem, and it always reported as shown in the title. mistake.
This code of mine was mainly compiled using visual studio 2017. At that time, there was no problem with testing in C language and node.
visatest.js
var ffi = require("ffi")
var ref = require("ref")
var path = require("path")
var dllpath = path.resolve(__dirname,"visademo.dll")
console.log(dllpath)
const api = new ffi.Library(dllpath,{
QueryMeasureResult:["void",["string","string","string"]]
})
var source="TCPIP0::192.168.253.13::inst0::INSTR";
var cmd = "FETCh:GPRF:MEAS:POWER:PEAK:MAXimum?\n";
var result=Buffer.alloc(100);
result.type = ref.types.char;
api.QueryMeasureResult(source,cmd,result);
var str = result.readCString()
var arr = str.split(",");
var maximum = arr[1]
console.log(parseFloat(maximum),maximum)/The above is my code and problem description part//
I thought it was because my code itself called the visa library. If it didn't need to call other libraries, would a simple dynamic link library not have this problem? In fact, I also used visual studio 2017 to compile, and there was no problem when checking on this machine, but problems occurred when I put it on another machine. It seems the problem lies in the environment.
Later, I accidentally saw a forum saying that windows-build-tools needs to be installed through npm. I tried to install it on another machine and found that the error no longer occurred.
But in this way, as long as it is a dynamic link library call, it needs to be installed on another machine. It seems too nonsense. In fact, electron+ffi is now so mature that it is impossible to write programs that need to be installed on the running machine. Install a windows-build-tools.
In fact, the installation of windows-build-tools essentially requires the installation of an msbuild, as well as the installation of python, windows10 sdk, cmake and other tools. Windows-build-tools requires downloading vs_BuildTools.exe and starting the installation. In fact, it is the installation using visual studio install. , if you have installed visual studio 2017, you are very familiar with this. In my environment, cmake needs to be installed, and cmake relies on windows10 sdk, and this thing is as big as 2.4G, so if you need to run the electron+ffi program without error on other systems, you also need to install an environment of about 3G , somewhat unrealistic.
Later, I looked again at the project of operating visa in the node environment mentioned earlier . In fact, it relied on the visa64.dll dependent library generated in the system after nivisa1850full was installed. It also operates the dynamic link library. This project also has 6 2 stars, I thought I could give it a try, and I finally found out that it worked.
Moreover, other machines can run without installing the windows-build-tools environment, but other machines need to install the nivisa dependent environment, which is required to operate Nord Schwarz instruments.
Surprisingly, I also wrote a dynamic library myself, compiled it on the command line without using the visual studio 2017 IDE tool, and finally packaged it, so it can be used on other machines without any problem.
I concluded that the problem with my dynamic link library call is caused by coding and compiling using visual studio 2017 ide tools. As for why, I haven't figured it out yet. I used the command line to compile, and actually used the developer compilation tools generated by the visual studio 2017 installation, and there was no problem.