CVS camera disconnects and causes reboot

[Brad]

Here's an explanation of how VBAI and MAX work with RT targets like the CVS:

In VBAI, we try to expose all the settings you have in MAX so you don't need MAX. When you are editing the step or clicking around on steps we use the same remote calls MAX does to set attributes and acquire images. The reason users may run into issues and need MAX to fix things is when the camera is in a bad state and the initial settings configured for the camera are not valid. MAX may handle this case better than the Legacy 1394 step in VBAI. We have put work into the IMAQdx VBAI step to try and handle this better so users can fix the settings in VBAI without needing MAX, but I haven't come across 1394 cameras in a bad state on the CVS that would make it possible to debug and add the same type of fix to the legacy 1394 step in VBAI. Once the camera's initial settings are good and saved in the camera file on the target, the legacy 1394 step in VBAI can correctly open and configure the camera and things should be fine in VBAI now.

The reason some users may see a difference between editing and running the inspection on the target is that we use remote calls when editing and clicking around in the inspection, and when you run the full inspection, that's when the code actually runs on the target and we use the standard 1394 API to acquire images on the target and then use a RT FIFO to make those acquired images and results available so the host can read them and update the image displayed on the host. There shouldn't be any difference between making the calls using remote calls and running the acquisition on the target and streaming the resulting images back to the host, but it does go through different code paths, and so if you do see differences, it may have to do with timing because running on the target may not be able to execute the inspection as fast as running on the host with remote calls to the target to acquire images or set attributes, and some cameras may behave differently when these remote calls occur faster than when the code is executed on the target using the regular 1394 API instead of the remote calls.

In my experience, a lot of the "voodoo" that can happen with cameras on RT targets usually is a result of cameras having very specific timing and behaving differently depending on how fast operations with the camera are called or having incorrect settings that make the camera behave in weird ways.

[MartyP]

The two drivers definitely work differently and you don't have all of the same options for changing camera attributes with both drivers. Some attributes can only be set thru MAX. Mike was right about it being just short of voodoo. There are certainly still issues with VBAI which havn't been answered yet. It could be that once the camera attributes are set correctly it should acquire images without issue. If this is the case then the values that need to be set should be made available so that we don't need to figure it out by trial and error. I was under the assumption if I purchased a camera from your list of approved imaging devices that all I would need to do is plug it into the CVS and program my inspection. It is a little more complicated than that.

One other thing I would like to know is if I were to create an inspection in Labview to run on the CVS, would I still need to use the Legacy Driver?

MartyP

[ChristopheC]

Marty,

> One other thing I would like to know is if I were to create an inspection in Labview to run on the CVS, would I still need to use the Legacy Driver?

No, if you're programming a CVS with LabVIEW, you can choose to install the dx driver on the CVS and it will work fine.

-Christophe

[Hony2]

Hello MartyP,

I fully agree with You, I am not happy with the NI support in case of some issues. NI is suplier and standard way in my company(automotive) in case of issues on suplied equipement is to call suplier to make list of issues with action plan with timing of actions to remove bugs or issues. I am going in case of NI against standards I spend lot of private time to investigate to think, because I was pushing to use CVS because of facing to shutdowns of line computer with TestStand and VBAI together. So the only way for me was to make new investment to CVS. Time to time we have problems, but very hard, finally it increase scrap on the line people stop to work and the only possibility is to share problems (Got bless it, I am happy that I am in contact with people like You, skilled, with logical thinking.), with other people with same problems. Anyway it is looking litlebit like psychotherapy (I feel that I am not alone), but there should be something systematical from suplier side to solve the issues quickly to avoid any other investments. To buy industrial equipment is not the same like to buy a toaster. I would like to see something constructive from NI side, because now I see that they know that st can happend, but they are not involved enough to spend time with FTA for failure to explain 2 hours breakdown of line to my boss. Then even I think that CVS is really great, I will start to think about to sell it back to NI and to replace it by additional system, but from another suplier. I think that market is full of similar units.

Have a nice day

Hony

[MartyP]

I don't think the people at NI understand the world of manufacturing. Downtime cost money, and once you commit to a process you can't simply stop doing it. If a vision system goes down you either stop production or visually 100% inspect. Both are expensive. As for NI support, I think it could be improved although it isn't as bad as some other companies. You will probably get more helpful information on the discussion forum than from the engineers at NI. Even with the problems I've had I still think the CVS and firewire cameras are the best vision solution on the market. However, Mike was right about the complexity of interfacing everything being rather mystical, and discouraging to new users. There is a huge learning curve and it's not quite as simple as plugging a printer into your USB port.

This probably isn't the right place for this post, but here it is

MartyP

[mvonstein]

I'm also an industrial user and agree with the last 2 posts.  From my experience, NI support people genuinely try, but are also hampered by these underlying, systemic issues.  I think they experience many of the same strange things we do, and like us, have no good way to explain it.  The other thing that really upsets me is paying for support for these systemic issues.  I can see paying for support for programming support where education on basic functionality and learning are involved, but I shouldn't have to pay to get support for basic issues that should not even be issues (regardless of whether they happen within 30 days from purchase or not).

It makes me look pretty stupid to management when I spec/buy these units, but then can't logically explain why it takes days to set them up or hours to recover from some unexplained hardware/system issue.   Furthermore, when I can't even say for sure, what the problem was that caused it. That said, they are happy with the quality of the inspections and the low false NG rate which I can achieve using NI's functionality.  I think the raw functionality of the NI software is awesome, but due to all the other issues involved with setup/maintenance, I will only use them for applications where I definitely need that functionality.  Otherwise, Keyence, Banner, DVT, etc are good enough.  If NI could match the ease of setup and operation of those units, I would barely even consider anything else.

Perhaps, part of the issue is that, traditionally, many NI customers are from laboratory-type settings where it's expected to have to tinker with things a lot and time doesn't have such a high cost?  In other words, you don't have a bunch of workers standing around producing nothing, yet getting paid while waiting for the production line to be fixed, then having to work the weekend on OT to make up the lost production.

Thanks, 

Mike 

[MartyP]

It's obvious I'm not the only one with NI support issues. I hope someone from NI addresses these concerns.

Getting back on track, it sounds like Hony is still experiencing problems with his cameras faulting out. We havn't had this problem since we started using AVT Guppy cameras. I realize this is an added expense but it is cheaper in the long run than having problems every other day. These cameras are about as inexpensive as you can get, and have no higher function processing. There are some camera attributes that need to be adjusted to make them work properly, and you probably need to connect directly to your computer to do this as you can't adjust them through VBAI. You will need a firewire port on your PC to do this. You also need to remember you are using the Legacy driver and you can set this through MAX or your device manager on your PC.

Marty

[Hony2]

Back on track, very probably You are on a good way, but my solution with hub was working 5 months.

How long do You test new cameras? I will try to find some people who offers cams in my country to be prepared, but in my case it is only part of investment, seccond part is to change them and to modify all inspections on all lines and it is why I will try everything include to try to develope new driver for CVS. Sumary 40 cameras and 6 CVS include spare one. For change of inspection You need deep knowledges of concrete product and test sequences. My estimation is 16 hours of expert per line with ofcourse big quantity of real parts with all known variations. Now You know why I posted what I posted. It is 9:00 pm here. Nice day

[Brad]

I will look into adding the ability for the legacy 1394 step to reacquire a connection during an inspection if a camera is disconnected...this is how the IMAQdx step works. A work around for the current VBAI to get the inspection connected again without rebooting the CVS is to detect this problem case in the acquisition step, switch inspections (using product select) to a simple inspection with the 1394 cameras you want to acquire from. This will initialize a new connection with these cameras and if all the 1394 cameras can acquire, then you can switch back to the main inspection since all the cameras are connected now. If any of the cameras are still disconnected and the acquisition fails, switch inspections to another simple inspection (can be exactly the same as this one, but named differently). This way, you can ping pong between these simple inspections, and keep trying to open new connections until all cameras are connected, and then you can switch to your main inspection once all cameras are connected again.

Sorry for the pain of the current work around, and hopefully the next major version will make this easier.

Brad 

[Hony2]

Hello Brad, I do not know what to say. Thanks. I am crossing my fingers. Jan