Ethernet camera

[Greg McKaskle]

Can LV do HTTP? Yes, though you will do it over TCP with a bit of string formatting and parsing.

If you choose to go this route, any enet camera should do. All we've looked at use HTTP to initiate the communications and change params. Some camera vendor's have good documentation on their web site, others were reverse engineered using wire shark.

By the way, doing this on a PC and later taking it to the cRIO should transition easily.

Greg McKaskle

[Daniel_LaFleur]

Originally Posted by Greg McKaskle

Can LV do HTTP? Yes, though you will do it over TCP with a bit of string formatting and parsing.

If you choose to go this route, any enet camera should do. All we've looked at use HTTP to initiate the communications and change params. Some camera vendor's have good documentation on their web site, others were reverse engineered using wire shark.

By the way, doing this on a PC and later taking it to the cRIO should transition easily.

Greg McKaskle

Thanks Greg for all your answers and patience.

Can LV or NI Vision parse frames from MJPEG for image Recognition?

[Greg McKaskle]

Originally Posted by Daniel_LaFleur

Thanks Greg for all your answers and patience.

Can LV or NI Vision parse frames from MJPEG for image Recognition?

Yes, but not nearly as well as they will in a few months. The current code for loading JPEGs and MJPEGs expects them to come from disk. So, you can make it functional, but not performant.

Greg McKaskle

[kamocat]

Let me just make sure I interpreted that correctly:
One of the things NI is currently working on is a VI to convert live video from an ethernet camera into a picture data type that will give the current frame whenever requested? (And this VI will not be locked, so we can actually see how it has been done?)

[Greg McKaskle]

The few months wasn't meant to imply we are still working on it, but rather when it will be delivered.

As for locking VIs, the JPEG convertor will in fact call into a C++ library because that is what the kernel of the imaging library is written in. The networking layer will be done with native LV functions, and all of the new VIs being written for FRC are unlocked and open source.

There will be some locked VIs in vi.lib, same as there are in regular LV. The reasons for locking them tend to involve submission for patents. There will also be many many example to rip into.

Greg McKaskle

[kamocat]

Cool. I had just run into some silly stuff like color to RBG being locked.
Thanks, it sounds great!

[Greg McKaskle]

Originally Posted by kamocat

Cool. I had just run into some silly stuff like color to RBG being locked.

That is pretty silly. That VI calls back into a LV entry point, and unless that sort of thing is locked down, people will start calling into it as well, but without the wrapper, the parameters may not get conditioned -- leading to crashes. And if/when we change the interface, we can also change our wrapper to match. If other locations are calling the interface, we have to honor the old interface as well or break their code.

Anyway, the reason the color stuff has to call back into LV is for the symbolic colors. The LV color picker and managers tap into the OS colors such as Window BG, Text FG, Text Selection, etc. That color lookup is the primary thing that the callback into LV handles.

Greg McKaskle