Profinet Xml Viewer
Marika Posley
The reason your scan did not work is that they use an ARP broadcast message to find those devices. That type of network packet cannot traverse a router however which is why your scanning did not work.
For finding IP addresses, I use a software called AngryIP Scanner (not an HMS product) which works by pinging all IP addresses in a defined subnet and then finding their name based on the response.
Thank you for the information so far. I was able to scan using TIA Portal. However, when I have the broadcast forwarding option enabled I am not able to go online with the PLC. Also, I am still not able to change the name of a device. Any more on this?
You can try use this software directly form your customer:
Siemens PST
In my case I have a plc and a Panel pc with windows, in the display have installed that software for change the profinet name or you can ask at your customer to use a notebook with a team viewer and that software.
I tried to assign the profinet name using PST when I was connected to a Siemens PLC from a Windows PC via the eWON but got an error. See video. I get the same error whether or not I have Broadcast Forwarding enabled or not. Did you see the same error? How did you have PST set up?
I just want to let you know that the proposed solution works halfway only. It is true true that by activating the Broadcast function accessible devices is able to find all conected devices even if an IP has not been assigned. The bad part is that it does not allow to set device name and IP addresses to PNIO devices. The only solution is to use the Siemen PST locally as suggested by another user below.
Allows a PLC to run dashboard commands on the robot (such as play, stop, pause, restart safety, etc) by writing specific integer values to an input integer register on the robot and monitor the robot state at any time.
Enable robot by using Profinet :
So, as I understand, there is no solution to enable the robot after a protective stop by using a Profinet connection.
Can somebody from UR confirm this? Because my software department want to use Profinet and not TCP (Dashboard server)
thats not completely true.
Yes, u cannot enable the robot by profinet, BUT
if u got some time and you can realize all the requiered things (Enable the robot after E-Stop, load different programs e.g.) on ur own (without purchasing expensive (?) software from external companies.
Yes, it is no problem to set up a dashboard client on a PLC.
But it is not possible to control the dashboard commands through the PROFINET fieldbus connection without some extensive programming (set up a dashboard client in the UR Linux operating system for example or make your own URCap). Which is what was asked.
To see if an operation mode has been changed on the robot without being physicaly present is to just use a VNC protocol with a viewer and you can check the TP display remotely. Not the most elegant solution but is the quickest. There is a Magic file circling around the forum.
We're trying to set up a Fanuc AM 0iB robot with a R30iB Mate controller for an ArcWeld application with a Fronius welding generator. So far, so good.
We've got a Siemens S1200 PLC with ProfiNet as a center for the cell.
The problem we've run into is in trying to set up the ProfiNet communication between the PLC and the robot. While we can see the robot fine and dandy on the network, and we use the most recent GDSML file from FANUC, we still can't actually communicate with the PLC.
On the robot's side I can see at the ProfiNet device configuration the error: Connection never established, never tried...and no option to do anything about it. I'm having issues navigating the ProfiNet setup interface that came with this particular robot.
This is basic, but are you plugging the profinet cable into to the profinet card itself and not the CPU board? The ports are not connected. Also, for a slave setup the bottom two ports on the card are used for that. The top two are for when the robot is a master.
2 is the one I have issues with because, honestly, the MENU -> I/O -> ProfiNet (M) sends me to the application and I don't have a manual for how THIS one works. See image underneath for how the ProfiNet configuration looks in the robot.
Thank you very much for the replies.
We've found our problem. We needed a MOLEX GSDML file, and not a SIEMENS one. It goes to show what happens when someone else orders the robot and doesn't give the installation team full details about what was ordered. Live and learn.
I also have issues with the Molex card, I have the GSDML file correct and I set up IP, Subnet, Gateway, Name and then slot 1 as PS2 Bytes, 2 as In/Out 16 bytes and 3 as In/Out 16 bytes. But the card won't communicate with my 315 CPU. Any ideas?
I have te exact same error here, TIA Portal V14 with S7-1200.
I have set profinet name to robot with TIA, and PLC then gives correct IP adress to robot, so this works.
but then no communication bitween PLC and robot, i can ping both.
in TiA i have this error: "Error: IO device failure - RPC common error r30ib-iodevice"
only thing i can think off: i have R30IBPLUS cabinet, wich is a newer version than the regular R30IB cabinet.
TIA detects the online device as "R30IBPLUS", my gsdml files are dated of the year 2016.
I don't.think the controller model would have some influence in this problem. What matters is the model oslf the ProfiNet board (I'm assuming is a Siemens one), and the firmware that is inside the board.
IODDfinder, an essential tool for providing IODDs (device descriptions for IO-Link devices), which has become highly recognized and much used in recent years, was established by the IO-Link Community. This recognition and use are not only reflected by the sheer number of device descriptions and amount of support for devices available in the database, but by the level of active utilization by users as well.
Currently, this central database contains IODDs from more than 100 manufacturers with support for well over 20,000 IO-Link devices. In 2020 alone, the number of IO-Link devices represented in IODDfinder rose by around 70%. Increasing acceptance and use are also confirmed by the download statistics, with well over 600,000 recorded monthly downloads and rising. These downloads almost always occur automatically, i. e. directly from user tools or applications.
The success of IODDfinder has motivated the IO-Link Community to make available to users an additional benefit of this kind of central database: a new function called IODDviewer. In addition to the original convenient way of making IODDs available from a central location, IODDviewer now enables easy, centralized access to documentation and information on the device functions described in an IODD:
What this means for the user in concrete terms is that IODDs now no longer need to be downloaded and possibly installed in order to get an overview of a device function. Just as in an IO-Link tool, an IODD view is now available directly in the browser window through quick access in IODDviewer. This rather technical view of parameter details now also serves as, among other things, a central reference guide on specific IO-Link parameters, e.g., for software development.
In the first step, IODDviewer only supports the display of IODDs for IO-Link devices according to specification 1.1. This accounts for more than 90% of all IO-Link devices today. In a subsequent step already in development, all IODDs and other features will then be displayed.
The advantages of IODDviewer to the user are clear: Information on devices and their IO-Link properties and functions can be called up from a central location with a standardized user interface and can be displayed without any additional tools.
7fc3f7cf58