When setting up a visual workstation, don't jump straight into discussing protocols right from the start.

First, let’s clarify three things:

Who will trigger it, what will the outcome be, and how will the data be stored?

That is:Trigger, result, retrospective.

These three pieces haven't been unpacked yet, and later on, a certain situation is likely to arise:

The camera can take pictures, the algorithm can process them, yet the device itself is always up and down—sometimes working well, sometimes not.

Triggering link: The simpler, the more stable.

Triggers the main functions: workpiece positioning, photo capture, lighting, completion signal, and reset.

There isn't much data for this type of signal, but the requirements are very high.

It must come when it's time to come.

If you can solve it with hard I/O, don't go too far out of your way.

For multi-device communication or status reading, you can use RS-485 with Modbus RTU.

The principle is just one sentence:

Don't make the trigger link complicated.

RS-232 is suitable for short distances and one-to-one communication.

But once the cable gets longer and interference increases, it tends to become unstable.

RS-485 is more suitable for industrial environments, and a single bus can connect multiple devices.

It has stronger anti-interference capability, but shielding, grounding, terminating resistors, and A/B lines must be properly handled.

Many communication problems, in the end, aren't caused by incorrect parameters—rather, they are...The wiring wasn't done properly.

Result link: Don't just consider OK and NG.

If the only possible results are OK and NG, using IO is fine.

But as the project progresses, defect codes, location, angle, dimensions, and quantity are usually added as well.

At this point, continuing to pile on I/O becomes increasingly difficult to modify.

Few fields? Use I/O.

Use TCP for many fields.

Under the network port, the camera, industrial PC, PLC, and server can communicate via a switch.

The benefits of TCP are straightforward:

The fields are easy to extend, the logs are easy to review, and issues are easier to troubleshoot.

It’s relatively easy to tell whether the issue is that it wasn’t sent, wasn’t received, or was parsed incorrectly.

Traceability link: Don't let image storage slow down your device.

Trace the main components: images, logs, batch numbers, databases, and MES.

It's not the same as returning the results.

The result is sent to the PLC-controlled device.

Tracing is for future data retrieval.

So it’s best to keep them separate.

After the PLC receives OK and NG signals, it first processes the workpiece.

Saving images, writing to the database, and uploading to MES can be done later.

If the server is slow, you can use caching.

If the network connection is lost, you can resend the transmission.

But don't let a single failed image save cause the entire production line to come to a standstill.

One piece of advice:

First, return the results; then, trace back and proceed.

Finally, just remember these three sentences.

The trigger should be steady.

The results should be easily scalable.

Trace back to avoid affecting the beat.

Neither RTU nor TCP is necessarily better.

The key is to use it in the right place.

Before setting up your visual workstation, first clarify these three questions:

Who triggered it?

What result is being reported?

Where do we store the data?

If you get these three things straightened out, you’ll avoid a lot of trouble later on.