basler ip camera IMAQdx error

[JeroenP]

Hello People from the forum,

Recently I started working on a new project and I stumbled on something strange. 

first of the goal is to capture images and run a skin detection algorithm on a single board RIO. a predecessor already made a running set up, but it was not fast enough for this application. In order to speed things up the first thing that came to mind was to decrease the image size. This is where the problem occurred.

I'm using a Basler BIP2-1280c-dn IP camera http://www.baslerweb.com/products/Fixed-Box.html?model=191 

it is widely adjustable with their web tool, but almost no settings are accessible with the IMAQdx vi's or in MAX. but that was not the problem the web tool works just fine.

I was trying out various images sizes and frame rates and in the web tool it works every time. but when running a simple grab program I sometimes got this error.

Error -1074360276 occurred at IMAQdx Configure Acquisition.vi

Possible reason(s):

NI-IMAQdx: (Hex 0xBFF6902C) Unable to connect to the camera.

Has anyone ever encountered this as well?

i googled the error and one of the fix suggestions was to change the static ip, but i dont belive that was the problem because it gets stranger.

To reduce the image size I used the camera's AOI( area of interest) function. I only used half the vertical size( since we have a wide angle lens and I’m not really interested in the floor or ceiling). now as I first set this it was capturing the top half of the range, this is when I got the error. it was persistent for more than a dozen times. Later on i tried to grab a band from 1/4 to 3/4 of the height. To my surprise this did succeed. I reconfigured the AOI again to the top half and the error showed again. strange stuff.

but it get stranger. On yet a smaller AOI combined with only outputting 1:2 of the pixels( reducing resolution in a manner) I got the error on all frame rates below the maximum fps of 30. again consistent.

I don’t know what to make of this almost selective error occurrence and I hope some can help me out. 

Regards Jeroen

[BlueCheese]

Are you using on of the sbRIOs with a USB port? If so, you might want to consider switching to a Basler Ace camera. This is likely to be a better fit for your application on all aspects:

- No compression of images, so your image processing can work on a cleaner image

- No JPEG decompression CPU overhead will speed up acquisition considerably

- Cameras have full functionality exposed directly configurable in MAX or via API. This is not currently supported with IP cameras (you need to change the settings via the web page and save them to the camera)

[ThiCop]

Hello Jeroen,

Most of the information concerning this error I find back seems to also indicate "IP-address" related issues.

Some questions from my side:

- Are you able to share a MAX Report from your set-up?

- How is the IP camera connected to the sbRIO? Do you have any switches/routers in between?

- Am I correct to assume that you do the grabbing via the sbRIO and do the web based configuration via your own pc?

- Are you accessing it from "two sides" at the same time?

  In other words: is the web tool open when you do the grab?

[JeroenP]

@ BlueCheese,

Switching camera has already crossed my mind but at this point the prospects are good, only the errors are strange, and the high fps means low shutter time. This low shutter time causes the camera to apply gain resulting in a more noisy image. But as a last resort a switch can still be made.

@Thierry C

At this point I’m doing the testing on the pc itself. Once I’ve completed this benchmark testing I will make the final program for the myRIO(previously the sbRIO was used).

My pc and the camera are on a router. The sbRIO is also still on that router. During testing I did the following. open the web tool, do the configurations, apply them upon which the web tool starts live view, stop/close the live view. and then i started the grab VI. the web tool remained open during testing to monitor the data transfer rate.

The final experience that made me think it wasn’t IP related was the following:

-I set the image size quite small and at 30FPS and started the grab vi, that worked.

-the next frame rate I wanted to test was the same image size at 10FPS, at this time I was too fast and didn’t close the grab vi before changing it. But to my surprise the grab VI kept running and grabbed at 10fps. 

- up on terminating this instance, I tried to start the grab VI again and I got the error I mentioned before.

*I repeated this several times with the same result every time.

what my idea about this is that at this low image( data) size and with the low frame rate there occurs a problem with setting up the connection with the camera.

PS the web tool is able to provide live view with all settings I tried so far, and using the live view and my grab vi at the same time doesn’t seem to cause problems. Other that doubling the data traffic.

Regards Jeroen

[BlueCheese]

---

@JeroenP wrote:

@ BlueCheese,

Switching camera has already crossed my mind but at this point the prospects are good, only the errors are strange, and the high fps means low shutter time. This low shutter time causes the camera to apply gain resulting in a more noisy image. But as a last resort a switch can still be made.

---

The Ace camera may have faster frame rates, but that doesn't mean you have to use them. The cameras all have fully adjustable exposure time. For a machine vision task such as what you described, I can tell you with certainty that the Ace will be a better fit in every aspect, even price. The IP cameras are more useful in scenarios like monitoring, where you want the ability to send the image to more than one system or take advantage of integrated day/night filters.

As far as the errors you are seeing with the IP camera, those do seem odd. What you are describing sounds like it should work. The one possibility I can think of is that somehow you might be accidentially configuring the stream you are using for H.264 instead of MJPEG. IMAQdx only supports the latter.

Eric

[ThiCop]

Hello Jeroen,

Thanks for the quick feedback!

Does it make any difference if you close the web tool?

Is there anything you can think of that I can do from my side to help/assist you (without having the specific IP camera present)?

[ThiCop]

Any news?

[JeroenP]

Hello Thierry,

There has been an interesting development:p.

On the pc I had no further progress and I was accepting the fact that I just had to work around the limitations. Though they are were and are still strange, they didn’t pose a threat to the project.

Now the interesting part starts

We got the myRIO last week and since yesterday I’ve been setting it up and i made a simple grab VI. ( it was a bit of a struggle since the dongle we have didn’t work so it’s on Wi-Fi now, not ideal but fine for now) the grab vi works it has a little more latency, I was already expecting that so no surprise there. But as I was messing around a bit I accidentally set one of the settings which didn’t work on the pc, the weird thing is that it did work on the myRIO grab VI. For good measure I closed the my myRIO project and tried my initial grab vi and it fail on the setting. Same error as before.

for some reason the myRIO doesn’t have the same error as the pc. it is added separately on the myRIO though. If anything I’m glad it works on the myRIO.

thanks for the assistance and kudos for the interest and help.

Regards,

Jeroen

PS. If you have any further questions or interests I’ll be glad to help you out.

[ThiCop]

Hello Jeroen,

This makes me wonder if it could just be something specific to that one pc.

If you ever have the time, then it might be useful to test with the camera on another pc.

I am curious about the reproducability of the issue.

[JeroenP]

Hey Thierry,

A small update, I asked a co-worker to run both a grab vi and the grab in MAX, and he was able to acquire images in both cases for settings in which I wasn’t. some of the differences between our machines was that I’m using LabView 2014 with IMAQdx 14.0.0 and he is currently on 2012 with IMAQdx 4.3.5. next thing I will do is down grade the IMAQdx to that version, once I have time for it.

some of the other differences I noticed: on the first image that I receive on my device it can take up to 2,5 sec for it to complete the acquisition. on his machine it seemed almost instant.

The next thing is when I leave lens cap on (meaning an almost completely dark image) I receive the same error nomather what setting I use. My co-worker could still acquire images while the lens cap was on, and of course they were almost completely black.

The other extreme is over exposure. Which occurred when I had the camera pointed at my screen. this also gave me the same error. and again my co-worker could acquire the image without any problem.

the last 2 cases make me wonder if IMAQdx 14.0.0 has some kind of "safety feature" to prevent/prohibit you from gathering this data.

In an error to remove myself from the same subnet i switched over to WIFI on my machine. I'm not sure how subnets are set up but I can imagine I would be on a different one then. even still I got the error in all the same cases as when i had a wired connection.

any further insights/ideas? I will down grade the IMAQdx as a first effort as well as try to connect the camera on a different location in the network. 

Regards,

Jeroen