Machine Vision

cancel
Showing results for 
Search instead for 
Did you mean: 

cvs 1456, VBAI 2.5 and ethernet issues

I have four CVS1456 vision systems running and have recently been getting a rather serious issue.  One of these systems is no longer allowing me to communicate with it nearly as fast as the others, if at all.  Basically, when I try to access it using VBAI it will start to communicate, then freeze up or drop the connection all together.  All of the settings are the same as the other three vision systems, including baud rates, the advanced ethernet settings and password protections.  I have checked the jack it plugs into for our network, replaced the ethernet cable with a new one, even hooked it up using the same cable used for one of the fully functioning CVS' to one of the jacks that has had no problems.  Same result.  Super slow retrievals, if at all.  Has anyone else experienced this problem?  Is there anything else I can do to solve this.  The pins on the ethernet connection to the CVS all appear to be ok... no bent wires.  When I hook up a crossover cable to it and use a laptop at the site, it is rather slow there too compared to all the other CVS', however, it doesn't lose the connection.  I don't get it.  What can I do about this?  Thanks for any input.

Message Edited by jimbonic on 12-19-2005 10:46 AM

0 Kudos
Message 1 of 13
(4,635 Views)
Hi Jimbonic,
Have you upgraded the OS and reformatted the compact flash?  If not, follow the KB (link below) to do this and let me know if you still have the same problem.

http://digital.ni.com/public.nsf/websearch/81B64C58139B2DA286256E45005B3C07?OpenDocument

If you have already done this, what is the serial number and version of the 1394 driver that is installed?

Happy Holidays!
Brooks W.
National Instruments
0 Kudos
Message 2 of 13
(4,601 Views)
This is Jimbonic, thank you for your input.  Yeah, I have the most up-to-date bios on the CVS (v.10.3).  Should I really bother reformating it again?   The software installed is: NI-IMAQ 1394 external drive support is 1.2.1, and NI-IMAQ for IEEE1394 RT 1.5.2. 
0 Kudos
Message 3 of 13
(4,593 Views)
Hi Jimbonic,
Have you reformatted since you started having these problems?  If not, then I would reformat again.  If you have reformatted then I will escalate this issue to R&D.  Please let me know.

Best Regards,
Brooks W.
National Instruments
0 Kudos
Message 4 of 13
(4,583 Views)
Yeah, I went ahead and reformatted it and it still is extremely sluggish.  I tried plugging it in via the other cvs network jacks that have always retrieved data with ease, and still sluggish.  Interestingly, using a crossover cable on site has become much faster to transfer to and from.  I plugged in one of the other sytems up to the network using the same cable and jack as the one giving me trouble and no problems.  Also, when I reformatted the compact flash drive and then reinstalled the software, and reinstalled my product files (inspections) the images being taken have switched.  I use two cameras for the majority of my inspections and have discovered that the the images which should be coming from the left camera is now taken from the right.  Furthermore, since I have your attention, with all the CVS' (we own four), I have discovered that every time I transfer one inspection to another CVS, I have to open it in config mode and change the Acquire Image steps due to the fact that the cameras have different serial numbers(?).  Not sure why, but that is what I figure.  This is a bummer, but it gets worst.  Every time I transfer one product inspection to another CVS and go to change the acquire image steps (the first steps of my inspections; usually two) the list shows up with the cameras (Bassler 622f) that are plugged into the CVS via IEEE1394, but the format drop down list is almost always blank.  When it isn't blank (which usually takes a reboot to get to) I select the one I need to use (Format 7) and I get an "Unknown Error" message.  This happens every time.  Then the VBAI stops responding, and I have to close the program and reboot the systems.  When I go into Measurement and Automation first, and select remote target, and click on the cameras, I can select the Formats with out any problems.  But when I open VBAI (which I've uninstalled/reinstalled from host computers) it still does this.  This is a major problem for me since I work in a manufacturing environment where minutes are critical.  Lastly, 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 nearly 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.
 
1). The ethernet/network of one of my CVS' is still extremely sluggish even after reformatting.
2).  Is there a way to trick the CVS' into thinking that the left camera is the right so I don't have to change every acquire inspection step via the software?  Swapping the IEEE1394 ports doesn't work.
3).  Why are there so many errors when I transfer one product inspection to another CVS?  All of the vision systems are wired the exact same.
4).  Lastly, why is it taking so much longer to send a signal through the 37-pin connector when in inspection mode vs. configuration mode and benchmarking?
 
I am very sorry for the length of this, but these are very serious problems for us that we hope can be cleared up promptly.  Thank you so much for your support.
0 Kudos
Message 5 of 13
(4,558 Views)
Hi Jimbonic,
Thanks for contacting National Instruments.  We want you to be successful in your application and will help troubleshoot these issues.  I will not be able to address all the issues that you mentioned in your last post.  Please create individual posts for issues 2, 3, & 4.  Creating a new post for each issue allows us to be more organized and give you better support.  I will help you with the first issue that you discussed.  Other engineers will help with the other issues.

Yeah, I went ahead and reformatted it and it still is extremely sluggish.  I tried plugging it in via the other cvs network jacks that have always retrieved data with ease, and still sluggish.  Interestingly, using a crossover cable on site has become much faster to transfer to and from. 
Can you quantify how much faster the crossover cable is?  Is it as fast as the other CVSs?


I will go ahead and escalate this issue to R&D and post back when I get a response.  To set expectations, there are many people out on vacation over the holiday so it may take a while to get an answer but I will get an answer as quickly as possible.

Best Regards,
Brooks W.
National Instruments

0 Kudos
Message 6 of 13
(4,518 Views)
Hi Jimbonic,
I've spoken with R&D about this issue and there have been some CVSs that have faulty ethernet wiring.  The typical symptom for this is rebooting.  Have you noticed if the CVS is rebooting?  You will need to pay attention to the LEDs on the outside of the CVS to determine if it is rebooting.  This could explain why the connection to the CVS freezes or is dropped altogether.  Also, when did you purchase the CVS and has it always had this slow transfer rate?

Best Regards
Brooks W.
National Instruments
0 Kudos
Message 7 of 13
(4,513 Views)
Are you suggesting that the entire CVS reboots? Or just the ethernet portion?  I ask because we have them linked to a display monitor at all times in which when it reboots you see everything reboot (like an older desktop computer does).  Also, the inspection counts have been matching what our presses have, so I am confident that it is not rebooting the entire system. 
0 Kudos
Message 8 of 13
(4,473 Views)
Hi Jimbonic,
Happy New Year! 

The entire CVS would reboot.  Are you sure that it has not rebooted?  Also, when did you purchase the CVS and has it always been this slow?  Do you have a serial number for the CVS?

Regards,
Brooks W.
National Instruments
0 Kudos
Message 9 of 13
(4,470 Views)
Well, the main reason I do not believe that the system reboots is because we run them 6 AM to 3:30 AM every day.  When the systems reboot, it will not retain the inspection statistics.  We run 30,000+ parts a day through these systems and the counts have always been right on with our press counts.  We got the CVS1456's around March last year.  I can get the serial number a little later.  As far as always being this slow...no, it was fine for the first 4 or 5 months, maybe.  
0 Kudos
Message 10 of 13
(4,454 Views)