One -unique- Connumication Module - is this possible?
Most manufacturers of Industrial Equipment are facing the various industrial protocols and bus systems. Which one to support and which one not? There is almost no right decision - except for supporting all of them. Except this not exactly an easy decision. Often enough the product is already existing and finshed in form, function and design. Mostly an CPU or MCU is being used which is perfectly suitable for the existing product - but not for more and certainly not for operating a complex Industrial protocol.
- the CPU/MCU is selected for the existing functionality only; not having capacities left for serving an extensive Industrial Protocol
- In many hours everything was optimized for exactly THIS CPU -- If it works - don’t fix it!
- Missing Know-How and/or capacities to implent the Industrial Protocols
- Window of Opportunity is open NOW – possible sales opportunities NOW
- Units to be adjusted to the appropriate protocol direct before shipping
- CANopen over EtherCAT
- EtherNet/IP (CIP)
- For EtherCAT the EtherCAT IP-Core is being used - so the EtherCAT advantages remain in function and all payload data are used in realtime.
- Regarding PROFINET a 3-Port switch IP-core utilizing Cut-Through and EtherType support is being implemented
- POWERLINK is being supported by a special low latency 3-port hub and a special POWERLINK MAC
- EtherNet/IP specific a 3-port switch IP-core supporting IGMP/Snooping is being used
- SERCOS is being supported with the SERCOS Ipcore And all of this very flexible.
Already here every manufacturer of a network operated device has solved many problems - but still has some problems to solve: The existing application need to be fed with the variables delivered by the Protocol Stack. Exchange of data with the host application - fast and with lowest resource consumption. Exactly here the impact on the existing application is determined and how many resources of the CPU/MCU and development effort are necessary:
Integrating of the existing control solution into the CPU of Communication module?
This comes with significant risks regarding time frame of the project and reliability as well as it costs time and money
Connecting with a serial protocol (e.g. SPI)?
This way anew bottleneck is being created and the CPU is loaded with management of the addional sub-protocol
Data Exchange by a Dual-Ported-RAM mapped as a common memory for CPU/MCU and Communication Module
Only small changes in the host application are necessary. The DP-RAM is integrated in the FPGA and can be adapted to almost ANY bus timing for the host CPU/MCU
Large parts of the object dictionary are maintained in the DP-RAM only - this can be adjusted with PUDIN and port’s tools - Optimizing performance made easy.
PUDIN - what about it?
PUDIN converts the normal DP-RAM interface into a fast and effective solution. Parts of the object dictionary are being held directly in the DP-RAM – by PUDIN. Changes are written directly to the corresponding location - the application accesses the variables directly. This can be optimized in way that a variable (e.g. rpm of a motor) are read by the state machine directly from the DP-RAM and not from a local variable any more. This reduces the impact of the changes to a minimum. Using the corresponding design tool makes the generating, managing and application of the variables on the host side very easy and reduces error-prone manual activities to almost zero.
This interface is independent from the Industrial Protocol by providing an optimized method. Adaptions to the specifics of the corresponding protocol may be necessary. Using the corresponding design tools this effort can be kept at a minimum and reliefs the engineers from error-prone definition duties. Just take a look at our sample for a communiction module and study our PUDIN specification. We are available for designing your specific Communication Module - in Hardware and Software.