multiple VBAI processes using Ethernet/IP?

[Nelson_Bridwell]

I am designing a vision system with 16 GigE cameras that will be triggered via Ethernet/IP from an Allen Bradley/Rockwell PLC.
With the current 2013 version of VBAI I can create a batch job that will launch multiple VBAI processes, where each once services a different camera.  This should work especially well on a multi-core processor.

However, I have also discovered that VBAI will not allow me to start up the Ethernet/IP server process for a VBAI process if there is also another VBAI process running the Ethernet/IP server.

This presents a problem.  How can several different VBAI processes communicate via Ethernet/IP with the PLC at the same time so that the PLC can tell each camera when to trigger?

Is there a special technique for bringing up Ethernet/IP for multiple processes?

Or, do I need to create a special communications-only VBAI process that passes messages via some other IPC techniques to individual VBAI processes for each camera?

Or... is there some type of "spawn" transition in the VBAI state diagram that can be used to invoke multiple threads that can be executed in parallel, so that each camera does not need to wait for every other inspection to finish before it can begin?

[ChristopheC]

Hi Nelson,

Yes, in Vision Builder AI, the Ethernet/IP server is "owned" by one of the VBAI instances.

I think you have a couple different options to solve this application.

I am assuming that what you were planning on doing, since you're considering using the Ethernet/IP Adapter step, is looping on a Ethernet/IP Adapter step to read the input assembly at an address set by the PLC that would correspond to the camera trigger, right? and when that register is asserted, exit the loop to acquire the image in another state?

Am I correct?

And you were planning on doing that for all instances of VBAI. The problem is that you can only use the Ethernet/IP addapter step in one of the instances.

One possible solution, that I tested and works is to use a Run LabVIEW step in other VBAI instances, to read the assembly from the instance that started it.

If you're interested, I can send you a VI that does that, that you can run using the Run LabVIEW step. If you need to write the output assembly in the other instance, it's possible too.

Other possible solutions:

1) Instead of using connected messaging (Adapter step), use unconnected messaging: the other Ethernet/IP step in VBAI. VBAI becomes the EIP master instead of being the slave and you can query tags that you create on the PLC for trigger purposes. Multiple instances of VBAI should be able to read/write tags on the PLC using that model. All you need to do is declare the PLC as a Slave device in the VBAI Communication device manager.

2) If you still want to use VBAI as the Ethernet/IP slave, the one instance that starts the server can monitor the different assembly addresses that correspond to the camera triggers and communicate with the other instances of VBAI using the TCP/IP step for example.

3) If your GigE cameras support action commands, the most elegant solution, would be for the PLC to use action commands to send network trigger to the cameras. This solution would be the most efficient as it does not involve polling.

4) If your GigE camera support action commands, still receive the triggers using Ethernet/IP with the one VBAI instance that starts the server, and this instance can generate network triggers to trigger the other cameras.

5) If it's possible to change the communication protocol, use Modbus TCP instead. The Modbus TCP server in VBAI is a separate process that is shared accross the different instances of VBAI and all instances can read and write the Modbus registers. This is probably how we should have implemented the Ethernet/IP Server... instead of restricting it to one instance.

Hope this helps.

Please let me know if you need assistance implementing any of the solutions I mentioned and I'll be happy to help.

Best regards,

Christophe

[Nelson_Bridwell]

Christophe:

Thanks for your very thorough reply!

If I want to limit this effort to VBAI then it sounds like I should either use (1) unconnected EIP or (2) set up a communications VBAI process.

For communication between VBAI processes, would it be possible to just use system variables rather than TCP/IP to pass Ready/Done/Trigger/Heartbeat flags?

In that case, I could also set up a VBAI display process that just shows the most recent images from system variables for those images from the inspection process.

So there might be 1 communications process, 16 camera processes, and 1 display process!

Another approach would be to dive into Labview/VDM, but someone mentioned that I would need to do all the I/O.  Not sure exactly what that means, because I am sure that it must support EIP standards...I assume that Labview would permit event programming (wait for trigger) so there would not be VBAI polling of flags, which might be more CPU efficient.

  Nelson

[ChristopheC]

> If I want to limit this effort to VBAI then it sounds like I should either use (1) unconnected EIP or (2) set up a communications VBAI process.

Actually, if you want to keep using the Ethernet/IP adapter, I would recommend using the Run LabVIEW solution I described, and I can send you the VI that you can call to read the Ethernet/IP assembly in the other instances of VBAI.

This way, you would not need to necessary communicate between the different VBAI instances. Simply implement the same polling you would have to do to read the EIP assembly to detect the trigger.

> For communication between VBAI processes, would it be possible to just use system variables rather than TCP/IP to pass Ready/Done/Trigger/Heartbeat flags?

Yes, shared system variables is a simple way to communicate between different VBAI instances, but it might not be the fastest.

> Another approach would be to dive into Labview/VDM, but someone mentioned that I would need to do all the I/O.  Not sure exactly what that means, because I am sure that it must support EIP standards...

LabVIEW has an Ethernet/IP toolkit (that we use in Vision Builder AI) that you would need to buy to implement the Ethernet/IP communication in LabVIEW.

Yes, LabVIEW supports event programming, but in your case, since the trigger is not actually a hardware trigger, but the PLC setting a value in the EIP assembly, you would still need to keep reading the assembly for that specific address change to detect the trigger if you go that route.

[Nelson_Bridwell]

I ran some testing using System variables, and it looks like the latency for passing a boolen flag between two VBAI processes is about 1 ms, which for triggering inspections from a PLC sounds entirely acceptable.  (I had to check Publish on Network to get this to work, even thought all the VBAI processes were running from the same Windows session on the same PC.) 

In addition, I ran a test with 4 VBAI inspection processes each reading an image from a file, performing a simple inspection step, and writing the resulting current image to a system variable at about 10 iterations per second, each, and all being displayed by a UI VBAI process that just displays the most recent image from each inspection process.  The image display update rate appeared instantaneous, with 4 iamges at 10 fts/each.  So this part of the problem will also work.

So, it appears that with system variables it is possible to perform multi-taskiing in VBAI, although it would be even better if the system variables were accomplished via shared memory rather than invoking any network i/o overhead.

And I will investigate Labview, which I suspect would be a more robust solution in terms of startup and shutdown, not having to worry about missing processes, etc...

[ChristopheC]

A trick is to use Modbus to share data between the different VBAI instances instead of shared variables (for data other than images).

The Modbus Server is implemented using shared memory on Windows, and you should get much faster performance than using system shared variables.

Simply start the Modbus server on the main instance, the use the Modbus step to write a register in one instance and to read that same register in the other instances.

Christophe

[Nelson_Bridwell]

Thanks!  I will definitely give ModBus a try!

Modbus Serial?  Modbus TCP?  Any special options?

[ChristopheC]

Modbus TCP.