I can successfully open the camera and view images in NxView, so the hardware connection seems stable. However, when I attempt to access the camera using the C++ nxSimple project from Ensenso SDK, I receive an exception. I’m using Visual Studio 2019
The output I receive upon running the program is as follows:
Could you please advise on how to resolve this issue? I have verified that the camera is working correctly in NxView, so it seems to be an API or configuration issue. Any insights or troubleshooting steps would be greatly appreciated.
we appear to be using an incorrect type specifier in a string formatting function somewhere.
I have not found the location yet and did not manage to reproduce the error either, so it would greatly aid the search if you could provide an NxLib log file from running the example. It is probably easiest if you copy the code snippets from the online guides to set the log level and set the level to valTrace, and then use the log writer built into NxLib. In the meantime, I will keep scanning our codebase.
This is not a common issue, so I am confident that we will find a workaround.
I have attached the requested logs for your review.
Additionally, I wanted to mention that I tried running the same example with an older version of the Ensenso SDK (version 2.3), and the example works correctly with that version.
Please let me know if there is any other information I can provide or any additional tests you would like me to perform.
Have you had a chance to review the logs I sent? I’m planning to install the latest SDK version and would appreciate any updates or recommendations to fix the issue.
I am still working on it. I could not pinpoint an exact location from you log, so I have enabled every check I could find: still nothing. I have improved the runtime error reporting as well, but since I do not see the error I need your help. If I send you a preview release containing the improved reporting, could you run that and see if the error persists and send me back the new error message? I could have that ready for you on monday.
Thank you for the update. Yes, please send me the preview release with the improved error reporting. I’d be happy to test it and provide you with the new error messages.
Thank you for the feedback you provided via PM. It helped me a lot to fix the bad format string.
Now we can focus on solving your underlying problem: the NxLib fails to connect to the projector when using the NxSimple example but not using NxView. Could you send me a log from NxView where you open the camera, so I can compare the two?
To capture a log in NxView you can use NxTreeEdit or press Ctrl-L in the camera selection window, open the camera normally and pres Ctrl-L again. This should open NxProfiler, which shows the path to the file in the title bar.
I suspect some issue with your network. Is you configuration okay, e.g. no overlapping subnets etc.? NxView shows a warning in the lower right of the camera selection window if it detects possible problems, which you can click on for further information:
From the log your configuration looks okay, but can you post a copy of the NxLib tree so I can verify? It lists all your network adapters and IP addresses.
How to copy the NxLib tree
Click the NxTreeEdit icon in NxView:
Right-click the root node / at the very top.
Select “Copy value as JSON string” from the context menu.
Paste the JSON into any text editor and save, or paste it directly in you reply.
Do you have a firewall enabled that blocks NxSimple but not NxView? The X projector requires TCP and UDP ports 24100, as detailed in our firewall configuration guide. UDP seems to be working for both programs, otherwise the projector would not be detected and NxSimple would not try to open the camera. Can you disable the windows firewall and see if it makes a difference?
Can your rule out any IP conflicts? Do you have the camera attached directly to your PC or do they talk over some wider network?
Is there already more information about this issue? We are having a similar issue. On an IPC (with windows 10 and EnsensoSDK 4.0.1502) it does not work from a C# project (we got also error code 17); NxView works without any problems. Firewall is enabled for the specific ports and no conflicting IP configurations.
How similar is your issue? Do you get the same error text about the incorrect format string? If you get a different error message, it might be better if you started a new thread.
In any case: can you please attach a log on debug level Trace and a copy of your NxLib tree, both from NxView and from your application? Do you get the same error on any of the NxSimple examples?
Apologies for the delayed response; I have been on vacation.
I have disabled the firewall to eliminate the warning, but I am still experiencing the same issue. At the moment, I have two cameras connected directly to my PC: a C57 and an X36. The C57 is working correctly, but the X36 continues to show the error we are discussing.
Attached below is the JSON file containing the NxLib tree as requested:
Welcome back, no need to apologize. We used the time to release SDK 4.0.1516, wherein, among other things, we fixed the wrong format string. So now you can finally see the error message in all its glory.
Concerning the resolution of the underlying problem, I am afraid that I have no new insights: I cannot see anything wrong with your NxLib tree. And with the firewall deactivated, there should not be anything stopping you from opening the projector.
As far as the C57 is concerned: the C series uses the GigEVision protocol to communicate. The same protocol is also used to communicate with the cameras on the X36, and those seem to be working fine. But the X projector uses a different, proprietary protocol.
Can you run any of the other examples and see if they work, maybe try the Python example nx_simple.py?
Since the issue seems to be network related: could you provide packet captures, e.g. using Wireshark, from opening the camera in NxView and NxSimple? You can message them to me directly to avoid information disclosure.
just another guess: I’m not sure how the “allowed app” list in Windows interacts with the general firewall settings. Can you maybe check if there are any entries in the list for your executable where not all checkboxes are ticked?
If so, please tick all of them for your executable. Sometime you can also have multiple entries, if the same executable name existed in multiple locations. Especially the ‘Public’ profile will likely be the one that’s being used by the local adaptor where the cameras are connected.
Do you have any other firewalling software installed that could lead to different behaviour of the NxView and NxSimple executable?
We have an external firewalling software installed which manages windows defender setting. However, we have disabled that software and the problem still persists.
Thank you for the packet capture files. When you captured the network packets, did you get the same error message from NxSimple as before: “Could not connect to host …”? Because from the capture it looks like the connection was established successfully, the conversation is just rather shorter for NxSimple than it is for NxView, but it does not look like the same error to me?
Yes, I did encounter the same error message from NxSimple: “Could not connect to host …”. However, I’ve found something that might be a clue to the issue.
NxLibItem cameras(itmCameras);
NxLibItem camera = cameras[0];
std::string serial = camera[itmSerialNumber].asString();
NxLibCommand open(cmdOpen);
open.parameters()[itmCameras] = serial;
std::this_thread::sleep_for(std::chrono::milliseconds(1000)); // SOLVES PROBLEM
open.execute();
This delay seems to resolve the problem. Let me know if you need further details or additional tests.
Could it be that even the ‘disabled’ state introduces some delay, until the TCP communication is allowed? That would explain why your solution with sleep works. And in NxView you just wouldn’t notice this, because you need some time to click the ‘Open’ button.
You could verify the ‘delay theory’ by launching NxView with the command line parameter --open <CameraSerial>. This will also directly open the camera, without showing the UI. But the delay in NxView might be longer compared to the rather minimal NxSimple example.
