PLC/HMI Programming | Learning from Mistakes

//PLC/HMI Programming | Learning from Mistakes

PLC/HMI Programming | Learning from Mistakes

HMIforMachineControls

Twelve years ago when I started writing basic ladder programs for PLCs I made a lot of mistakes. Seemed like I was always getting halfway through a project only to realize I’d taken the wrong approach and needed to take two steps back before I could move forward. Frequently this resulted in me scrapping the entire program and starting over. I told myself that was fine. I was learning, right? Well… a dozen or so years later I’m still learning. Now I say, “You never want to stop learning,” but I’m not sure I believe myself. I mean, wouldn’t it be better to stop making mistakes, altogether? I suppose that’s not likely to happen so here’s the tale of my latest misstep:

One of my projects for an OEM control system based around a Unitronics Vision 570 (V570) uses several data tables. Even though we’ve already built hundreds of these electrical control panels and the machines work great, we’re constantly updating and improving the PLC/HMI program. Some of these changes affect the data tables. No problem, except…

Two of the data tables are frequently accessed by a third-party wireless, handheld device called SynTrack. Here’s where my mistake comes in: I should have put these data tables first in the list. Whenever you make a change to a data table, the starting location of all the data tables following it will change. The starting location of your first data table will never change, though, so it would have been a good idea for me to put one of these two first in the list of 7 or 8 tables. It wasn’t a big deal to change this but there is an issue with the second data table that Syntrack needs to access.

I can only have one table in the first position. What happens, though, when I make a change to the first data table? The starting location of table number two will change but I don’t want to force changes to the software in SynTrack. An easy solution is to add a column in the first data table which holds an offset value to tell SynTrack what the starting location of table two is. SynTrack always knows where to find the first table and that first table will tell it where to find the second table. Simple but effective. Now I can make changes to any data table and SynTrack can keep up with my changes without the need to revise its software. I just need to remember to change the value of this offset integer.

You can bet I’ll remember this in future projects. It was aggravating to fix after the fact because changing the order of data tables required me to delete the originals from the DT structure and then search them all out in ladder, point to the new tables and then re-address all the fields in each of those DT function blocks.

Hopefully my time-consuming mistake will help you, though…

By |2018-01-20T18:02:56+00:00November 5th, 2010|Company News|