Profinet Driver
Sharyn Requena
I have a problem with my KR16 KRC4 kuka robot. Yesterday there were many power surges from the control plant and the controller went through rapid on offs at least 4 times before I was able to shut it down for good. Upon restarting, the smart pad signals me a red bar with "emergency stop local" and among the messages I have a warning of the type KSS00076 I / O driver 'PNIODriver' uninstalled. From the Plc i can't see the robot in profinet and i think there is some profisafe signals in profinet so if the profinet of the robot not work is a problem.
Trying from the menu in the smart pad to go to configuration-> input / output-> I / O driver I see in the table the PNIODriver with the gray dot beside it instead of green (as on another twin robot). What can I do ?
Thanks for the answer. The kss version is 8.3. The PNIO module was installed at the beginning and the machine worked for many years. But now if I go to configuration-> input / output-> I / O driver and I press the tab configuration the smart pad show me the PNIO module is installed ad if I click on it the system tells me that is impossibile to unistall it (show a lock on the name of that driver)
To reinstall it, if You have an old 8.3 (and here is important to know the third number on KSS version), like 8.3.12, You will go the same Install Additional Software, but this time press New Software, and choose ProfiNet package.
I have the old wov project so I can deploy that project to robot controller and see what happens ? And in order to do that I think that in my wov 5 i've need to have all the packets(like profinet) that are installed an used in the robot controller.
When the Ethernet port (Profinet) of your S7-400 CPU is connected to the same Ethernet as the Igntion Gateway, you can use Ignitions Siemens driver. All S7-400 Profinet CPUs support standard Ethernet connections on the Profinet port.
The process data of the Profibus devices should be mapped to I/Os, so you can read them with the driver. In fact you can read anything that can be shown in Simatics variable status when you are connected to the cpu over Ethernet.
Some settings in the plc need to be set to allow connection. If these are not set by the machine manufacturer you will have to request it, alternatively do it your self if you have the Siemens software and access/permission in the plc to make these changes.
If your supplier meets the Siemens programming guidelines, all relevant data will be in optimized data blocks. Maybe you are lucky and they still use global flags and not optimized blocks, but i would not rely on this.
There are reasonably priced 3rd party OPC-UA servers with full support for S7-1x00 plcs.
Hi, I am looking for something similar. I hace some questions regarding this adapter:
First, have you use this modules to connect MPI/Profibus to ignition? Is this a transparent process or does it requiere custom configuration? Can you explain a litle more about it? I dont have access to edit anything in the PLC.
The MPI to Ethernet adapter is used to connect a legacy Siemens processor (S7-300/400) to Ethernet. The Ignition Siemens driver can access the processor with that connection. The processor itself is the gateway to the MPI/Profibus network. What data is available depends on the plc program, but at least all Profibus I/Os should be accessible to read.
AZ Series Stored Data drivers now offer PROFINET communications for a battery-free, absolute mechanical sensor motor and driver solution.
For use with all Oriental Motor AZ Series motors and linear & rotary actuators equipped with the AZ Series.
The stopping accuracy of a typical αSTEP is 0.05 (under no load), which is equivalent to that of servo motors. The graphs below show the actual measured stopping accuracies when an αSTEP and an AC servo motor were rotated once.
Oriental Motor has developed and patented a compact, low-cost, battery-free mechanical type absolute sensor. The αSTEP AZ Series is available at affordable prices and can contribute to improved productivity and cost reductions.
There is no concern about sensor malfunctions (when operating in environments filled with oil mist or filled with metal pieces due to metal processing), sensor failures or sensor wire disconnections.
Because return-to-home is possible without an external sensor, return-to-home can be performed at high speed without taking the sensor sensitivity into account, allowing for a shortened machine cycle.
The home position can be easily set by pressing a switch on the drivers surface, which is saved by the Mechanical Absolute Encoder. In addition, home setting is possible with the MEXE02 data setting software or external input signal.
No battery is required thanks to a mechanical-type sensor. Because positioning information is managed mechanically by the Mechanical Absolute Encoder, the positioning information can be preserved, even if the power turns off, or the cable between the motor and the driver is disconnected.
Because there is no need to secure space for battery replacement, there are no restrictions on the installation location of the driver, improving the flexibility and freedom of the layout design of the control box.
Normal batteries will self-discharge, so care must be taken when the equipment requires a long shipping time, such as when being sent overseas. The Mechanical Absolute Encoder does not require a battery, so there is no limit to how long the positioning information is maintained. In addition, there is no need to worry about various safety regulations, which must be taken into consideration when shipping a battery overseas.
The AZ Series motors can be controlled easily by using the PROFINET communications protocol.
The PROFINET compatible drivers comply with Conformance Class B.
Using the diagnostic tool of the host controller, network diagnostics and topology detection can be performed.
The αSTEP AZ Series Mechanical Absolute Encoder is available as a leading closed loop, battery free absolute motion solution sold as a Stepper Motor + Driver or Linear Actuator + Driver allowing for absolute, battery free, advanced performance across a wide range of applications.
The AZ Series offers high efficiency, low vibration and incorporates our newly developed Mechanical Absolute Encoder for absolute-type positioning without battery back-up or external sensors to buy. Closed loop performance without hunting or gain tuning. Available with a built-in controller or pulse input driver which substantially reduces heat generation from the motor through the use of high-efficiency technology. Requires AZ Series Driver.
During vertical driver (gravitational operation) or suddent start/stop in high inertia, an external force causes the motor to rotate and funciton as a power generator. When the regenerative power exceeds the driver's regenerative power absorption capacity, it may cause damage to the motor. In such a case, the regeneration unit is connected to the driver to convert regenerative energy into thermal energy for dissipation.
This somewhat depends on the physical connection you need. If it is an ethernet connection, then there is option to connect the cRIO to the device(s) via the built in ethernet port, and then use the API for Profibus in Labview (not sure if it is only in a specific version of LV, or is an add-on). We've had a few systems developed interfacing to Profibus devices through the built in ethernet port. If the physical connection is via some older serial type physical connection, then you may need to dig a big deeper to find out how to a) physically interface, b) access via sw.
From our experience with Profibus, it is important to know about the terminology and configuration of the devices you are trying to talk to. This might be a useful starting point: -gb/innovations/white-papers/08/profibus-overview.html
Seeing as Profinet and Profibus are two very different things - one is a field bus using RS-485, the other is an industrial protocol using ethernet - I'd be very surprised if you could directly connect Profibus devices to an ethernet port without any adapters, or if you could use a Profibus API in LabVIEW to communicate with Profinet devices. I'm not an expert, though, so I might be wrong here.
Siemens used to offer a Profinet driver that allowed Profinet communication via a generic ethernet board (ie without additional specialised hardware) but it has been discontinued, too. This driver was available for Linux, and we briefly looked into porting it to NI Linux RT. Eventually, though, we dropped the idea due to the end-of-life status of the driver itself.
I would be interested in communicating via the Profinet protocol using a cRIO 9057 with extension. The idea of using a built-in Ethernet port and then an API for Profibus in Labview is not clear to me. Is it possible to give me more details please?
I do not think that there's a way to connect Profibus and Profinet without additional hardware. Not only with NI and LabVIEW, but in general. Also, I do not know of any "API for Profibus in LabVIEW", either.
The idea I described above was to implement a LabVIEW wrapper for Siemens' Profitnet driver (which is a pure software-based implementation of the Profinet protocol) and then use the built-in ethernet socket on an NI Linux RT based device for Profinet communication.
The Profinet driver makes possible the integration of PLC Siemens S7 series control devices into Niagara Framework. All components of the driver, devices and detected points are perfectly integrated into Niagara Workbench, allowing a better efficiency in the design and maintenance of the systems and consequently lower costs.
The use of JACE, together with the QL Profinet driver, allows to manage PLC Siemens S7 control devices non only with the native supervision system (Niagara Supervisor) but also with other supervisory systems (eg. SCADA) fitted with standard communication protocol (Modbus, BACnet, oBIX, etc.).
4a15465005