04-10-2012 05:13 AM
Hello Thierry,
Frame rate and LUT are 2 parameters that can be changed: In the C++ program we use, the LUT is linear (allthough sometimes we change it through the NI software, to check some images) and frame rate is a parameter that can be changed. We did some tests with different frame rates and always we see the same problem.
We just use the PCI-card, which I just plugged in two different computers. There is no PXI chassis involved.
Regards,
Bart
04-12-2012 05:02 PM
Hello Bart,
The coming week I'm not at the office so I'll try to do my best to help you from home.
There were some things that popped into mind while reading this thread and I would like to have reconfirmation about:
- You are using exactly the same card and are swapping it between the 2 PC's? Or are you using the same type of card?
- Are you using exactly the same camera and exactly the same cable? Or are you using 2 camera's of the same type and 2 cables of the same type?
- Are you using exactly the same code on both pc's or are there subtle differences, because of the 64-bit 32-bit differences?
- Did you recompile both pieces of code in the same "way" (eg. enabling debugging features) and ended up with one 32 bit application and one 64 bit application?
Rereading this thread I also started thinking about a previous issue I had. The explanation of that issue was found on this webpage:
http://digital.ni.com/public.nsf/allkb/96CB1A25EFF49A3C86256F80005B8EB1 (in the section Parallel Digital Camera Acquisition)
Could this be in any way linked to your issue?
04-13-2012 06:31 AM
Hello Thierry,
I thought that you would have a week off, because the reply took so long
Here are the answers to your questions:
1. We are using exactly the same card which we swap between the 2 PCs.
2. We use the same camera and the same cable.
3.&4. We use exactly the same code on the 64-bit and 32-bit machines. And they are compiled in the same way.
I looked at the "parallel digital camera acquisition" section and discussed it with our software engineer. We don't think it's the same issue. It's not that our camera only outputs half the number of images that we expect. Sometimes, a frame is skipped. Everything can be OK for x number of frames and then suddenly one frame is darker. We then still have an image on the screen, only the image looks much darker due to the exposure time which is too short.
Regards,
Bart
04-16-2012 02:56 PM
Hello Bart,
I have one simple (but important question) left for you.
Did you do a recompilation after the installation of the new drivers?
Can you share an extract of how the descibed code/functions is/are used in the final program with me?
04-18-2012 05:15 AM
Hi Thierry,
We did a recompilation of the C++ program (code.cpp) that I have attached to one of the previous posts, on the 64-bit computer that we are using and where we installed the latest drivers. Still we have the same problem: 200 out of 3000 frames were skipped.
I cannot send you the final program. This program controls a micro-CT machine and is too long to send to you. You also cannot compile it because it needs other drivers. That's why we wrote a small simple program, first for ourselves to test the snapimage function, secondly to send to you. This small program code.cpp also experiences the same problem as what we have in the final code.
Regards,
Bart
04-25-2012 06:14 AM
Hello Bart,
Thanks for sharing this information.
I had one last question before further escalating this issue.
Are you able tor reproduce this issue on another 64-bit system?
05-02-2012 10:11 AM
Hi Thierry,
Last week and this week we did some extra tests.
1. As everything worked on a 32-bit system, but not on a 64-bit system, we installed a dual boot on the 64-bit system. Windows 7 32-bit was installed, but also then we experienced the same problem. So I think it has nothing to do with the operating system.
2. We have a second system (same type of scanner, same type of camera, same type of framegrabber, same type of 64-bit computer with Windows 7, everything is identical) somewhere in Germany. We did remotely the same test to check if this scanner skips some frames or not. It has ran for approx. 3 hours and none of the 6500 frames was skipped. The computer was running on 64-bit Windows 7.
We also work with other framegrabbers from NI (1422) in other scanners. And lately with 64-bit systems, we also experience problems with these framegrabbers. Last week our software engineer looked into the problem a bit more and he saw that sometimes there was a FIFO error. Can it be that when data is transferred from framegrabber (which has no memory on board) to the computer memory, something goes wrong or that data transfer through the PCI bus is on the limit.
Regards,
bart
05-04-2012 05:14 AM
Hello Bert,
Which error do you exactly get?
Do you have an error code?
Is it this (http://digital.ni.com/public.nsf/allkb/5D55CF2154009495862571EA006625C4) error code you get?
The NI PCI-1422 and PCI-1424 do have a minimal amount of onboard memory available on the framegrabbers:
http://digital.ni.com/public.nsf/allkb/DEBD7A051B083E1E86256B5D005F588C
Have you tried removing other PCI-cards that are on the same PCI-bus?
Some other possible causes of overflow errors are explained over here:
http://digital.ni.com/public.nsf/allkb/32F3F5E8B65E9710862573D70075EED1
05-24-2012 09:19 AM
Hi Thierry,
We have tested the configuration of the Hamamatsu flatpanel and the NI PCI-1424 (always with the same cables, framegrabber and flatpanel) on different computers and operating systems.
1. computer 1 with 64-bit Windows 7: Imagesnap function fails frequently (MAX report was attached in one of the previous posts)
2. computer 2 with 32-bit Windows Vista: Imagesnap works fine without problem (max report was attached in one of the previous posts)
3. computer 3 with 32 bit Windows XP: Imagesnap function works fine.
4. computer 3 (same as in point 3 - dual boot system) with 64-bit Vista: Imagesnap function sometimes fail
5. computer 3 with 64-bit Windows 7: Imagesnap function fails immediately
----
6. computer 4 with 64-bit Windows 7 with same configuration (but at another location): Imagesnap works fine.
It seems it's not only a problem of the bus or the OS, but a combination of the 2!
For the time being, we will run the program in Windows XP and hope that it will run in WIndows 7 at our customer site (computer 4).
Regards,
Bart
05-29-2012 06:12 AM
Hello Bart,
It indeed seem to be related to OS/bus combinations.
Do you have MAX Reports (http://digital.ni.com/public.nsf/allkb/271F252B4EF0A2E0862570E70056A1E4?OpenDocument) and System Information Reports (http://ae.natinst.com/public.nsf/web/searchinternal/ddf39729a407bfc1862578f7007807a3?OpenDocument) of all of those systems?