Como muestra el título, este problema ocurrió cuando usé ffi para llamar a la biblioteca de enlaces dinámicos en el proyecto electron. Funcionó bien en esta máquina, pero cuando lo empaqueté, lo construí y lo puse en otra máquina, algo salió mal.
Este problema también me confundió mucho. Si el problema es causado por la ruta, simplemente especifique la ruta correcta, pero la ruta también es correcta y se informará un error. Ésa debería ser una cuestión medioambiental.
¿Por qué debería usar ffi para llamar a la biblioteca de enlaces dinámicos? Mis necesidades son las siguientes. Necesito programar para conectar el equipo de instrumentos Nord Schwarz cmw500 a través de tcpip. De hecho, es programación Visa. Comencé a implementar simplemente esta función a través del lenguaje C. Pensé que todo estaba bien y luego escribí una dinámica. biblioteca de enlaces., que lo llame el proyecto electron, porque el nodo rara vez opera visa. El único enlace que se puede encontrar en Internet es este en github: https://github.com/petertorelli/ni-visa . No miré con atención en ese momento y no estaba seguro de si este método era confiable.
Código de biblioteca de enlaces dinámicos escrito por mí mismo:
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);
}Más tarde pude usar la biblioteca dinámica que compilé yo mismo para operar Visa y no hubo ningún problema con el entorno de desarrollo local. Luego me alegré mucho de pensar que el problema estaba resuelto y lo empaqueté. Más tarde, cuando lo probé , había un problema y siempre informaba como se muestra en el título.
Este código mío se compiló principalmente con Visual Studio 2017. En ese momento, no hubo ningún problema con la prueba del lenguaje C y la prueba del nodo.
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)/Lo anterior es mi código y la parte de descripción del problema//
Pensé que era porque mi código mismo llamaba a la biblioteca Visa. Si no necesitara llamar a otras bibliotecas, ¿una biblioteca de enlace dinámico simple no tendría este problema? De hecho, también uso Visual Studio 2017 para compilar y no hay problema con la inspección local, pero sí cuando se coloca en otras máquinas. Parece que el problema está en el medio ambiente.
Más tarde, vi accidentalmente un foro que decía que Windows-build-tools debía instalarse a través de npm. Intenté instalarlo en otra máquina y descubrí que el error ya no ocurría.
Pero de esta manera, siempre que sea una llamada de biblioteca de enlace dinámico, debe instalarse en otra máquina. Parece una tontería. De hecho, electron + ffi ahora está tan maduro que es imposible escribir programas que necesiten instalarse en la máquina en ejecución. Instale Windows-build-tools.
De hecho, la instalación de Windows-build-tools esencialmente requiere la instalación de un msbuild, así como la instalación de python, windows10 sdk, cmake y otras herramientas.Windows-build-tools requiere descargar vs_BuildTools.exe e iniciar la instalación. De hecho, es la instalación mediante Visual Studio Install. Si ha instalado Visual Studio 2017, está muy familiarizado con esto. En mi entorno, es necesario instalar cmake, y cmake se basa en Windows10 SDK, y esto es tan grande como 2.4G, por lo que si necesita ejecutar el programa electron+ffi sin errores en otros sistemas, también necesita instalar un entorno de aproximadamente 3G, algo poco realista.
Más tarde, miré nuevamente el proyecto de operar visa en el entorno de nodo mencionado anteriormente. De hecho, se basó en la biblioteca dependiente visa64.dll generada en el sistema después de instalar nivisa1850full. También opera la biblioteca de enlaces dinámicos. Este proyecto también tiene 6 1 estrella, creo que puedo darle una oportunidad, con la actitud de darle una oportunidad, finalmente descubrí que funciona.
Además, otras máquinas pueden funcionar sin instalar el entorno Windows-build-tools, pero otras máquinas necesitan instalar el entorno dependiente de nivisa, que es necesario para operar los instrumentos de Nord Schwarz.
Sorprendentemente, también escribí una biblioteca dinámica, la compilé en la línea de comandos sin usar la herramienta IDE de Visual Studio 2017 y finalmente la empaqueté para que pueda usarse en otras máquinas sin ningún problema.
Llegué a la conclusión de que el problema con mi llamada a la biblioteca de enlaces dinámicos se debe a la codificación y compilación utilizando las herramientas ide de Visual Studio 2017. En cuanto a por qué, aún no lo he descubierto. Utilicé la línea de comandos para compilar y, de hecho, utilicé las herramientas de compilación para desarrolladores generadas por la instalación de Visual Studio 2017, y no hubo ningún problema.