we are developing a virtual environment using qt5 and pyopenvr with the HTC Vive. All our scripts are fine and working. On one laptop, however, we all of a sudden keep having an issue.
It's a high-end gaming laptop equipped with a gtx1060 (6gb), so it can't be a real memory problem. Even a complete system reboot with only the required installations and all drivers up to date didn't solve it. It used to work at one point when we first tested the laptop, but now this error keeps recurring:
GLError: GLError(
err = 1285,
description = b'Nicht gen\xfcgend Arbeitsspeicher',
baseOperation = glRenderbufferStorageMultisample,
cArguments = (
GL_RENDERBUFFER,
2,
GL_DEPTH24_STENCIL8,
1512,
1680,
))
"Nicht genügend Arbeitsspeicher" is the German equivalent for out of memory.
This happens even if we are running only the sample "hello world"-script of pyopenvr to show the simple color cube. The error is the same when using our scripts. On another laptop, everything works fine.
Anyone encountered a similar issue? Any help appreciated!
This could be a whole set of different issues from driver bug, to a bug in your code that only shows in certain cases.
I would advice that you debug it by different means, such as removing part of the code and seeing if you hit the same bug, or maybe you can break on error to inspect the data that is passed to the driver (is this possible in Python)?
You could also try using different versions of drivers, libraries etc.
Sorry for such a vague answer, but really there isn't much else I could advice from your question.
Related
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.
Im using widows 7 on my working PC and i know i should update (i have win10 on my common pc)
but i still need to finish some important art projects and updating my system now would cause me a lot of compatibility trouble with some wierd and old programs i use so im stuck with win7 until im done with theses projects.
However, last night i had an update (i thought there was no more updates wor win7 Oo')
and since then, my mouse software wont work anymore !
the software is called "Steelseries Engine"
i worked until late and the software was working, but today, it wont start.
i tried to restart, update, and reinstalling but the problem seems to come from some missing dll.
when i go into the install folder and launch it from there, it gives me the following error :
the program cant start because "api-ms-win-core-winrt-string-l1-1-0.dll" is missing.
Anyone could tell me how to repair that ? is it something related to visual c++ or something ?
I really need help, because i have to finish my project fast and witout my mouse setup/macros its going to take ages.
art
Thanks a lot.
I have got the same problem from yesterday, now.
Same message, same circonstances, "steel series" connected + windows 7, and i see no reason why it started. i reinstalled the steelseries engine exe i kept from my personal depository file, and it worked, then today i rebooted the PC and the dll message came back. Very strange. Stranger is that the steel series engine exe for the mouse and Co is not available for windows 7 anymore ont the steelseries website, it is written "For windows 8 and upper versions."
edit: i fixed the .ddl missing trouble, even though i don't know how it started. Thanks to CCLEANER, i found in the start list a long command line stating that the .dll will be deleted by a steel series operator. Delete this useless line (i don't know where it suddenly came from, may be a corrupted auto upgrade by SSeries) and reinstall steelseriesengine. I'm pretty sure this problem had nothing to do with W7. Enjoy.
I am facing a strange issue, I have an old large VB6 app with datareports. It's large, so please don't suggest migrating etc.
I have a datareport on it which filters by date. the report works well on development PC but shows
"no value given for one or more required parameters"
or
"item cannot be found in this ordinal"
on all other PC's. This is quite strange as i have all the files.
Any known similar problem..
For anyone having a similar issue, i found a solution..so this may help in future.. the issue is purely bcoz the database is in the program files folder on non development machine and so full rights are not available to the app.. Try changing the db location outside program files and it'll all be perfect..
I have a network path that contains hundred of thousands .wav files. When I do the following:
FileBuffer = Dir$("\\MEDIASERVER\*.wav", FileAttribute.Archive)
The line freezes forever. I have literally let it run a day, and it never returns with execution. I then decided to test the symptom with a dir command in DOS. Same symptom.
I then wondered if I would get the same symptom if I added a prefix to the search pattern narrowing my results. I did this in DOS:
DIR 0009*.wav
Worked like a charm. So, armed with this knowledge, I went back to my VB.NET project and applied a similar solution:
FileBuffer = Dir$("\\MEDIASERVER\0009*.wav", FileAttribute.Archive)
Doesn't get stuck, actually does the search. But I was surprised by the first result:
FileBuffer came back with the following value:
003925034541228334146804222014065036AM005020MIF.wav
This does not match the pattern I asked for. Can someone tell me what I am doing wrong? Is there a known bug with DIR$? Is there a way to achieve what I want without enumerating 100% of the files in the network share?
Additional Information if it's relevant:
Developement Machine: Windows 7 Pro, VS 2013 Pro
Network Server: Linux Centos 5.0 (I have the same issue with a network drive running Windows 7 Pro).
Thanks in advance.
Sorry for just posting the question, and already getting the answer. The question about whether or not it worked properly in DOS helped narrow my troubleshooting. I came across a couple of pages on the net stating that DIR will come back with unexpected results. They state that it's because of the 8.3 naming convention. I then decided to see if there was any other constraints I could add to my program. I changed the pattern to:
DIR \\MEDIASERVER\0009*MIF.wav
And now I am getting the expected results. This cannot be because of the 8.3 Naming convention though. It's something else, but at least I got this working.
Thanks for your time.
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?