- Make sure to assign your device names properly
- I/O display update rate: the default is 32ms and should be equal or above the device update time set in the project
- NIC selections can be saved by selecting the option from the options menu
Frequently Asked Questions
This usually means that the XML File in use by PROFINET Commander can’t be overwritten. If you are compiling, shut down PROFINET Commander prior to compile or copy the XML file to a different location each time (ex: Desktop)
This means that your TIA Portal configuration is invalid or you are using the wrong file type. Typical reasons include not putting the device in the configuration and attaching to the controller, only the controller. Or another reason might be that you are importing the wrong file (for example a device GSDML file) instead of an actual configuration file. If you still have trouble after checking these items see the manual for a configuration example or contact support.
Double-check the dependencies from the installation section (especially Npcap for V184.108.40.206 or higher, or WinPcap for V220.127.116.11 or lower). Try to restart your computer and check again if problems continue.
No, connecting to a monitoring port on a switch causes duplicate frames to be sent to the driver and this can cause communication issues. A switch port monitor is not supported at the same time. Disable any monitor ports on the switch prior to running PROFINET Commander.
Make sure you have set the controller to operate mode. Check that the name has been set and you can see the device with the PN browser. Note that the configuration tool “display” name and device name may not match. You can see what the actual name should be by clicking on the device in commander and viewing its properties or looking in the engineering tool at the PROFINET device name setting in the devices properties. Try to set the update time to the slowest value in the engineering tool (512ms). Also ensure that there is no firewall/antivirus/malware scanner on the PC which could block the communications (port 34964 and Ethertype 0x8892 should be possible). Usually Windows Firewall is OK, but if there is another firewall it should be disabled or an exception set. Check that you have selected the right network interface for communications.
See if alarms window shows any information. Check that you have configured the device and modules properly with the correct fw and revision. Highlight the device and under read/write record read the diagnostics (0xF80C) to determine the error (or see alarm info). Also you can see the module diff block record (0xE002) to determine what modules might not be configured properly.
Check the update time set on the device(s). As Windows is not a real time OS, some other tasks could interrupt PROFINET communications at fast update times. Set the device(s) to 512 ms and try again as a test, and then you can adjust down incrementally to see what works best on your system to a minimum of 32 ms. You can also try to figure out what tasks are running simultaneously and close other programs you don’t need to see if that helps.
This can happen if there was a preexisting diagnostic prior to the startup on a device and is a known issue. Fix the diagnostic issue on the device and then stop and start the controller again to clear it. We are planning a fix in a future version.
This can happen if the GSD files cannot be found on your system in the following folders:
- TIA GSD
- PROFINET Commander GSD
- User supplied (via Options)
Make sure the GSDs for the devices are located on your system and you are running the software with Admin rights. Also make sure the GSD file name conventions are correct as it helps the tool find the correct GSDs
If you have configured a topology based system for diagnostics testing or device replacement the device is signaling an error because the PC is likely sending multiple LLDP messages (like Windows LLDP + PROFINET info) and confusing the interface. Be sure to disable other LLDP protocols under your network adapter settings. LLDP is already built into the PROFINET Commander driver.
No, PROFINET Commander only needs one license because it uses the PN Driver object in TIA Portal. This is considered a “PC Station” and does not require an additional license for TIA. TIA requires a license if programming Siemens PLC’s (like S7 1500, 1200, 300 / 400, etc.).
In some special cases, this is an issue coming from the underlying drivers when requesting the NIC information and there is no current workaround. In this case, you should try each selection where Microsoft is listed and see which card it applies to. Once you find the correct card you can turn on ‘save NIC selections’ under the options menu to save the setting.
Make sure to select a valid adapter prior to importing and starting the controller or browsing the network. If network adapters have changed in the meantime restart the software and try again. If you are using a USB adapter this may require restarting the Npcap (or WinPcap) service. Start a command prompt with admin rights and type net stop npcap then hit enter. Then once the service stops type net start npcap and enter again. (or use npf for WinPcap) Then restart PROFINET commander and try again. Make sure the adapter in question works with Wireshark as well.
To use the automatic update feature a license and Internet connection are required. The software will check the server at startup if an update exists and notify the user if so with a dialog. Another way to get the update is to manually download the latest (free) version from the website. Install the latest free version and the license will be detected and all updates activated.
A ModDiffBlock can mean multiple things. For example, it could be a mismatch between the actual device configuration and the offline configuration (fw rev not matching, missing modules/submodules, wrong modules/submodules), that the device is locked by another controller/process, or that there could be an active (in place) diagnostic. Select the device in question and enter the R/W Record dialog. Read record 0xE002 (Module Diff block for one AR) to see what modules/submodules have the issue and then correct the underlying problem. A substitute module/submodule is usually OK (probably a firmware difference, check the GSD file and versions) and the device will continue normal operation even with the ModDiffBlock; however, a wrong or missing (unplugged) module will not work until corrected. Check your configuration if a wrong module and change the device configuration or check real hardware if a module is missing, not plugged in. If a diagnostic is detected you can read diagnostics to attempt to get more info or check the alarms/info pane from the main window display. If the device is locked by another controller it means that no more than one controller has access to the device at a time, check shared device settings if trying to setup ‘shared device’ in the device configuration. Note that sometimes a ModDiffBlock may be incorrectly signaled with a device under development if the modules are not plugged into the device firmware/stack correctly. Or sometimes this may happen with gateways / proxies if they are using virtual modules or are not ready for startup.
In this case you can go under the application directory (usually C:\Program Files (x86)\PROFINET Commander) and Redistributable folder. In this folder you will find Version 18.104.22.168 which is the last version supporting WinPcap. Simply install this and run the uninstall for PNC and Npcap during the process, then the installer will ask you to install WinPcap and you’ll be good to go.