invalid node error during connect to camera in Spectrum Analyser

[Luc]

Ok so I had a look at the problem and it should be a file replacement issue.

The error you get ("Invalid node") does not exist anymore since the patch and has been replaced by another error "invalid node "XYZ"" where XYZ is the name of the node that cause a problem. So if you still see the old error message it means you are running the old dll.

To be sure, remove all dlls in the bin64 folder and replace them with the one you just compiled (or here attached if you use the SDK that I uploaded on the website)

pointgrey.zip

(142.26 KiB) Downloaded 3213 times

[Luc]

I implemented several hotfixes for the BFS camera:

• calibration is now supported with BFS camera
• removed the error message when connecting to a BFS camera
• removed annoying errors during calibration when no peaks are detected

I wasn't able to validate the calibration support for BFS because I don't have the time yet to integrate it into the spectrometer and put the neon source (I'm currently moving everything in my house and don't have much access to my lab). The fix is simple enough so that it should work (if not, please tell me!).

If the software cannot save the calibration into the camera, it will default to saving the calibration file in My Documents/OpenRAMAN/calibration.dat. It's really an uggly patch with no check for camera serial number and so on. But at least it should deliver the function to the end user!

SpectrumAnalyzer.zip

(161.48 KiB) Downloaded 3248 times

I'll make it cleaner when I have more time

[automatic_jack]

To be sure, remove all dlls in the bin64 folder and replace them with the one you just compiled (or here attached if you use the SDK that I uploaded on the website)

pointgrey.zip

Are you sure this is a different dll? The md5sums are the same as the one published earlier in this thread.

Code: Select all

5560daf8d86105aab076686ba4284138 *pointgrey.dll
5560daf8d86105aab076686ba4284138 *OLD\\pointgrey.dll

[Luc]

To be sure, remove all dlls in the bin64 folder and replace them with the one you just compiled (or here attached if you use the SDK that I uploaded on the website)

pointgrey.zip

Are you sure this is a different dll? The md5sums are the same as the one published earlier in this thread.

Code: Select all

5560daf8d86105aab076686ba4284138 *pointgrey.dll
5560daf8d86105aab076686ba4284138 *OLD\\pointgrey.dll

Yes indeed they are the same. I wanted to make sure that we were using the same files and not some older version.

Quick couple more questions:

• does the camera work in spinview ?
• did you close spinview when trying to access the camera ? (they cannot access the camera both at the same time)

A screenshot of the most recent error message dialog box would help

[automatic_jack]

Quick couple more questions:

• does the camera work in spinview ?
• did you close spinview when trying to access the camera ? (they cannot access the camera both at the same time)

A screenshot of the most recent error message dialog box would help

Yes, the camera works in Spinview, with proof attached here, the spectrum of a neon lamp.

I only run Spinview when I need to be sure that the camera is working.

The forum-supplied pointgray.dll is unable to find any camera interfaces, but the debug version I built from unmodified source and solution successfully finds the devices. This is additionally using the source package you posted earlier, @Luc, and built this morning with the defaults (excepting a change to OutputDirectory).

I am tracking changes locally in a git repository, but it would be nice if we had a GitLab rendezvous point instead of passing around zip files.

[Luc]

I wouldn't pay too much attention to that error because it can technically happen if you use the dll in debug mode and the main app in release mode.

It's weird that SpinView finds the camera but not the SpectrumAnalyzer software because I'm directly relying on FLIR's SDK to populate the cameras. Did you try to uninstall FLIR SDK and reinstall it ? Just in case some drivers or else were not installed properly.

Side node but the neon spectrum looks super fishy. You should expect very sharp lines that are ~100 px tall at most. Here it looks like the objective focus is incorrect.

[automatic_jack]

I wouldn't pay too much attention to that error because it can technically happen if you use the dll in debug mode and the main app in release mode.

Noted, but that's not the build settings, which is why it was relevant.
Edit: the build *was* a Debug build, but that's not what I thought I'd asked it to do. VS 2022 is more "helpful" than previous versions, apparently.

It's weird that SpinView finds the camera but not the SpectrumAnalyzer software because I'm directly relying on FLIR's SDK to populate the cameras. Did you try to uninstall FLIR SDK and reinstall it ? Just in case some drivers or else were not installed properly.

I'll try that, but there were no differences in execution after the last two re-installations.

Side node but the neon spectrum looks super fishy. You should expect very sharp lines that are ~100 px tall at most. Here it looks like the objective focus is incorrect.

That's likely as the lamp was simply resting where the system was responding to it. I didn't take it as an indictment of the system's quality.

[automatic_jack]

I have had success in pulling an uncalibrated spectrum from the system.

However, exiting the spectrum-collection software caused the tool to stop cooperating. Attached is the result, even after rebooting but making no changes in the configuration.

Is there a need or mechanism to force the SpectrumAnalyzer tool to defaults?

[automatic_jack]

You're probably ahead of me here, @Luc, but the point where the error happens is in pointgrey.dll's camera.h on line 222, which is in the init() function:

Code: Select all

assert_node(ImageFormatControl.height);

I intend to run the full debugging versions of the app and dll later today CDT and see if I can dump the object coming back from the Spinnaker API.

[automatic_jack]

Would you believe that the switch on the power-strip which the camera is powered by has no effect on actually interrupting the power to the camera? Not quite "PEBKAC," but awkward none the less.

Power-cycling the camera seems to have set this part straight.

Attached is a curve generated with a neon source.

Also, while calibrating the system (with no laser on), I have found that with the FLIR Blackfly S, it is possible to overload the camera with a bright light source. This happened while using a CFL source. SpectrumAnalyzer displays the message "Waiting for data" in the plot background. Blocking the light from the source will allow SpectrumAnalyzer to successfully collect a spectrum. Removing the blockage results in the message appearing again in the plot background.

I'm not sure if this needs to be controlled better in the software, but it was unexpected.