Carl is taking a short vacation. He may return with more off-topic news, but in the meantime enjoy this guest post from the PROFI Interface Center’s Kyle McMillan.
The first time my new neighbor got to see me get mad was when I found him lying under his mower, trying to change a blade by beating one of my ratchets with an iron
pipe. I had let him borrow my tools, and it looked like it was going to cost me real money. I’m your typical engineer, and little veins started to pop on my forehead as I comprehended the scene in front of me.
After I calmed down I taught him the wonders of penetrating oil and a breakover
bar, and I haven’t had a problem with him popping my ratchets since then. Simply teaching him how to use a new tool has saved years of frustration between us.
PROFINET’s no different; many people approach their PROFINET device designs with the same mentality they used for their old Modbus implementations years ago. They understand that not all of their data fits in to a neat cyclic data exchange – they may have parameters that have to be set at startup, or have application-specific alarms – but they try to cram those features in to the cyclic data exchange with the expectation that “the end user will just write some application code to sort it all out in the PLC.”
That’s the equivalent of my neighbor’s mentality. Throwing all of your data in to the cyclic data exchange is a surefire way to tick off your system integrators and ensure that the end customer inherits technical debt the moment they install their shiny new machine. If only there were a few more mechanisms to help deal with different types of data appropriately… and wouldn’t you know it, PROFINET has them!
Do you have event-driven data like diagnostic events or fault information? Put it in an alarm and let the standardized error-handling routines in the PLC take over from there – no funky application code required. Do you have data that only needs to be written at startup, like drive tuning parameters or analog-to-digital converter configuration? Put it in a parameter record and let PROFINET’s native configuration mechanism handle it from there – no funky application code required. Designing your application with these tweaks can save a lot of time for your system integrators and end customers.
Not only do these changes save time, they also save a lot of precious system resources. Imagine a PROFINET device that contains 16 bytes of parameterization data and 32 bytes of alarm data in the cyclic payload. That’s wasted space in the PLC’s process image space that can’t be used for other devices – and if you’re implementing sixteen of these devices that’s ¾ of a kilobyte that evaporates for no reason! That space costs money, and may mean an application engineer has to buy hundreds of dollars of extra PLC capacity… all because a device application wasn’t designed efficiently.
So don’t be like my neighbor and try to use the wrong tools for your next PROFINET development project – learn to use the right tools and build a better product. If you’d like to know more, check out our series of Developer Workshops at http://us.profinet.com/training/developer-training/.
Kyle McMillan is an engineer at the PROFI Interface Center and has plenty of experience using the wrong tools for the job.