Machine Vision

cancel
Showing results for 
Search instead for 
Did you mean: 

Issues streaming in RS-170 640x480 cameras in proven and utilized LabVIEW app

My labview 2014 SP1 image capture tool has been in use for multiple years since I wrote it. It has successfully streamed and captured upon request multiple gigabytes of image files for IMAQ and IMAQdx cameras, and GEV cameras. Back in late 2015 I had a problem where connected GEV cameras no longer streamed in video. That was fixed after updating the drivers in my LV2014 install. The problem here is on two different workstations, one named grab1 the other is picasso, both were working previously, well okay, last I recall them working with RS-170 cameras was mid last year. No further NI LabVIEW updates have been installed, and these workstations are on an isolated lab network, meaning there's no outside world connection to the internet. Somehow I now have a similar problem with the IMAQ side of things on both machines and I know where it fails, and I have read other posts and did all the suggested things others tried. The two workstations both have LabVIEW 2014 SP1 and Vision Acquisition, I know MAX is v15 on grab1 and I believe v17 on picasso. Identical error -1074397153 which in short is an unrecognizable video source. In MAX on both machines the video is streaming in perfectly. I tried white and black levels, tried creating a new RS-170 camera file, and as of this morning this is consistent with 5 different manufacturers RS-170 cameras, so I cannot say it's only one model of manufacturer.

 

The issue is with the VI used to set up for a grab session, that's the one causing the error, which occurs when I tell my tool to connect on a chosen interface. I was trying to get a jpg file to attach, but so far that's on my phone and my office network seems to be dumping the file.

 

While waiting on all you brilliant people to think and reply, I am going to try a connection with a camera link camera to make sure it isn't all IMAQ camera types I work with.

 

Any ideas?

 

 

-- Bill

0 Kudos
Message 1 of 7
(2,782 Views)

Hello Bill,

 

If I am understanding the situation correctly, it sounds like you have two computers that are not connected to the internet and have not received any updates since they were last able to run this LabVIEW application.  However, this application that was previously working is now running into an error.  Additionally, you can stream from the cameras without any issue in NI MAX on both computers.

 

Since you mention that the error seems to be related to an interface, can we make sure the interface we are choosing/referencing is the same as what we see in MAX?  If it is working well in MAX, I would think that there is not a problem with the driver interfacing with the camera and it is probably something related to the application.  It seems odd that if nothing changed over this period of time that we would run into this issue, but that is my guess based on the info you have provided.

 

Also, how did the Camera Link test go?

Clemens | Technical Support Engineer | National Instruments
0 Kudos
Message 2 of 7
(2,729 Views)

Your are correct, none of my lab computers ever see the outside world, and no, there's no NI or MS updates unless I specifically download them to bring in and install. That's what makes this awkward. Usually I am the only one applying updates to my IT systems, however, our network services branch has over-ride keys and has been known to just walk into areas with known IT systems and install specific MS updates.

 

NI updates, I have done a few, and I would hope that wasn't the original trip point for all the issues these two workstations have seen, but it probably was. Both workstations are involved in many test scenarios without imaging such as temperature tests in an environmental chamber, DUT power profile, and software command and control tests prepping for the image based testing I need working now. And keep in mind, my code has not been altered and has been in use for more than 5 years

 

Last time something like this showed up was with GEV cameras which was fixed by installing drivers and a couple other updates. Then other test requirements got in my way and I most likely never got back to further test and fix imaging problems. My current IMAQ issue may have been broken for almost two years now., since that's about how far back when the IMAQdx was fixed. And I have always had issues with the way NI downloads can be managed for offline installation.

 

This morning I am going to be running more image tests with my cameras, I now have in my possession cameras needing the NI 1409, 1428, 1435, and GEV interfaces. I will go through all the cameras, and interfaces across two machines one more time to ensure I didn't do something wrong.

 

In the meantime, I forwarded to one of the NI support engineers, the two error codes I can generate, -1074397153 and -1074397163. The 163 code shows up if I leave the MAX default name in place for an interface I need to connect to, such as the PXIe 1435. On the 1435 yesterday I was able to generate the 163 error code in MAX with a camera link camera. This was with the MAX default name for the interface card which allowed even MAX to through the 163 code. With the PXI 1409 analog RS170 interface, in MAX all the camera types I have checked all stream, but in any code I have tried, of mine or example code from NI, they all result in the same error codes: 163 code if default interface name is kept, or 153 code if the default interface name is changed. In my case I was renaming the interface to 'img0'.

 

I am certain it is an update issue since multiple PXI chassis and interfaces have been tried across the two machines. So I think updating to a newer install version will makes these issues go away. And that's what I am trying on a third test computer, I downloaded the WB installer suite to update everything to the May 2017 distribution matching my license. This morning I finally got the installer to allow me to build the xml spec file. But still, when running the setup.exe, the installer wants to connect to NI and download what's already there in the same directory tree. So that's where I am stuck at right now.

 

I included a picture of the two VIs where these codes are generated. What feeds the first VI is simple, in the past connections such as 'img0' or 'cam12', which I then parse out the img and cam for other reasons. And the second VI which is what sets things up for a grab session is where the error code show.

0 Kudos
Message 3 of 7
(2,717 Views)

So I think I discovered the cause of my problems. Seems at some point backups were made which included all our custom camera files. At some point camera files look to be on the wrong machine so the interface alias name no longer maps correctly to the actual interface name or alias. In other words what should have been img0 for the 1409 ends up being img2.

 

Could also be from swapping out PXIe chassis and new one having more slots and the mix of image capture cards are also reordered.

I am also still slightly suspect of the few NI suggested updates which are not equal between the two workstations. Possibly a needed update was missed.

 

However, now that my VLA is back in place, I am opting to update to May 2017 distribution to see if all is normal again, then update the 2nd machine if first works fine.

 

Bill

0 Kudos
Message 4 of 7
(2,705 Views)

Hello Bill,

 

Thanks for the update!  That sounds like a very probably cause given the behavior and errors you have described.  Hopefully you get to test all things out and get things back in order now that you have your licensing in place.

 

Looking forward to your next update and hopefully conclusion to this mystery!

Clemens | Technical Support Engineer | National Instruments
0 Kudos
Message 5 of 7
(2,695 Views)

Yeah, it is definitely the mapping of interface names "img#" against what the actual interface is and what's referenced in the iid files. And this is layered with the new PXIe chassis and card locations in chassis being different from original iid files when they were created.

 

Guess now I need to consider doing a MAX config reset and start over, which is the part I hate the most since the MAX config export does not fully backup the config and manual editing/rebuilding of instrumentation on gpib enet boxes is always required......takes so long to put back what should be saved out when a MAX backup is created.

Message 6 of 7
(2,683 Views)

I finally got this all figured out as to how and when the special operational condition happened happened. (Yeah, I am calling it special!)

 

I had rebuilt one of my image capture IT systems, named grab1, and once all was up and running, I copied over a zipped copy of the IMAQ 'Data' directory I stored off prior to the rebuild, and overwrote the existing to ensure I had all the latest custom IMAQ camera files I created. It was further complicated by my adding to it camera files from iamge capture IT system# 2 named picasso.

 

So..... grab1 has a new PXIe chassis and cards are installed in a different order, and MAX was happy with it all until I unzipped the zipped backup of the IMAQ Data directory in place of the existing. This should not have broken anything, however, since I had also included the img0.iid through img6.iid files, this is where MAX breaks. The img#.iid files are mapped to specific interface cards in specific slots in my older PXIe chassis, they don't play nice with the new cards and chassis.

 

Some careful editing and testing was all that was required, and now it all works again. In the future, all backed up camera files will be done based on a key word at beginning of each file name.

 

Bottom lien, both grab1 and picasso are now fully functional again, although I am still constantly battling a different issue regarding the GEV IP addresses utilized with GEV cameras. Some of the GEV cameras I am required to work with, have hard programmed IP address data embedded in their attribute table, so I am constantly needing to open eBus Player and change the IP address data so I can make the cameras be seen. I have to do it this way because I cannot modify the IP data on the camera, and I need to make sure that administrator access is not necessary for running cameras. Tough restraints! If only there was a way to do the IP address remapping in LabVIEW, but I have not found it yet.

 

I will most likely stop posting to this thread since the problem is solved, unless someone has some brain storm idea on the IP address remapping.

Message 7 of 7
(2,604 Views)