Specify the controller as well as the network
A request for “EtherCAT support” or “PROFINET support” does not describe a complete integration. Record the PLC or motion controller model, firmware, engineering software and intended drive functions. Distinguish cyclic commands and feedback from parameter access, diagnostics and coordinated motion. A network name is the start of a compatibility discussion.
Identify the exact communication option
The INVT GD350A official product page describes optional communication expansion cards. This is a useful example of why a series-level protocol list must not be interpreted as hardware included in every quotation. Ask for the card part number, compatible drive frame, supported firmware and whether commissioning accessories are included. Treat each option as a separate item in the agreed configuration.
Separate physical connection from supported behavior
A link indicator demonstrates a physical connection, not successful machine control. Define the commands your application needs: enable, start, stop, speed or torque reference, actual speed/current, fault acknowledgement and diagnostic information. For motion applications, add the required operating modes and synchronization behavior. Do not assume that every function in the controller's library is implemented by the drive.
Agree on an acceptance sequence
Begin with a saved parameter set and an identified software version. Verify device discovery and configuration, then confirm command and feedback scaling. Continue with direction, stop behavior, fault reporting and restart conditions in an appropriately controlled commissioning environment. Record expected and actual behavior for each step so a successful demonstration can be repeated on the delivered configuration.
For example, a hypothetical test record might require a commanded speed to agree with the returned engineering-unit value and a simulated communication interruption to produce the previously agreed stop response. The correct response and acceptance tolerance must come from the machine's engineering requirements; the directory does not prescribe them. Capture logs and configuration files as well as screenshots.
Ask for a useful PLC connection report
The report should identify both devices, firmware, option cards, project files and the date of testing. It should explain which functions were exercised and which remain untested. A photograph of a running motor or an online status screen cannot establish all required modes. Where a supplier provides a sample project, confirm licensing and whether it matches the intended controller revision.
Keep ordinary control and functional safety separate
A standard stop command and a safety function have different purposes and evidence requirements. Do not infer a safety rating from the presence of a network connector or a software parameter. Ask for the relevant hardware configuration, manufacturer documentation and validation requirements for the actual safety architecture. Safety integration requires application-specific assessment.
Put the configuration in the purchase scope
Include the drive model, communication option, firmware constraints, required files, tested functions and commissioning responsibilities in the inquiry. Ask whether a replacement unit can be restored using the supplied backup. Record any differences between the demonstration unit and the offered unit. An explicit configuration makes later comparison and troubleshooting much more useful than a generic “protocol supported” claim.
References & scope
This guide supports sourcing discussions. Confirm final sizing and installation requirements for the exact model.