Large Sensor System Considerations

When designing a Gocator sensor system that may consist of many sensors, a GoMax, and/or an accelerating PC or software app, there are some lessons that we have learned from past large-scale systems to adhere to. 

Image Size

Whether you are working with an unaccelerated buddied system, a GoMax/ GoMax NX accelerated buddied system, or a GoAccelerator PC accelerated buddied system, there is some maximum storage allocation per image based on the controlling unit. Be sure that your overall image does not consume more memory than the system can store.

You may also want to consider upgrading from unaccelerated to GoMax/ GoMax NX accelerated or GoMax/ GoMax NX accelerated to GoAccelerator PC accelerated if you are approaching this limit. 

Job File Development

In many large scale sensor systems, the development of an inspection job can take a very long time on sensor because each individual change is registered and has to be synchronized with all the buddied sensors. The more sensors that you add and the more job file changes that need to be synchronized, the worse the delay due to synchronization between changes can be. This makes iterative design of the job file take a long time. 

In order to avoid the many delays due to syncrhonization, you should first try utilizing the Quick Edit checkbox in the bottom of the web GUI. Simply check the box to enable Quick Edit, then make a few changes (We would recommend to make maximum 1-10 changes at a time), then uncheck Quick Edit to sync those changes. Repeat as necessary.

If the Quick Edit option is still taking too long, then you may want to make all your program changes in the GoEmulator.exe utility. You will download your job file from the sensor system, load it into the Emulator, make the necessary changes all together, download the modified job file from the Emulator, upload the modified job file to the sensor system, and then run. 

Sensor Connections and Job File Size

When several sensors are buddied together, there is a form of connection checking between each buddy and the main sensor. In some cases with very large job files (i.e. >125 tools), a job file change to a very large job file can take so long that the communication between the buddy and main sensors would be interrupted or delayed. This can cause the main sensor to drop its buddies from the system and then try to re-buddy them to the system. 

In some cases, this can cause an un-buddying then buddying cycle in which the main sensor is stuck in this process of trying to detect, drop, and then re-add buddied sensors. This can be problematic as the job file will never successfully load, and this sequence would not be detected as a crash. It is also very challenging to diagnose.

Currently there are two developer variables, RemoteProvider.ConnectionTimeout() and RemoteProvider.TransferTimeout(), that can be increased to create a greater window within which the job can be loaded and then the buddy-checking communication resumed such that the timeouts are not reached and the cycle not entered. Please contact the LMI support website or your LMI AE/FAE for assistance if you think this may be necessary for your system. 

One warning about implementing greater timeouts is that in the case of a true loss of communication with a buddied sensor, that loss of communication would not be registered until either timeout is reached. It is not recommended to change these values from their respective defaults unless it's deemed neessary. 

A similar timeout may be necessary to load these large jobs in an Emulator. 

Network Bandwidth and Hardware Selection

Large sensor systems can generate a lot of data very quickly. It is smart to check that your network architecture can handle the type and quantity of communication that you are planning to transmit.

At the time of this writing, the Gocator family supports Gocator TCP, Ethernet/IP, PROFINET, Modbus TCP, and ASCII over Ethernet ethernet-based network protocols. While the Ethernet/IP, PROFINET, Modbus, and ASCII protocols vary in average size, they usually are considerably lower in network bandwidth consumption and average packet size than the Gocator TCP protocol. 

If you are planning to use the Gocator TCP protocol with an SDK application or 3rd party software, you should calculate the size of an individual transmission and the frequency of those transmissions prior to selecting a network switch. 

In most cases, it is good practice to put the Gocator system on its own unmanaged 1-Gigabit-ethernet network switch. That switch should be Jumbo frame enabled for these larger transmission up to and including the IEEE standard 9000bytes of payload. 

It is also recommended to utilize the highest cateogry shielded Ethernet cables possible, and the shortest length for those cables. 

With respect to bandwidth, a quick calculation will reveal the size of the transmission. An inexact but quick ballpark figure can be calculated with the following formula:

For Uniform or Non-Uniform Surfaces or Profiles:

(Number of Data Points in Transmission of Surface or Profile) * (2 bytes per point) = (Surface or Profile data size)

For Intensity image:

(Number of Data Points in Transmission of Intensity image) * (1 byte per point) = (Intensity image data size)

Other data types can also be transmitted and they add to the size of the transmission, but that quick calculation will get you close to the transmission size.