By farzane lk
I have received a LabVIEW dll and the corresponding header files so that I can send a trigger to a skin stimulation device.
when I use the loadlibrary command in my Matlab script, I receive these two errors: "We don't know the Compiler" and "We don't know the ProcessorType architecture"
Which means while reading the "platdefines.h", the Compiler and the ProcessorType does not match the ones listed in ifs.
I have set c++ compiler to visual studio 2015 in Matlab. (also tried MinGW). the system I`m using is Windows 10 (tried on 7, too), 64bit.
I read somewhere that manually defining the ProcessorType and the compiler might solve the issue. But the problem is I Don`t know what they are. (when these two conditions below are not accepted.)
#elif defined(_MSC_VER) || defined(_NI_VC_)
#define Compiler kVisualC
#define ProcessorType kX64
How should I find out the ProcessorType and the compiler I have?
I`d be EXTREMELY THANKFUL for any solutions you can think of.
P.S.1 I attached all the headers and the Matlab error.jpg
P.S.2 The code seems to work fine on manufacturers system with Matlab 2011. so it may be Matlab-related, but I don`t get how since the error is from platdefines header file.
I have never gotten the performance that I desire out of the 2D picture control. I always think that it should be cheaper than using controls since they don't have to handle user inputs and click events etc. But they always seem to be slower.
I was wondering if any of the wizards out there had any 2d picture control performance tips that could help me out?
Some things that come to mind as far as questions go:
Is the conversion to from pixmap to/from picture costly?
Why does the picture control behave poorly when in a Shift register?
What do the Erase first settings cost performance wise?
Anything you can think of that are bad ideas with picture controls?
Anything you can think of that is generally a good idea with picture controls?
I am using the variantconfig.llb for saving/loading configuration files.
Unfortunately these configuration-files got very huge: 10.000 lines or even more, having hundreds of sections.
Loading these files takes 15-30 seconds. The workflow:
- getting all sections with "Get Section Names.vi" (is very fast)
- a for-loop is using "Read Section Cluster_ogtk.vi" on each section Name (using Profiler, I can see that this uses the most amount of time). Depending on the section name, I am selecting the cluster type.
Do you have any hints, how I can speed up the process?
I'm using a Labview Shared Library (DLL) to comunicate between a C# program (made by another company) and a labview Executeable (which means different processes) on the same PC. Currently i'm using network published shared variables, to communicate between the Labview DLL and the LABVIEW program (both made by me) which works well, except for the performance.
Each time the DLL is called it needs to connect to the shared variable, which takes between 50 and 300 ms. When it is connected, the data transfer is instant. I have tried to use the PSP "Open Variable Connection In Background", which is a bit faster, because it doesn't wait to verify the connection. But it still adds some overhead.
I have also tried to use notifiers from this example: https://lavag.org/topic/10408-communication-between-projects/ . Opening connection and sending the notifier takes 50 - 100 ms.
I guess both the notifier and the shared variables are "slow" because they use the network communication, even if it is the same pc both programs are running on (localhost).
Does any of you know of a faster method of communicating between a program that is running continuesly (connection open constantly) and one only exectuted when new data is ready (connection "re"-opened on every instance)?
Thanks in advance.
Before making the switch from LV2011 to LV2014, I ran the exact same test with the 2 versions (2011 and 2014) of my application. I recorded the CPU usage and discovered a huge deterioration of in LV2014.
Is anybody aware of any change between LV2011 and LV2014 that could impact the performances like this?
I should mention that the unit on the Y-scale is %CPU and the X-scale is MM:SS