Saturday, December 15, 2007

Programming In my last post, I made a snide remark about stringing ladder logic code into something we call "spaghetti code" because you can't untangle the strands. This past week I also spent some time with the ISA 88.5 committee (Make 2 Pack) as they were developing a final edit of the draft in preparation for comments and voting. Part of the standard refers to programming. I haven't been around programming for 10 years, now, but I was assured that people are still writing spaghetti code. Our programmers at Cardinal Tool were often required to develop flow charts. Did they write the flow chart and then develop code around it? Oh, no, that would have required thinking about the machine. It's easier to just string the code then do the flow chart later. (Kind of like when you were supposed to outline your freshman paper, then write it--remember?) I started programming in the late 70s on an IBM minicomputer in RPG III. I picked up a little COBOL and Fortran (but never used it). Then I bought a little computer (before they were called PCs), and then got a second, and started writing programs in BASIC. I remember finding a book called Structured Programming in BASIC, or something like that. Surely an oxymoron if you ever heard one. It had a great influence on my thinking. I've been trying to find it in my library for years to prove to myself that I wasn't smoking something (I am from the 60s, you know). I still can't find it, but you can buy a dozen books on Amazon.com by that title. Some date to the late 70s/early 80s. So there's a good chance I really did have the book. Probably loaned it to a forlorn programmer who couldn't troubleshoot his code. That's why I like the standards development and integrated development environments that help programmers do a better job. I think it can actually save a company from bankruptcy. I'm not a programmer, but I'm opinionated. I guess that counts for something ;-) 9:42:16 PM    comment []

Digital factory By now you've seen some news of the "memorandum of understanding to develop a joint solution" (a phrase obviously painfully contrived by lawyers--the arch enemy of sense) between Rockwell Automation and Dassault Systemes (specifically Delmia). So despite the lawyers' antipathy, we ordinary folks would say that the two companies are partnering to provide a technology to support the coming "digital factory." A seven-person entourage visited the Automation World offices last Monday to explain the details. (Wes's news report is here.) At long last, I may add. I remember covering a demonstration of this technology (obviously before its time) probably around 2000 (I worked for Control Engineering at the time, so I can't find my notes). The idea in simple terms is to unite design of part, machinery and tooling, and automation systems--at least at a conceptual stage. All the design is done in software now. So, if all the applications could share information and talk to each other, then all the design stages could be compressed. This is the famous reduce time to market and time to produce benefits. Not only that, if you can add simulation, then you could actually test the entire manufacturing line before cutting the first piece of steel. It is impossible to overestimate the value of this for both OEMs and automation users. I know exactly what this means. When I was a manager a one of those machine-building OEMs in the 1980s, the point of the project that would determine profitability was at final debug before test and acceptance on our floor. The problem was that mechanical design came first. Then the programmer (who was often an electrician who learned ladder logic for a PLC) would start at a sensor at one end of the machine and start stringing code one ladder at a time (if you don't know ladder logic, trust me, it's ugly) until he (always male in those days) arrived at the other end of the machine. Then we'd turn the machine on after the wiring was done. Poof -- nothing happened. Now we're at debug. I saw some machines sit 3-4 months before we could get to acceptance testing. Our profits on that machine just went down the drain. This technology has the potential to be a game changer. I'm not just making that up tonight. Here's my report from the 2006 ARC Forum (before Siemens acquired UGS, by the way). I'll quote a little here: In one interview, I talked with Ralf-Mchael Franke, President of Siemens AG Automation and Drives. (Note, I linked to the US site for Siemens.) Franke's presentation focused on the company's development of the virtual (digital) factory. The first product (in partnership with UGS) is a designer CAD system. The long term intent of the initiative is to be able to integrate CAD design through simulation to build not only of product but also manufacture (machine design through control programming). I've seen glimpses of this technology during the past few years. I think this is a real game-changer (if they can pull it off). The Siemens acquisition is only a few months old, but it looks as if it will be a while until they can merge their software. Meanwhile, Rockwell and Dassault are touting the past investments they have each made in software architecture as the reason they will be able to pull off this collaboration. Rockwell laid the groundwork years ago as it developed its Logix platform with modern computer science principals such as global namespace and objects. Interestingly, Dassoult made a similar investment. Therefore, this joint solution involves writing a solid interface (they already have one in Visual Basic to prove the principle) between their platforms at the one crucial spot. So now we have competing platforms. That's good. Users stand to reap immense benefits--if they can pull it off. 9:28:46 PM    comment []