CVS-1456 "Error not in error database"

[RichF]

While running my CVS-1456 I intermittently get an error that locks up the CVS. The error posted in VBAI is "Error not in error database".

The system runs through several states. Each state is small (3 or less steps) due to image acquisition frame rates.

The first determines which shade of grey (Black, grey or white) the part is and switches through the appropriate transition to the next step. It never fails.

The next step looks for a feature at 30fps. Here, it ran continuously for 48 hours in a test. Today, it fails after several minutes. When it works correctly, it runs until the feature is found and then transitions to the next step where an I/O pulse is fired.

I formatted the unit and reinstalled the software. Still....

I am not moving the cameras or causing cable flex that may loosen the camera connections.

There is very low electrical noise in the area.

Are there buffers that need to be cleared? Does anyone have expperience with this?

[iZACHdx]

Hello,

After reformatting and everything, you still get the error everytime without fail? Have you tried separating your two inspection steps and running them on the CVS just to make sure that one is running and the other is failing? Does it give an error number at all or just the message? What versions of VBAI and drivers do you have?

-Zach

[RichF]

Zach,

The problem occurs at various points in the inspection. Usually during a 30fps inspection, but not always. Sometimes cam0, sometimes cam1.

I have confirmed also that the camera config was correct and that it was in sync with MAX. (Format 7) Small frame, approximately 2250 per firewire packet. (I found that if the unit has been formatted, the MAX config for the cameras default to Mono 16, 60fps which hogs all of the IEEE 1394 bandwidth in a hurry) I believe 4912 is the max combined packet size for all cameras.

VBAI 2009 SP1For program developnent on my laptop

The softwares on the CVS are:

Labview Realtime 8.5.1

Language Support for Labview RT 1.0.0.3

Variable Client support for Labview RT 1.4.1

NI-Visa Server 4.2

NI-Visa 4.5.1

NI-RIO 3.2.1

NI-IMAQ for IEEE1394 RT 2.0.5

NI-IMAQ Server 2.9.0.3.0

NI-IMAQ I/O 2.3.0

Datasocket for Labview RT 4.5.4

Ethernet IP Industrial protocol Support 1.0.4.3.0

NI-1394 external Drive support 1.4.4.3.0

NI-Vision RT 9.0.3

Network Variable Engine 1.4.1

NI-Serial RT 3.3.4

Vision Builder AI 4.0.1

Thanks.

[RichF]

Also, there is no error code.

Rich

[iZACHdx]

Hello,

Does this only occur with this one inspection? Can you be a little more specific about you inspection steps?

-Zach

[RichF]

Sure.

The inspection is broken down into several states with non-default transitions.

A moving part is located in one state running at 30fps. 

The next state fires a TTL pulse. That's all. It tells the machine to slow the part down. (I found that if I put too much in a single state, it compromised speed)

The next state also runs at 30fps and detects when the part is "home".

The next state fires a "home" TTL signal.

There are several programs like this that are selected using the Inspection select discrete I/O inputs. One has three branches like the above description. The branch is selected by a histogram function at the beginning of the inspection.

Is there a limit to program size? I found that the more states there are in a single inspection, the higher the likelihood that the errors occur.

Also, after editing and before rebooting.

Thanks,

Rich

[iZACHdx]

Hello,

I would like to try and reproduce this here. Can you post your inspection and some sample images?

-Zach

[RichF]

Because it is somewhat proprietary, do you have a direct email to send the attachments?

To explain the application, it is a set of rings.

The bottom ring rotates cw from right to left.

If there is a slot in the ROI initially, it is ignored and the ring rotates 360 degrees.

Once the slot reenters the FOV, the circular edge tool picks it up.

The system fires a TTL output to indicate that the slot is in the FOV and to slow down.

The short, straight edge tool detects when the slot is home.

The system fires another TTL output to indicate that the slot is home.

These steps repeat for the middle ring, which rotates into the FOV from left to right, and then the top ring that rotates into the FOV from right to left.

The framerate is usually in excess of 30fps and this inspection series almost always fails at some point...but not at the same place.

I have broken the inspection into four separate inspections, triggerend by the inspection select discrete inputs,  and the system does not fail.

The problem THEN becomes one where there is a delay while the next program loads. A single program would be fastest.

[iZACHdx]

Hello,

If you cannot post the code to the forums because of proprietary information, I would recommend that you visit ni.com/support and create an e-mail service request there. This will get directed to the appropriate team so that one of our Applications Engineers can take a better look at that is going on.

-Zach

[RichF]

Zach,

I thought I was an SSP member due to recent purchases but apparently not. The customer has allowed me to forward.

Thanks for your help.

Rich