I'm trying to use LabView to operate a ThorLab CS235CU camera. However, so far I haven't had any success using LabView to operate it, despite searching the provided thorlabs and national instruments documentation and google for an answer all week. I started by trying ThorLab's VIs that came with their software, but anytime I run a script it returns the following error:
Error 1386 has occurred at Invoke Node. In the provided "simple image aquisition" VI, this error occurs at 3 locations (steps 2, 3, and 4) before deleting the rest of the script, if run with execution highlighted. National Instruments has 3 suggested fixes on their website: unblocking DLLs manually, which seems unrealistic given I don't know what is causing this error; running LabView as an administrator, which I had been doing from the beginning and didn't help the issue; and creating a configuration file, which I tried but did not work. I put it in C:\ProgramFiles\National Instruments\LabView 2020 as well as C:\ProgramFiles(x86)\National Instruments\LabView 2020, but the error still occurs. I'm very new to using LabView and couldn't begin to explain why this error is occurring, so anyone that can or knows how to help, please do.
It seems that you didn't set up the ThorLabs driver properly one way or another. Often it is the manufacturer's installer that must be run first (with LabVIEW turned off) and eventually you'll find the according driver/dll wrapper VIs (also referred to as LabVIEW-Driver) in some arcane subdirectory like <Program Files>\ThorLabs\<Product>\Drivers\Labview\...
It might make sense to copy that directory to your myProject\drivers\ Folder and the simple image acquisition.vi to something like myProject\examples and work your way from there. Also make sure you're using LabVIEW 32bit since few third-party drivers come in 64bit.
Related
I recently built a large-ish open source program in Visual Studio 2013. Initially the build failed due to a couple errors (a C1900 and a LNK2019). These errors were quite puzzling since I was following clear, simple instructions for building the program. The main developer couldn't think of any good reasons why they would occur.
I turned off my laptop overnight and the next morning I reattempted the build with the intention of reproducing the errors. But to my great surprise, no errors. I did not change any of the source or any compiler settings, etc.
Later that day I decided to do another build, and I got the same errors as before. I shut down my laptop for a minute or so, turned it back on, tried building again and it worked.
Clearly this is really strange. I have reason to suspect that there is some faulty hardware in my laptop. Could that cause these mysterious disappearing errors?
Try this on another machine and see if you get the same results. If you do, you'll know it's not a hardware issue.
It's more probable that you don't have complete build steps provided by the other developer. If he only built/tested it on his computer, then he may have added/installed (and not documented) some other tools/scripts/libraries necessary for a successful build - that he doesn't even remember about. There could also be circular dependencies between the projects which prevent you from building in one step.
You should try and identify the relationships between the projects and then build them separately, until you find where the problem is. You start with those projects not having references on any other ones, and so on. Eventually, you'll find the 'problem' project, and it'll be easier to fix.
I am running opencv 3.0's sample code hog.cpp (from the folder \samples\gpu\hog.cpp) for people detection, using the GPU. (the CPU part crashes for me). The code compiles, but when I run it, it crashes at the line:
gpu_hog->detectMultiScale(gpu_img, found);
Unhandled exception at 0x000007FEDE717A28 (opencv_core300.dll) in
Hog3StandAlone.exe: 0xC0000005: Access violation reading location
0x000002380000013C.
I am using visual studio 2012, Windows 7 Pro 64 bit.
There are quite a few things that can cause such a problem.
The code itself seems "fine".
What I suggest is that you compile the program in Debug mode. Then, run it from Visual Studio. The IDE's debug session should stop at the exact place in which the "access violation" happened. From there, you can have a more precise idea on the origin of the problem.
For example, I got similar problem at line #341
vc >> frame;
because the VideoCapture vc object returned corrupted frames.
Your problem might be similar (or completely different. That's why you should run a debug session in Visual Studio)
I've tried the same sample before and worked without any problems as far as I remember. On the other hand, this access violation is probably due to the fact that your input "gpu_img" is empty or corrupted. Make it sure that you read the frames correctly (you can use imshow function to visually examine) and also you upload it into gpu_img as well. I don't see any other possible explanation.
Description of the problem:
I'm testing the irisVR Beta and I'm trying to launch some cranium.obj 3D model I have. I dragged and dropped the model directly on irisVR launch window and clicked launch. A terminal opens up for half a second and closes. Then nothing happens.
Image 1 -- Iris launch window -- indefinite progress bar
Image 2 -- irisVR console.log
Here is the error I am getting in the console.log:
Question:
What is causing this error, and how do I fix it?
Nate here from IrisVR. Just wanted to let you know that for the next few versions (next few weeks), we have removed OBJ support. Your question makes me realize that our documentation needs some TLC and is misleading - I have added updating it to my task list and it should be amended by EOD tomorrow. Thanks for that!
You'll notice that the drop-zone graphic only includes the SketchUp and Revit icons. This won't last long, I promise! We are building a new system for handling the model geometry and optimizing it for VR and it broke part of the OBJ code. Ultimately, these changes are going to lead to some terrific improvements. Given our limited programming bandwidth right now, we had to pick two file formats to carefully maintain throughout this migration process and we'll pick up the pieces with OBJ ASAP
Thanks again for your patience and for using the app! In the meantime, give a SketchUp model a try :)
Another tester here - ran into the same issue on a fresh Bootcamp install, it's not isolated to the *.obj support that Nate mentioned as was able to recreate with both Sketchup and Revit models.
The current release (v0.2.4) appears to have some dependencies on the Microsoft Visual C++ 2010 redistributable. If you don't have this installed, it will block the associated IrisVR ModelConverter from running and that statistics.ivr file from being generated. Unfortunately there is nothing logged to this effect, so took a bit of digging to find. You will however see a window flash up briefly, then close. This is the ModelConverter attempting to launch and quit.
To resolve, download and install the redistributable from here.
I have got a minigame.exe which crashes at some point inside the game. It does not show any error message and it just says Not Responding. I am using Win 7. I want to identify the crashing point and try to fix the games problem. I think the problem might be caused due to a specific DLL imported by the executable. However, I have no clue about how to find out that specific assembly line and try to patch the executable with OllyDBG.
With the information given, this answer would need a full tutorial style, which is considered as too broad for this site. But the first step, finding out what type of crash it is and where it occurs can be explained.
I'll use WinDbg as the debugger, since I'm not familiar with OllyDbg. It is is part of the Debugging Tools for Windows and it's freely available. Install the versions, x64 or x86, that matches minigame.exe.
Start WinDbg, use the correct bitness
Run minigame.exe under WinDbg (File/Open executable). It will stop at the initial breakpoint.
Set up the symbols, at least .symfix c:\debug\symbols and .reload. This will download information needed to construct the callstack.
Continue running the application with g
Reproduce the issue / wait until it crashes
When WinDbg stops,
create a crash dump with .dump /ma c:\debug\minigame.dmp so you can analyze it later, e.g. for asking questions here, so that you needn't reproduce the bug again.
get information about the exception with .exr -1
switch to the thread that caused the exception with ~#s
look at the callstack with k
Now you should have a better understanding of the crash, perhaps enough to apply a patch, maybe not. At least it's a better starting point for further exploration.
I'm new to VB6 but i'm currently in charge of maintaining a horror of editor like tool with plenty of forms, classes, modules and 3rd party tools all chunk together like the skin faces on that guy in the texas chainsaw massacre...
What i don't understand is why i get different results when i run the app in debugging mode, vs when i compiled it and run it on my devevelopment pc vs when i installed it on a different pc.
Yes i know i'm dumb, so please direct me to where i can find out more about this. I'm hoping to find out something like different linking, registry related etc connection that i'm simply not getting right now, i.e. something like wax on, wax off :P
The main pain in the neck is when i'm trying to debug some errors from my QA and i need to find a spare pc to test this on plus i can't directly debug because i don't know where the code is if i do it that manner.
Thanks.
i run the app in debugging mode vs when i compiled it and run it on my
devevelopment pc
When you compile you have the option of compiling to native code or pcode. The debugger runs using pcode only. Under rare circumstances when you compile to native code there will be a change in behavior. This particular is really rare. I used VB6 since it's release and I may get it once or twice a year. My application is a complex CAD/CAM creating shapes and running metal cutting machine and has two dozen DLLs. Not a typical situation. At home with my hobby software I never ran into this problem.
There are another class of errors that result from event sequencing problems. While VB6 isn't truly multi-tasking it has the ability to jump out of the current code block to process a event. If it re-enters the same block for the new event interesting things (to say the least) can result. I think this is the likely source of your problems as you software is an editor which is a highly interactive type of software.
In general the problem is fixed by reordering the effected areas. You find the effected area by inserting MsgBox or write to a text file to log where you are. I recommend logging to a text file as MsgBox tend to alter behavior that are timing or multi-tasking related.
Remember if a event fire while VB6 in the middle of a code block and there a DoEvents floating around then it will leave the code block process the event and return to the original code block. If it re-enters the same code block and you didn't mean for this to happen then you will have problems. And you will have different problems on different computers as the timing will be different for each.
The easiest way to deal with this type of issues is create some flag variables. In multi-tasking parlance they are known as semaphores or mutexes. WHen you enter a critical section of code, you set it true. When you leave the routine you set it to false. If it is already true when you enter that section of code you don't execute it.
when i installed it on a different pc.
These are usually the result of the wrong DLL installed. Most likely you have an older version while the target has a newer version. I would download the free Virtual PC and create a clean Window XP install to double check this.
If your problem is event timing this too can be different on different computers. This is found by logging (not MsgBox) suspect regions.
If you can display a screen shot or the text of your specific errors then I can help better.
The first thing to check would be the versions of all the dlls that your app depends on - including the service pack version of the VB6 dll.
Have you any more specific details about what's behaving differently?