07-30-2017 09:17 PM
Hello,
I created an executable/installer to run USB3 camera (Tornado spectormeter) on the target machine. It installed correctly since MAX can see the camera. But when I try to run the camera, it shows below error. VAS is installed and licensed. I ran the software from the manufacture, it runs fine. Has anyone encountered such problem?
Windows 10-64bit
Thank you again.
Solved! Go to Solution.
07-31-2017 04:31 AM
related xml file to your camera are corrupted somehow and you have to repair it
07-31-2017 09:35 AM
Hello,
Sorry to hear about your issue. I am a developer at NI who works on driver software for USB3 Vision cameras. I have seen a similar problem with a few other cameras (see this post and this post), so I have an idea of what could possibly be happening.
Long story short, NI software resets the USB endpoints on the camera to ensure it's in a good state before trying to communicate with it. On the control channel endpoint in particular (which is used for communication like reading/writing camera attributes), I have observed that in many cases the vendor software does not do this step, but we do. Sometimes, especially if it hasn't been tested by the vendor, the camera does not correctly handle this command to reset the control channel endpoint on the camera. I am guessing that your camera does not respond well to when we reset the control endpoint when we try to open a session to the camera. Anecdotally I've seen more issues with this with Win 8+.
You can determine if my guess is correct by disabling this behavior via registry key***:
Making that registry key change means that we won't do endpoint stalling on any endpoint (the image streaming endpoint for example... more than just the communication on the control endpoint). Since the stalling is used as more of a failsafe, everything should still work file with that change. However, it may impact the driver's ability to recover from error. Ideally if this is the issue, we'd want the camera vendor to provide a firmware update that resolves the problem and then you could re-enable the registry key.
Please let me know if this is the issue, as we will want to reach out to the camera vendor and let them know that the camera isn't properly handling that specific command. Because we've seen this issue across several cameras, I'm working on potentially making a change on our end as well to try to avoid getting into this situation. I'm also communicating with the USB3 Vision standards committee about how to ensure cameras properly handle this use case in the future.
Please let me know if you have any more questions, and if you can try out that registry key to see if this is indeed the problem you're experiencing.
-Katie
***DISCLAIMER: This step involves editing the registry. Inappropriate changes to the Windows Registry can disable the operating system or prevent it from functioning properly. To safeguard against such an accident, we recommend that you back up your existing registry by choosing Registry » Export Registry File... after launching the Registry Editor and before making any changes.
07-31-2017 01:29 PM
Thank you so much. This fixed the issue.
FYI, the device is Tornado Spectrometer, USB3.0, that uses Pleora driver to communicate.
Thanks!
02-21-2018 02:47 PM
Thank you so much. This solved my problem as well. I am using a Basler acA1920-155um USB3 camera. The IMAQdx Open Camera vi would hang for several seconds and then return with error "-1074360258" every other time I ran my program. I found this strange, but was able to continue to use my program as long as I ran it twice and waited for the Open Camera vi to timeout. In MAX, I got the error mentioned by dk91 above, "0xBFF6903E," again every other time I try to access the camera. After making the registry key setting change suggest by kensign I no longer get any error messages.
02-21-2018 03:04 PM
I'm glad to hear this change helped you work around your problem!
I just wanted to circle back on this issue. In our latest (17.5) release (download here), we made a change on our end to mitigate this issue in a more targeted way than just changing the registry key.
In the future, if you're in this situation please just download an IMAQdx version 17.5 or later and you should not have this problem anymore. Please let me know if this is not the case for anyone.
If you were using this work around and then updated your IMAQdx, you should go back to your registry and change the key U3V_DisableEndpointStall to have a value of 0. As I mentioned before, that registry key disables ALL endpoint stalling, which in some edge cases could negatively impact the ability of the driver to recover from an error from the camera. The change to IMAQdx 17.5 is scoped to only disable the stalling of the control endpoints in a non-error case by default, so this should give you the benefits of the work around without any of the risk I mentioned above.
Please let me know if anyone experiences these issues anymore with U3V_DisableEndpointStall set to 0 (or not set at all) and IMAQdx 17.5 or later.
Thanks so much for your feedback!
Katie
Software Engineer, Vision Acquisition Software
01-15-2020 07:27 AM
Hello,
I faced a similar issue with a SVS-VISTEK camera USB3
Error -1074360258 with IMAQdx Configure Acquisition.vi
I work with IMAQdx 19.5 on Windows 10
Is it the same problem encountered in 2018 ?
01-20-2020 12:04 PM
Since we made a change to the driver to avoid control channel endpoint stalling in the general case with IMAQdx 17.5, the error you're seeing must be something different. I would recommend contacting NI support to assist with debugging this specific issue. I don't think the registry key described earlier in the post would help with your issue. Because this type of error indicates a fundamental communication problem, this will probably need to be investigated and worked out between NI R&D and SVS-VISTEK R&D.