04-10-2012 05:13 AM
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.
04-12-2012 05:02 PM
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:
Could this be in any way linked to your issue?
04-13-2012 06:31 AM
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.
04-16-2012 02:56 PM
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
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.
04-25-2012 06:14 AM
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
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.
05-04-2012 05:14 AM
Which error do you exactly get?
Do you have an error code?
Is it this (http://digital.ni.com/public.nsf/allkb/5D55CF21540
The NI PCI-1422 and PCI-1424 do have a minimal amount of onboard memory available on the framegrabbers:
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:
05-24-2012 09:19 AM
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).
05-29-2012 06:12 AM
It indeed seem to be related to OS/bus combinations.
Do you have MAX Reports (http://digital.ni.com/public.nsf/allkb/271F252B4EF