IMAQdx Timeout on Smart Camera (1774C) in stand-alone only

[DenverRod]

We have a 1774C smart camera that works well in development mode but not when the application is built and deployed.

The application ALWAYS works in development mode and occasionally when deployed as stand-alone.

We use the IMAQdx Grab.vi (triggered grab with 100ms timeout) to grab the image (we also use this to time the loop).

We probed the error out of the grab function in debug mode and found that we got a timeout error. We clear this error

during every iteration when it occurs, but we have it again during the next iteration.

We have another 1774C camera that runs the same code in stand-alone mode with no problems.

We have tried the following:

1) Format and re-install all software using MAX - no change

2) Re-install NI IMAQdx software using MAX - worked the first time the camera was restarted but not again afterwards.

3) Timeout settings higher than 100ms - no change

What else can we try? What could the problem be?

[[dk]]

How old is the 1774C smart camera that is giving you problems? How many times does it actually time out when executing as a stand-alone system (you mentioned occasionally)?

Is it possible to set the camera to re-initialize if the timeout does occur? My initial thought is that the camera hardware could be faulty, but the fact that it always run in development mode is curious.

[RichardM]

We tried two cameras and got similar results.

The oldest unit would be probably one of the first production runs.

The other unit is probably 6 months or so old.

[DenverRod]

Hi Dan

When we cycle power or restart the camera, the grab function either works for the entire duration while the system is on or continuously times out. We haven't had a situation where it switches from working to timing out or vice versa. So what I meant with occassionally is after restart/power up.

I mentioned that 1 camera did not give us this problem - this turned out to be incorrect.

The camera that gave us problems were on site while the other one was at our office. We tested the office camera with the same code and experienced no problems but when we took it to site we experienced the same problem.

We then brought the site camera and connector block to the office and tested it - no problems were experienced. The only difference between the two systems now is the power supply. We will take the office power supply to site and test the system and provide some feedback later.

It is not possible to re-initialize the camera when it times out in our application.

[BlueCheese]

What sort of trigger signal are you using? What is the voltage range is it; how long does it pulse?

This sounds to me like a triggering issue.... Can you confirm this by seeing if the device runs in free-run mode in your setup?

Eric

[RichardM]

Thanks for your reply.

The other guys who are more intimate with the project will probably only see your post tomorrow (time zone differences), so would you mind giving some comments on possible issues relating to voltage range of sensor; pulse duration; etc.

I do not know if they tried free run.

Could a voltage glitch be a cause of a problem (we are using an NI 24V power supply)? (e.g. if a big machine starts up nearby)

Richard

[DenverRod]

Hi Dan and Eric

Thanks for responding to the question. We've found the cause of the problem and solved it. It was due to a mistake we made in software.

I will now try to explain what caused the problem and how we solved it.

The camera is opened, attributes are set and the IMAQdx Configure Grab.vi is called before the main loop is entered.

Some attributes (worth mentioning) that were set:

•  Trigger: On, External, Rising Edge, No delay
• Timeout: 50 ms

The settings used for IMAQdx Configure Grab.vi were as follows:

•  Wait for next image, Continuous and Buffer Size = 5

The main loop (while) is then entered and waits in a "Stopped" state for "Start" button (physical button on panel) to be pushed.

When the "Start" button is pushed, the "Run" case is entered.

In the "Run" case the following happens:

•  The IMAQdx Grab.vi is called
• Inspection is done when image is "grabbed" with no errors
• The "Stop" button is monitored (This button does not stop the program. Only the grabbing of images and inspection)

The problem we encountered was during the "Run" state (Stand-Alone mode only). A timeout occurs continuously - no images are acquired for inspection purposes.

It later occurred to us that this problem is only encountered when 1) we cycle power and 2) there are products on the line triggering the camera before we push the "Start" button (a situation which was never simulated at the office). So, I think, the buffer is full by the time we want to "Grab" the "next image" and it continuously times out. 

Solution:

•  Only enabling the trigger when start button is pushed 
•  Only Calling the "IMAQdx Start Acquisition.vi" when the "Start Button" is pushed. This VI is called in the "IMAQdx Configure Grab.vi" that we called in the beginning. The  "IMAQdx Start Acquisition.vi" was removed from the "IMAQdx Configure Grab.vi" and only called when start button is pushed. (Note: this step was necessary since images were still acquired even though the trigger was disabled. I believe the camera went into free-running mode (?))

Question: Why did this problem not ever occur in development mode? What's the difference in the behaviour of the buffer?

[BlueCheese]

The buffering doesn't quite work the way you think it does. New images will always overwrite old images in the internal bufferlist as long as it can access them. The only thing that prevents access to them is that each buffer is temporarilly locked while you call Get Image on it and if the acquisition loops around to that one you are trying to Get it can cause that buffer to be skipped. However, once the Get call completes, the next image to be triggered will be captured into that buffer.

Thus I can't quite explain the behavior you are seeing. I suspect it is more subtle interaction with your code. Without seeing it I can't think of any specific reasons.

Eric

[DenverRod]

Hi Eric

See attached VIs that shows the method we used which gave us problems and the method we used to overcome it.

The bad version only works if you push start and enter the run case before the line is running.

Can you tell why the problematic version would work only in development mode?

Regards

Denver

[BlueCheese]

Are your images being continuously triggered or do you just send one trigger? If you just send one, I suspect one issue could be that you have your Grab call set to "Wait for next image". What this means is that it will wait until the "next" image comes (basically it waits for last_buffer_number_received+1), even if you already have a new one already available that you have not grabbed yet. Generally if you are going to be tightly controlling the timing you'll want to instead use the Low level Get Image and request a specific buffer number. The difference between the two sets of code could be the timing of the setup and whether the Grab call starts waiting before or after the first trigger comes in.

It might be worthwhile to put a debugging while loop that just polls the number of acquired buffers so you can see if the camera is acquiring images.

Eric