why it takes so long to send a signal when in inspection mode vs. configuration mode or benchmark tests w/CVS

[scott_7723]

I use the decision making step in VBAI 2.5 to reject unacceptable parts by sending the signal out the 37-Pin connector via an ISO OUT port, in which I have been doing since we first purchased the CVS 1456 systems.  I wondered why it takes so long to send this signal when in inspection mode vs. configuration mode or benchmark tests?  In other words, if I run the inspection there is atleast a 1/2 second lapse in time until the signal is sent, however, when I run configuration mode until failure, it takes an instant to send this signal.  This is verified on the display as well.  Every inspection has a final step of displaying images which includes a Boolean of fail or pass (after the decision making step; and the inspection is set to fail upon the decision making step).  When a part pass/fails, the display shows the result 1 to 2 seconds after it has started, yet, Benchmarking instantly sends the signal every time there is a failure (all inspections take up to 400ms according to benchmark tests) and the display shows the result just as fast.  Same goes with configuration mode.  Any known reason for this or way to not have it perform this way?  Thanks for your time

[DJ_L.]

Hey Scott,

Have you tried to remove any host - target interaction, and just run your inspection on the CVS only? When you run in Inspection mode while connected to the host, it has to send both the images, and the inspection information from the CVS back to the host, which might be slowing down your overall inspection time. Also, when you select how the ISO OUT signal is sent, what do you choose as the signal type, Inspection FAIL, or one of the Step Status choices? Try running the VBAI script without the host connected and see if you get better performance. Also, check any of your other settings to make sure nothing else could be causing this behavior. Keep us updated on how things go.

Regards,
DJ L.

[scott_7723]

Thanks for your reply.  I use the decision Making status as the ISO Out that would reject the part from the product line.  The inspections fail only if Decision Making Step is false (Global settings) due to the fact that there are features on our parts that, at times, are seen better from the other image, and vice verse.  There are no delays in any and all of the settings.  And, yes, I always have it run on the CVS alone.  I use the host computers only for changing over programs or for making adjustments, then I properly disconnect from the CVS.  Thanks again for your input.  Wish I could make these CVS's respond as quickly as the benchmarking shows and does. 

[scott_7723]

Any more reasons for this behavior?

[DJ_L.]

Hey Scott,

Without seeing your script and the settings you have chosen, it is hard to determine what might be going on. If you would like to post your VBAI script, I can try and run it on one of our CVS's here and see if I can see the same behavior to determine if it the script or the CVS.

Also, do you see the same behavior using VBAI 2.6 or is it just with 2.5? Have you tried to run an example script and add the decision making step that does an ISO out on a failed step, and does that give the same result? I have been able to get an example to run in the inspection mode with no delay, so there could be a few things going on with your script. Let us know if you would like us to take a look at your script. Thanks, and have a good one.

Regards,
DJ L.

[scott_7723]

Hey DJ L, not sure if you'll ever view this again, for it has been a year now since we last posted anything.  And of course, now it is occurring again.  Basically, I have a CVS that seems to activate an ISO OUT line based on a failed decision making step almost 5 seconds after the part begins processing.  The benchmarking shows ~250ms to process, and the ISO Out port is Driven Low on the 37-pin terminal block almost immediately, however, it takes 4-5 seconds when in run inspection mode with/without the host computer connected to it.  It used to drive the line much much faster when we first started using the CVSes.  I haven't been exceeding the current/voltage that these lines are supposed to handle.  I don't understand why it is taking so long.  Is there any accounts of this occurring to others?  Am I suppose to expect this to happen over time...like most PCs, they just degrade/slow down over time from heat, every day use, etc?  I will try to re-write the script and see if it fixes it, but until then, let me know if you are still out there and I will send you the script at that point.  Thanks for your time.  Oh, and I am using VBAI 2.6.1 on a CVS1456

Message Edited by scott_7723 on 03-13-2007 03:32 PM

[DJ_L.]

Hey Scott,

I am still out here. To address your questions: I have not heard of or seen other customers with this same behavior before. Most likely this is not supposed to happen over time, (not to say that it couldn't, because the CVS is pretty much a PC with a Real Time OS on it), but the CVS's are pretty rugged and I don't think you have had it that long to start doing this type of behavior. If you think that the CVS might be overheating, then this can cause unexpected behavior, but only when the CVS overheats, not right away when you switch to inpection mode.

You said you are going to re-write the inpection, but I would also recommend that you do a couple other things as well. First, go ahead and Format the CVS so that you start with a fresh install of the software. Second, if possible and if you have it, load VBAI 3.0.1 (most recent at the time of this post) onto the CVS. There have been bug fixes and improvements since 2.6.1, so this might help. If you don't have 3.0 or 3.0.1, then put 2.6.1 back onto the CVS. Then I would recommend that you try a simple example program (like the ones that get loaded onto the CVS when you install VBAI onto the CVS) and add the ISO Output step in that example to see if it also gives you the same behavior. This will help determine if it is just your code or if it has something to do with the CVS or with VBAI. Then if the example program with an ISO Out step also shows the same behavior, then you can start doing some other things to debug where and when the delay is occurring. For example, you can place an overlay onto the image and update the image after every step to determine which step is really causing the delay. Even though you say it takes 4-5 seconds on the ISO Out step, it could actually be pausing somewhere else in your code, at a different step, before the ISO Out step. By adding the extra steps to display the image with an overlay after each step will help determine which exact step is taking so long.

Finally, you can send me your script, but that would be the easy way out. First, try to troubleshoot your code and the CVS by doing the above suggestions first, and then once you understand what could really be causing the delay, then I can go ahead and take a look at the code for you to see if I can reproduce the behavior. Let me know if you have any questions along the way. Thanks, and have a great day.

Regards,

DJ L.

[scott_7723]

That is a great idea...displaying after each step...I will try that.  I will also try the samples and add the ISO Out option to it.  Thank you very much for your reply.  I do have VBAI 3.0 as well, however, I had issues with updating my existing codes not working properly.  Unfortunately for me we run 4 of these systems daily where I am at and I rarely get an opportunity to tinker with it for an extensive amount of time.  We rely on these systems to run all parts through that we make.  Little things like using the select product wasn't working when saving the old products from 2.6.1 to 3.0.1 and I had some camera lagging go on where it would literally use an image from the previous run without updating to the newer one when using multiple cameras (four cameras).  I ran into this in the past as well with 2.5 to 2.6 upgrade (and i made sure that the Wait until next image was not on for the other acquire image steps since my setup needs multiple cameras to take pics at the same time.  But yeah, I will try your suggestions first and see if any behaviors change.  Reformatting is fine too, however, the goal is to not have to re-write all of our product scripts, so if they are corrupted, then I suppose I will have no choice.  So, first things first.  Thanks again.