Evaluating IEC-Dev for Structured programming

[KenE 0]

Hello, I am evaluating Mitsubishi Q series PLCs for general high speed automation equipment at our plant. We do all programming in-house with a small number of engineers in charge of the machine controls. I prefer high level text languages such as C/C++, so I am naturally drawn to Structured text, with SFC as an outer "overall structure" kind of architecture. For me, and the company I work for, we are looking to use ST for 95% of our code. I have found several limitations with GX-Developer (I haven't used GX-IEC yet) with Function blocks, the most severe being that you can only have 500 steps in a function block (Why the heck is this so.. who knows?). Also, variable names and function block names are seemingly limited to 16 and 8 characters respectively. There are other less important details that put me off, but they aren't as important. After using GX-Developer, I am a bit concerned that there are some of these "hidden-self-imposed" limitations on GX-IEC as well, but, then again, reading the manual of GX-IEC, it appears to be just what we need, and conforms quite well to the IEC standard for the most part. I guess I am asking if there is anybody on the list doing what I am proposing, that is performing high level, structured programming tasks similar to C/C++ / Pascal, and what are the limitations that he/she has found in using GX-IEC. Also, I am interested in things like support in the USA for GX-IEC. I don't care for project design support, more for bugs in the program and other technical details that may not be readily published. Thanks, ~Ken Emmons Jr.

[JimRowell 1]

Hi Kemmons, I can't really comment too well about GX IEC since I've never used it (I use the old dos Medoc) but it should be more or less servicable since it is supposed to be IEC (more or less?). I'm tempted to tell you not to be completely put off from your look at GX Dev... the multi language support in GX IEC "should" be enough to zoom it light years beyond GX Dev. IMO Developer itself is absolutely 100% unusable. I can't even call it software (although others here disagree with me on that point). What I would suggest is if you are close to a serious supplier, they will have a copy installed. I'm sure they would allow you to sit down for an hour in their office and try it out. Can't beat a test drive (a *long* test drive).

[Guest IanJ]

Hi, We have only ever used GX IEC Developer and not GX Developer, so I can't compare. With IEC we have managed to develop some complicated and high speed machine control programs/systems using it, and managing to keep scan times well below 0.5ms. Put this into perspective, our alpha version was running at about 10ms before optimization on one product. Modifying the program to a more structure layout enabled us to do this. Our VB/C programmers don't have too much to complain about when using IEC, of course it's not as flexible as C etc., but compare it to say Medoc ladder, or Toshiba ladder there is absolute ZERO comparison for friendly yet complex producing abilities of IEC........but only if the effort is put in (hence the 10ms to 0.5ms.....!!!). Ian.

[JimRowell 1]

Well, then it must be pretty good since higher level languages such as ST, when not internally optimized, can be seriously inefficient (and I doubt that GX optimizes very much if at all). Was that a Mistubishi plc you managed sub 500us scans on? I'm asking because it sounds like you are not using the END instruction or normal scans since the END instruction by itself is listed as taking 450us on an FX1N and 508 on an FX2N. The A series gets much, much worse. I'm not knocking you. I'm seriously interested in how you managed to do this. I work below 1 ms at times and avoid END for short periods (back-looping) occasionally when I really have to but I wouldn't say that I keep my scan time well below 0.5ms. I have an FX2N running beside me right now with a program that consists of nothing but a single line with END on it. It shows a minimum scan of 500us, a current scan of between 500 and 600 us and a maximum scan of 900us. Edited 3 Jun 2004 by JimRowell

[KenE 0]

Hello Again, Thanks for the replies guys. I am getting an evaluation copy sent to me as we speak. I hope that it will answer the questions I am having. As far as efficiency, I guess it is relative. I've seen examples of ST code where people programmed in a "ladder style" but using ST. Essentially it was like "if this input, turn on this output" kind of code. So you have potentially hundreds of lines of code that get scanned every time, instead of using more efficient means where only a few lines of code get scanned every cycle. Another question I have with ST and GX-IEC is how it scans the ST code. Specifically if you have a parallel branch that calls three ST function blocks, when does execution switch from one ST function block to another? I'm pretty sure its not time based, such as in pre-emptive multitasking systems. In some PLC-like systems (Like Steeplechase Soft-PLC) it is when you need to loop back in your code to a piece of code that was already run (such as you are waiting on a condition to be true, which is not going to be updated until next scan...) Thanks, ~Ken

[Guest IanJ]

Hi, Right now, I have a Q06HCPU running a machine control program, and with a hand built simulator to simulate all the I/O and complete the various sensor I/O loops. Scan time = 316uS (micro). The code comprises:- 27 POU's, the largest of which has 59 rungs. A mix of FB's, PRG's & FUN's Used system words = 1350 of 6144 Used system bits = 328 of 4096 Used timers = 4 of 1984 Used labels = 99 of 2048 I also have a Q02 (slower cpu) running a smaller but nevertheless similar project here and it's running 0.4ms (milli). The secret is not to scan what you don't need to, and if you do need to then only scan at the speed you need to. There are many other tricks to keep the scan time down. The Q06H is as fast as it gets (same as Q12H & Q25H I believe). LD X0 = 0.034us MOV D0 D1 = 0.102us .....if that's any gauge! Ian.