NI Vision Builder vs. LabVIEW RT + NI Vision Assistant

[janCZ1]

Hello

I’m designing a vision application which should be able to run stand-alone (EVS-1463RT). The app will have up to 30 inspection states (read gauge value, checking for the presence specific objects, etc.) approximately. The second requirements are the communication ability with other devices not NI via TCP/IP and logging pictures in FTP.

Now I’m thinking about the two possible solutions.

1.        Create an AI with NI Vision Builder
2.        Create LabVIEW RT app and with using NI Vision Assistant build inspection states
   
   

A have to say that the first solution is not my favorite because I tried to implement the TCP/IP communication in NI Vision Builder and it was function but the using of the server is limited. In the other hand the building the inspection is “easy”.

The second solution has following advantages for me: better control of the app, maybe better possibility to optimize the code, implementation my own TCP/IP server. My biggest concern is the using NI Vision Assistant to generate the inspection states.

In conclusion I have to say that I’m not experience in the vision app but the LV RT is no problem for me.

Thanks for any opinions

Jan

[ChristopheC]

Hi Jan,

> A have to say that the first solution is not my favorite because I tried to implement the TCP/IP communication in NI Vision Builder and it was function but the using of the server is limited.

Could you give more feedback on this point? What do you mean by "using of the server is limited". More precise feedback and suggestions would help us improve the functionality.

What I would recommend you look into is the use of the VBAI API. You can find examples in <Program Files>\National Instruments\<Vision Builder AI>\API Examples\LabVIEW Examples

This features allows you to run VBAI inspection within your LabVIEW application, an retrieve results that you can send using a TCP implementation of your own in LabVIEW, without having to use the VBAI TCP functionality.

You retain the configuration feature of the Vision part of the application, and can add extra code in LabVIEW.

The API functions allow to basically open an VBAI inspection file, run it synchronously or asynchonously, and retrieve images and results.

As you mentioned, the other solution is to implement your state diagram in LabVIEW and use the Vision Assistant Express VI in different states. What VBAI give you that Vision Assistant doesn't is the pass/fail limits for each step (and the state diagram).

Best regards,

Christophe

[Brad]

If you don't want to use a PC, I don't think the API idea will work since this currently requires a PC to control a VBAI inspection running on an EVS (i.e. API can't currently run on RT targets). I would either:

1. Get VBAI to work on your target. You can use Run LabVIEW VIs to call your own custom LV code, and if you have problems with the TCP step in VBAI, let us know because maybe there's another way to accomplish what you want or maybe we need to fix something, but hopefully you can get the built-in TCP Server of VBAI working because this would be the easiest solution if it works for you.

2. It sounds like you have several discrete Vision inspections, so maybe implementing this in LabVIEW and using a Vision Assistant Express VI for each visual inspection with a state diagram (Loop with a case structure) in LabVIEW might also not be too difficult.

I would try to get the TCP issues resolved in VBAI and ask if you have problems and if that doesn't work in parallel you can also try a simple version of the LV only approach and see which you think would work better.

Hope this helps,

Brad

[janCZ1]

Hi Christoph,

Thank you for your answer.

About the TCP/IP server: I need to implement communication between EVS and the other real-time system (not NI). Actually I need to control the EVS from the other system. Send the control word to EVS and based on this control word to execute an appropriate inspection. The EVS should be able to send the result of the inspection back to the system as well

I have tried to implement this feature and I was successful but it was necessary to send fix length 1024bytes otherwise the server did not function properly. It was a little challenge to find this feature because I had to generate a LV code from VBAI and read how it functioned.

I was worried about a next ‘hidden feature’ of the server that was a reason why I thought about implementation in LabVIEW.

Best Regards

Jan

[Brad]

Hello Jan,

The TCP step in VBAI can read a fixed number of bytes, but it can also look for termination characters. If you know your message to VBAI will always end with a particular sequence of characters that won't be anywhere else in the message, you could use this stategy to read a variable length message as well. Did you try this? If so, why did this not work for you? You can even use non displayable characters by selecting the "Display" option of Hex.

Hope this helps,

Brad