Communication with National Instruments VBAI

PAC Project
1

National Instruments has a machine vision program called Vision Builder for Automated Inspection that offers many of their vision inspection features at a fraction of the full LabVIEW+Vision Module development system cost. In practice, VBAI runs best when it is on a dedicated computer, so that its resources can be focused on image processing and analysis. The results of the image processing would be useful inputs into an Opto22 strategy that controls the equipment on which the vision inspection system is installed.

VBAI offers the following methods to transmit information to another device or program:

  • You can use IO lines, if you have a DAQ card.

  • Standard TCP or Serial communication using the TCP or Serial I/O step)

  • Ethernet/IP (VBAI 3.6.1 support unconnected messaging)

  • Modbus

  • Serving data using OPC

My strategy is running on an R1 controller with a 16 module rack that is not yet fully populated. I would like for it to be able to send basic configuration infomation to VBAI (part number codes, on/off commands), and also read the results of the inspections (some discrete, some values).

The DAQ card option is probably the fastest and simplest, although the DAQ would have to be NI brand to be recognized by their software and used properly. Sending more than 2 channels of analog data by this method would get very pricey.

OPC would be relatively fast. VBAI’s preferred case would have it function as the OPC Server, and Opto22 as the client. Is that possible? Based on what I’ve been able to determine from the online resources, PAC Display can only function as a client to an Opto OPC Server. With OptoOPCServer software, it might be possible to talk server to server, but that will incur software costs on both sides (Opto and NI).

I’m not sure how I would use Ethernet I/P to communicate, leaving direct serial or TCP, or Modbus. The advantage of Modbus is that the data persists in registers even if the message is lost. The strategy would act as the master and VBAI the slave. The VBAI registers can be read or written to as needed by either application, without worrying about whether or not the data is needed at that moment. By having a defined register for each tag, it is possible for PAC Display recipes to reliably control VBAI parameters.

As an added bonus, multiple instances of VBAI can be open on the inspection machine (distributing the machine vision CPU load), and they all share the same Modbus registers. This allows the instances to talk to each other, as well as to the Opto controller.

The Modbus integration kit will speed up the programming for this considerably. Thanks for making it available.

Jason

2

FYI Jason, re: Modbus integration kit is rather large, here’s a smaller sample that might help get you going:
http://www.opto22.com/community/showthread.php?t=321&page=1

Sounds like TCP is your best bet, not sure what (besides Modbus) you might use over TCP – is there some other protocol that’s well documented for this? The Modbus commands are pretty simple and there are lots of tools to help debug, also our PSG team knows it well too. Guessing that’s your best bet. Happy coding!

3

I think TCP could be used without the Modbus structure, in the same way that serial commands can be done with or without Modbus. Once the TCP comm handle is opened, the VBAI software I am using gives the ability to watch and manage the TCP communications buffer on its end, similar to the control I would have with an Opto chart on the other end. I could send some kind of command code like “*S”, and VBAI could be watching the buffer for that command and take action when it receives it.

Really, though, Modbus is a much better approach for what I want to do. Having persistent data in registers is a more robust way for the two applications to talk. Between the Modbus Integration Kit and the WattNode example, which was happily coded to support TCP even though WattNode requires RTU, I should have enough examples to make this work.

4

For the rare someone who might stumble onto this thread and be doing something similar, one complication with VBAI is that the modbus server loop rate is fixed by default to 200 ms. There is a discussion on the NI forums about how to change this setting if you would like to communicate more quickly.