Control.com - Nerds in Control

I am in need of good PLC recommendations. I am new to the field. I have been working with PLCs from Automation Direct. I have a 12 volt solar/battery power supply. The automation direct PLC I have is working great, however, their ladder logic programming is proving to be to static and not reusable enough.

I did some reading on the web and found this stuff called Structured Text and the IEC-1131-3 standard. It sounds great. However the only PLC manufacturer that I have found that supports it is Allen Bradly and they only have 24 volt systems. Any advice? Thanks,

What size and price range of PLC?  It is difficult to find small, low cost PLC's with high end software environments.  Lot's of PLC companies use IEC-1131, maybe not in their smaller PLC's, however.  Look at Wago, I have heard good things about them.  EZ Automation is similar to AD in size and price, but they offer subroutines in their ladder logic.

Also look at Rabbit Semiconductor, if you can program in C.  They have some nice embedded boards that are similar to a PLC in functionality, as long as you don't expect your end users to program them also.  You will certainly be able to write modular code in C.

Hopefully, some of these ideas are useful to you.

Bill Sturm

Abbeytronics LLC

Hi Mike,

You will probably find that 90% of PLCs work with 24V, which is a defacto standard for signals. I'm sure some work with a variety of voltages though, just make sure that your inputs can handle lower switching thresholds.

We started using Mitsubishi with IEC developer because it had a re-useable library that could be common amongst many projects (we have a acommon library file on a network drive and gets included in every project). At the time we went with Mitsubishi AB didn't have the "User Defined instructions" that they now have, so I would look at them as well. I didn't look into Schneider, GE, and Siemens for different reasons. I am not sure if OMRON has anything for re-useable libraries.

One thing I will say, however, is that beware of the implementations of the IEC 61131 languages. Myself amongst others have looked at structured text (ST) for control (For those familiar with C and VB, ST is easy to learn...). The problem with this is that you really can't do a lot of control tasks in ST like you would in a multitasking environment in C/C++, etc. That is to say that ST code in PLCs tends to be just for calculations and more intricate logic solving, such as the following:

(Syntax may not be right...)

If(input := true)
set output;
Endif

What you can't do in most PLCs is code that blocks (multitasking OS term for something that does not exit right away) such as the following:

WaitForInputValid(MyInput); //Blocking function call
DoSomething();
WaitForAnotherInput(MyOtherInput);
DoSome thingElse();

If your input waits exceed the watchdog time your PLC will error.

In practical terms, it seems that ST was only really intended for allowing programmers of PLCs to do a lot of "Math" and complex decision making in a Pascal/C like language. I.e. it seems they never meant it to be used for sequential control.

There is, however, no reason this has to be that way, just the way the PLC is structured. I'm pretty sure that IEC 61131 does not cover task execution at all, so you are reliant on the vendors implementation. If a PLC has really fast execution and allows for multiple "fast" tasks running simultaneously (and you can get around a watchdog problem) you could program entirely in ST. If anyone knows of such a system, let me know! Usually something is wrong, such as task execution time, or the number of tasks you can have, etc.

KEJR

In reply to Ken Emmons Jr.: You said: "ST code in PLCs tends to be just for calculations and more intricate logic solving, such as the following:

If(input := true)
set output;
Endif
"

That's not a good example for ST. It's actually a classic case of where ladder logic or IL works better than textual type languages. In ladder, that would be just a normally open contact and a latch output.

As for whether you could do typical PLC type operations with a conventional textual (e.g. 'C') language, it's quite possible. It's just a lot of work. The example you gave (quoted above) is how you would do a latch or unlatch type operation. The equivalent of a coil is just an assignment operation. Sequential control can be implemented as a state machine. You just need a state variable and a series of "if" statements or a "case/switch" statement for each sequence. I've done this in machine control applications in 'C', Basic, Python, and a few other languages as well.

You also have to be very careful to write code that *doesn't* block. This is done all the time however with GUI event loops and with asynchronous server programming. What ladder/IL languages offer is a language that is designed to inherently work this way. You have to go out of your way to make a blocking call in ladder/IL (e.g. an infinite loop).

So far as I know, most ST implementations simply compile the ST source code to IL. The IL acts as the "machine code" for the PLC. I believe that ST is mainly used for expressing complex mathematical equations. You can do the same thing in ladder with some PLCs however, via equation "boxes".

Most PLCs don't support ST, because ST is used in only a few niche industry applications.

I found C to work fine, and the work, once accomplished, can be very reusable. I used a file with logic statements and a large switch statement. It wouldn't be much to add the PLCisms of an input
read and an output set to be more synchronous. This is a classic compiler problem and flex and yacc could be used to advantage to write the code. Speaking of ST, this would be one of the easiest ways to make a PLC. It could be extremely close to any of the "4GLs" to make an Automation Language and be done with it. This would be even easier than ladder because it's text based and the set of PLC instructions is quite limited. Many similar things get written as a school project, so I'm sure a group from this august body could do a great job.

Regards
cww

In reply to Curt Wuollet: An ST to C compiler? So far as I know, that's already done. The Beremiz editor http://www.beremiz.org does:

* Structured Text - ST,
* Function Block Diagram - FBD,
* Sequential Function Chart - SFC,
* Ladder Diagram - LD,
* Instruction List - IL

It targets an IEC version of MAT (I believe you've heard of that), which compiles the output to C, which in turn compiles to machine code.

I can't say how well it works, as I haven't spent any time on it. You might want to give it a try though. You'll have to pull from CVS though, as they don't seem to do packages.

Yes, that would be one way. There _will_ be others as well. What I am speaking to today is how to "productize" (which isn't really the right word) a vertical package that has users from the start. Here is the link I mentioned:

http://linuxdevices.com/news/NS9634061300.html
I can't say enough about the Mat developers or the Beremiz folks either. They have demonstrated that the software end is certainly doable. On the hardware front, the link shows something that will become extremely common pretty soon. An "appliance" computer that has the all attributes needed to do automation. The I/O is all networked. presentation could be either browser based, or?

A cool fanless, driveless computer is $50 in qty. There are similar units with Open designs to which adding an I/O bus would be doable.
The I/O cards are not rocket science either. All the pieces are there, so how to get it done? If 10 small automation solution providers want a platform that they can own to get off the treadmill
and could somehow agree to get the thing done without directly profiting from the effort, it could be done. There are things that will need some kind of backing, like the hardware end. Most of
the software is done, but the point is that it is doable if this community would "buy in". I'm sure we could get someone to build the hardware to spec. And I've sure we could get the FOSS projects to port to the platform. But the missing link is a few companies that want to change the status quo and the course of Industrial Automation.

Regards
cww

Hello,

We started using PLCs at the company I work for because we wanted a scalable system that was reliable and didn't require a lot of work maintaining a development environment. There are some cases where the parallel nature of ladder proframming is beneficial too. The eliability of the hardware and the ease of configuration of modular rack systems is very nice in a PLC (Well, the better ones anyway).

We are interested in around a 1ms IO update loop, and this is probably easy today with the choices of IO. Many things have evolved in the last several years and doing an embedded C/C++ controller is much more feasible. If you know of a development environment that supports hard realtime (say 16 tasks in 1ms), HMI/visualization, Network/SQL Database connectivity, Windows visual IDE with debugger, and IO drivers for [fast and compact] fieldbus IO I would be interested.

If, for instance, VxWorks supported all of the above and integrated (with drivers) to a slice IO over ethernet such as B&R, Beckhoff, or others that would be interesting. I've done some work with a version of realtime linux years ago (RTAI) and the lack of easy to use debugging and choice of IO systems was difficult. I had to write IO drivers for a PCI IO board we were using because one didn't exist. In the end, going to a fanless PC with multiple ethernet ports and flash drive would be ideal. I just found out that the Mitsubishi Q system has a VxWorks programmable CPU that can be plugged into their backplane. This is something we might consider moving toward since it uses PLC hardware but can be programmed in C.

As for the ST example below:

>If(input := true)
> set output;
> Endif

This was probably not the greatest one to represent my point, but it is what I have found for example code in many PLC manufacturers manuals of how to program in ST. I fully agree with you that if you are going to program like this, then ladder is better suited for the task. I tend to use ST for complex decision making and calculations that would look obtuse in ladder.

My main point of the last email was that it is easy to look at ST and say "They finally have high level programming in a PLC!" and it is, well, only partially true and extremely vendor dependent as you have said.

KEJR

The platforms are here, fanless, powerful, with ports of Linux which could certainly blow graphics across the wire or run any amount of I/O. There is one I was looking at the other day. I'll post a link. The RT stuff is available as well and much could be done to make it easy to use. The problem is that most of the I/O protocols are owned or controlled by entities who are not at all inclined to help you do anything but buy their whole package. Getting something to talk to several flavors of their product is something they can thwart indefinitely or at least for the foreseeable future. That said, these same inexpensive powerful, fanless, driveless, tiny SBCs would make great I/O couplers. The electronics to add I/O are fairly cheap and easy and by owning both ends, you can use any protocol you want.
All it would take is a sponsored FOSS project to bankroll some very modest costs and there would be a Open alternative. If we could somehow get enough people interested in using it, the last barriers could be easily broken. As a shared project, neither the expense or the time needed would be at all unreasonable.

Regards

cww

After some poking around on the internet last night, the preempt_rt extensions to the latest linux kernel releases look the coolest to me
(at the surface). It seems like you can program and debug in userspace (i.e. not in the kernel) but I am not sure of all the details having not worked with it yet. For instance, do you have problems with having posix multithreaded processes that some are realtime and some are not. The advantage to this, of course, is that you can have a GUI/HMI, or maybe a database reporter thread share memory space with your realtime thread(s), etc. Also, you don't have two applications to start/restart, etc.

- Shared RT and non-RT threads in one process?
- Can you have remote cross compiling/ debugging in a windows IDE using GDB or something similar (Everyone at my job uses windows and I can't change that .. Possibly remote X server would work....)?

Besides the linux/RT questions there are some concerns with Networking. I would think that Modbus TCP would be the network of choice because it appears the most widely supported amongst the "more open" vendors such as Wago, Moxa, and the like, and the standard is available for free.

Advantech and others make Box PCs and panel PCs with multiple network adapters, so you can have a dedicated Modbus ethernet port that would avoid collision problems altogether, at least in theory (Your linux
computer would be the only device soliciting responses). Some people even support Modbus protocol over UDP transport which gets rid of the TCP overhead, while maintaining the standard "Modbus/TCP" protocol. And, yes, UDP is reliable with Modbus because all modbus commands get acknowledged with a return response, which you can choose to resend or create a fault condition. The more I dig into this matter, however, the more I realize that you can tread into some deep water. Are all "Modbus TCP" IO and motion control devices even required to respond in sub-millisecond timings? I've used PLC modbus interfaces that had a built in 5ms latency that you could not adjust. What other pitfalls are out there lurking?

The other question of networking devices in realtime concerns the actual ethernet drivers and interfaces. Are the standard linux "user space" drivers good enough for sub-millisecond realtime polling when they are dedicated to their own ethernet interface (that is to say that you have an ethernet card/interface just for your handful of IO nodes that you are polling in realtime). OR conversely, do you need to use the rtnet drivers, and in doing so are you limited to third party Modbus devices that only support UDP transport? I think Wago does support Modbus over UDP, but I have to double check. I would also like to interface sub-millisecond to a motion controller such as Galil, Delta Tau, or Yaskawa. I know two out of these three support Modbus TCP, but I don't know about the UDP issue as it is not really published in anything I could find. Delta Tau is coming out with a version of PMAC motion controller that is promised to provide entire machine control in C (motion and sequence control) with realtime kernel under linux, but I don't think it will be an open system, that is to say you will have to largely rely on features they provide in their firmware releases and hardware options.

I realize that this post is somewhat off topic, and that it deals more
with the RTOS side of things, but I feel that there are unique concerns here for industrial automation that contributors here have real experience with.

Thanks,
KEJR

In reply to Ken Emmons Jr.: I'm not sure what your applications are, but have you looked at EMC2? http://www.linuxcnc.org/

They do a Free/Open Source machine tool and robot control system that uses real time Linux. They have CDs based on the latest Ubuntu LTS (8.04) that you can download.

If EMC2 isn't exactly what you are looking for, then their mailing list is probably a better source of information than this one is.

Most machine control applications don't need real time. This is why normal PLCs are not real time control systems.

In reply to M Griffin:

The LinuxCNC project looks really cool, but we make high speed assembly machines for the manufacture of our product. We typically use Pneumatics with sensors on all of the actuators, and use motion control where we need the programmable dynamics or multiple position capability. In this regard I find we use some high level programming techniques to make error recovery as automatic as possible and to aid operators and technicians working with the machine. We are forcing the PLC software to work sequentially. We are doing this with the trick of using step numbers comparisons, and jumping to other sequences by setting other sequence's step numbers to "one". Although this is a bit more work at first compared to text programming in C (everything can be designed to be inherently sequential, and you just have while loops and select goto statements...) there is really no development with the PLC beyond some initial libraries and framework template projects. Being tied to their offerings is a bit frustrating though.

My biggest worry with the Mitsubishi PLC control is that we are using their European IEC developer software (They have a development package written by Beijer that is used predominately in Europe, and one written in Japan that the USA uses.. We are based in the USA). Mitsubishi Electric USA is really against using the IEC software, probably because of training since the editor is drastically different and the fact that you can use labels on everything and have callable function blocks (Wow, what a concept). There is supposed to be a new release this year that promises to be one environment for everyone, but I heard it was written in Japan (No offense to any japanese developers but I've had really mixed success with Japanese automation companies' software). I seriously hope I'm wrong and the next release is the coolest thing to hit USA from Japan, but in the mean time it would not hurt to keep an eye out for more open control options for our future machines.

BTW, the Steinhoff environment does look interesting, I bookmarked it for future research. I like how you can dive under the hood with C programming, but it still has the drivers for fieldbus integrated and high level software for IEC programming.

Thanks

Yes, I would be a little worried about the IEC developer stuff, I can't know how it is supported in the EU but support in the US was not stellar. I've never been able to convince anyone to buy all the stuff to program in C on a MS platform, at least not since the DOS days. I think C on Linux is a far better option. But, it's not gonna get the driver, etc. support for a while until the absolute domination of Linux in the embedded world forces the issue. They can make much better margins without the Microsoft tax.

Regards
cww

In reply to Ken Emmons Jr.: You asked about: "a development environment that supports hard realtime (say 16 tasks in 1ms), HMI/visualization, Network/SQL Database connectivity, Windows visual IDE with debugger, and IO drivers for [fast and compact] fieldbus IO I would be interested."

MG: I can't answer for every one of those details, but that sounds a lot like DACHS from Steinhoff Automation. Armin Steinhoff posts here regularly, and could answer that question better.

KEJR: "If, for instance, VxWorks supported all of the above".

MG: That list actually sounds more like something for QNX or real time Linux than for VxWorks. I believe that QNX is more of a complete operating system than VxWorks. Wind River is promoting Wind River Linux for larger scale real time applications and VxWorks for smaller ones.

The thing is I think you are really looking for a development system for industrial automation that runs on an RTOS, rather that just the RTOS itself plus some standard tools. There aren't as many of the former around, while the latter is quite common.


KEJR: "I've done some work with a version of realtime linux years ago (RTAI)".

MG: Things have changed a lot in the past few years in real time Linux. It used to be that all the real time features were external patches. Most of these are now in the standard kernal, and the rest of it is working its way in. Within a few years, the difference between real time Linux and non-real time Linux will just be a compiler option.

KEJR: "I just found out that the Mitsubishi Q system has a VxWorks programmable CPU that can be plugged into their backplane."

MG: The problem with things like that is they are very much a niche market. You will be locked into whatever Mitsubishi's plans are for it. Siemens had a product like that a few years ago, but they dropped it when it didn't meet sales expectations. Anyone who developed a product around it was stuck with unsupported hardware and having to start development all over again.

KEJR: "My main point of the last email was that it is easy to look at ST and say "They finally have high level programming in a PLC!" and it is, well, only partially true and extremely vendor dependent as you have said."

MG: What I have a hard time understanding is why someone felt it was necessary to invent a new language. It will never be anything other than an obscure niche language with few books, little learning material, and no common libraries. Pick any major programming language, plug the name of it into Google along with some suitable key words and you will find all kinds of code samples for that type of problem. With IEC ST, you will find next to nothing.

Math equations are the cases usually cited for applying ST. I have R.W. Lewis's book on IEC 1131-3. I just had a quick look through the chapter on ST for some examples. All of the complex mathematical equations that are listed there I can do with a single IL MATH instruction in the soft logic system that I am writing (which is modeled on the Koyo Click instruction set). If the reason that we need ST is because of deficiencies in the math capabilities of a particular IL/LAD instruction set, it seems to me the solution is to fix the IL/LAD instructions by letting them do complex equations.

I can see an application for a textual for string manipulation (e.g. extracting data from bar code input). I think that IEC ST is the wrong sort of language for that application though. It's a staticly typed language with very rudimentary string capabilities. What is needed for that is a dynamically typed language with good regular expression handling.

I suspect that IEC ST ended up the way it was because the committee wanted something that wouldn't require any changes to existing products. The solution was to create a language that could be compiled to IL on existing PLCs.

ST no good for PLC? We use it almost exclusively (mainly because it is is the best implemented language/dev-environment in Beckhoff/Codesys. I could see using ladder and SFC a LOT more if each had a better dev environment in Codesys.)

What's wrong with this...

PROGRAM XXX_SEQ_TEMPLATE_XXX
VAR_INPUT
Enable :BOOL;
END_VAR

VAR_OUTPUT
Done :BOOL;
Busy :BOOL;
Error :BOOL;
ErrorID : STRING[80];
END_VAR

VAR CONSTANT
(*TODO: Replace this with the name of this POU*)
myName :STRING[32]:='SEQ_TEMPLATE';
END_VAR

VAR
myState :INT;
myLastState :INT;
isDone :BOOL;
ErrorState :INT;
StateTransition :R_TRIG;
Trigger :R_TRIG;
myTimer :TO N;
(*Additional local variables here*)
END_VAR




CASE myState OF
0: (*initial state*)
Busy := FALSE;
Done := isDone;
Trigger(clk := Enable);
IF Trigger.Q THEN (* On rising enable line, init sequence... *)
Busy := TRUE;
Done := FALSE;
isDone := FALSE;
Error := FALSE;
ErrorID := ERR_NONE;
ErrorState := 0;
myTimer(in:= FALSE);
(*Add initialization for other variables and sequences here*)
myState := 10;
END_IF;

10: (* Step 1 of sequence *)
(* Wait for initial input state... *)
IF input1
AND input2
AND NOT input3
AND NOT input4
AND NOT (somethingElse OR thatEither)
THEN
myState := 20;
ELSIF WDErr THEN
(* some watchdog process timeout or something... *)
ErrorID := ERR_WDTIMEOUT;
END_IF;

20: (* Step 2 of sequence *)
(* Activate the thingamajig... *)
output1 := TRUE;
StartWDTimer2 := TRUE;
myState := 30;

30: (* Step 3 of sequence *)
(* Wait for feedback of activation of previous thingamajigger... *)
If input 6 AND NOT input7 THEN
myState := 99;
ELSIF WDErr2 THEN
(* another watchdog timer for the activation of the thingamajigger... *)
ErrorID := ERR_WDTIMEOUT2;
END_IF;

99: (* Done *)
isDone := TRUE;
myState := 0;


ELSE
Error := TRUE;
ErrorID := ERR_INVALID_STATE;
LOG_MSG_INT_INT('INVALID STATE TRANSITION IN %D, %D->%D ', myName, myLastState, myState);

END_CASE;



(*Watch for errors to occur*)
IF myState > 0 THEN
IF ErrorID <> '' THEN
Error:= TRUE;
END_IF;
IF Error THEN
LOG_ERROR_STATE(MYNAME, MYSTATE);
ERR_ADD_TRACEBACK(myName, myState);
ErrorState := myState;
myState := 0;
END_IF;
END_IF

(*Watch for state transitions*)
IF myState <> myLastState THEN
LOG_TRANSITION(myName, myLastState, myState);
END_IF;
myLastState := myState;


Each case statement should be coded like a rung of a ladder, but 'could' have some math or functions or whatever in them, as long as the function isn't blocking or processor-greedy. If another FB of indeterminate duration needs to be kicked off from one of the above case 'states', then the enable input of that FB is merely set to high from that case statement. Any given case then executes quickly, like a rung of a ladder, evaluating to some resolution (or none, meaning on the next scan of the PLC, that same case is evaluated again (and again) to see if a real-world sensor-state has come true, or a user watchdog process has come true instead).
When done without error, this program (or FB) returns to state 0 with it's Done flag set and Busy flag off. State 0 continues executing indefinitely until the enable input is set low and then high again, which resets the Done flag, reinits, and restarts the sequence.

The above is my boilerplate template for a ST state machine.

Jay

I would consider a DC-DC converter to convert the 12V to 24V.

You may also want to look at Beckhoff and TwinCAT for an IEC61131 environment:

http://www.youtube.com/watch?v=l_nFE9wx8OM

At that power level, a DC to DC converter might be a solution. Or even perhaps a DC to AC converter. I realize that you don't have any power to waste with a battery/solar system, but a converter may actually help as it may run over a wider range of voltages than a PLC
letting you tolerate deeper discharge. Also you should actually check the specs for PLC power, many are nominal 24 V but will work at onsiderably lower voltages. And as far as the ladder not being reusable, ladder can be made just about as reusable as anything else if you write it that way. For example, you can have all logic operate on bits (internal coils) and then the assignment to I/O can be entirely different from machine to machine.

Regards

cww

IEC61131-3 does indeed "sound great". The reality though is a bit disappointing. There is no standard version of the IEC61131- 3 "standard". Each implementation from each manufacturer is different. Even different IEC61131-3 products from the same manufacturer can be different from each other. As long as a manufacturer uses a few basic features from the "standard", they can call just about anything they want "IEC61131-3".

It's like saying that "C" and Javascript are compatible with each other because they both use "{" and "}" characters to enclose blocks of code. If Automation Direct changed their IO addressing from "Xx" and "Yx" to "Ix.x" and "Qx.x", they could probably call their product "IEC61131-3 compatible" and have just as good a claim on that as any of the other manufacturers.

If all you want to do is have your existing ladder logic subroutines be more reusable, then what you want is subroutines with formal parameters. The DL05/205/etc. subroutines don't have formal parameters, but they do have fairly deep stacks. You can push the parameters and return values onto the stack. Its not as nice as named parameters, but it works fine.

If you want to write your whole program in Structured Text (ST), then I would have to question why you want to use a PLC at all. You may as well just use a single board computer and write the whole program in 'C', or some other conventional computer language.

Take a look at the PLC's offered by Triangle Research www.tri-plc.com

Although not ST, they support TBASIC (as well as ladder) which allows for a very robust PLC, at a low cost. They are Jumper selectable for 12 or 24v operation.

Software (Java based) is free and contains a simulator for debugging

You could also check out Advantech's ADAM-5510 Series. 10-30VDC power input and programmable in either C or IEC 61131-3, based on the model selected.

http://www.advantech.com/products/ADAM-5000-Series/su b_1-368QIL.aspx

We have a PLC model launched called Nexgenie.
This is a PLC with a 128x164 dot matric white backlit LCD and 4 navigation keys.

The PLC is programmed using CoDeSys V2.6 based IEC61131-3 platform. The PLC has built-in 16 I/Os with 6 HSC channels (including encoder modes), upto 1K bytes of retain data, RTC for independent utility functions.

The LCD is supported with HMI like functions programmed and controlled via PLC logic. This includes 5 fonts, upto 64 screen definitions, variables display and modification, navigation control via both - with and without PLC logic, password protection.

The details can be seen on www.messung.com

Beckhoff has a large range of controllers that use their Twincat IEC 6-1131 software, allow you to use their function libraries or write your own, and have communications libraries/ hardware to communicate with just about anything.

They use modular "slice IO" (their IO blocks used to be produced by WAGO, and are the same cage clamp style). They have hardware and communications libraries for everything from RS232, Modbus, Industrial TCP/IP, profibus, any of the CAN busses (device net too), fiber options, and their own Ethercat for high speed control/motion apps. Twincat will program everything from their small units similar in price to micro PLC's (but include rs232, rs485,CAN ,Ethernet) to full blown multi-core industrial computers integrated with touch panels.

Their ladder editor is a little clunky (the siemens S7-200 micro-win is my favorite ladder editor! I believe codesys writes Beckhoff's) but with the rest of the IEC Languages I use ladder much less, only where it makes sense. If ladder is limiting your applications, you need to learn structured text.

As for the comments on Structured text for only limited applications, once you get used to it you will probably find yourself writing mostly in Structured Text- especially if you have experience with C etc. I use lots of structured text, with ladder and Sequential function chart where they make monitoring/ troubleshooting overall operations easier. The Beckhoff crowd also swears by Continuous Function Chart for a good over all picture of a process, but I have not gotten the hang of that language YET.

I have used Beckhoff devices for connectivity with SQL through their ADS comm. library functions-we have received great support with any question about libraries etc- there are so many their documentation can be a little much, so asking their support guys to point you in the right direction is recommended!

The only problem I have with ST is that no one but a programmer will even attempt to troubleshoot it before calling the author. Usually at 3 AM. It's not a big language, but you do have to know it before that gibberish makes sense.

Regards,
cww

In reply to curt wuollet: I would guess that the majority of people who understand PLCs have never heard of ST, and that more than 99% of those who have heard of it have never seen it (and never will). Anything written in ST may as well be in hieroglyphics as far as most of them are concerned.

While we are talking about difficult to read programs, the one here is my favourite:

http://99-bottles-of-beer.net/language-perl-737.html

That's a real program, if anyone wants to try running it. I'm sure the programmer had a lot of fun writing it. I would hate to be the one who had to troubleshoot it though.

Reminds me of FORTH!

There is also an obfuscated C program contest that produces some impenetrable stuff.

Regards,
cww

I was previously a field applications engineer and PLC programmer for Schneider Electric (Square D/Modicon). One of the biggest surprises I got there when I started on was that they use a TON of structured text. In fact, the Unity Pro Structured Text editor is pretty good with "intellitype" style entry.

The biggest reason they were doing so was for complex array management.. mostly data collection and manipulation (which supports the above post which talked about ST being useful for math).

I guess it really depends on what angle (brand name and training pipeline) you come at the industry from.

I personally use ST as sparingly as possible, especially these days with the AB's and Opto 22's I work with.

Just thought it was interesting to see people who, even today, break out the ole ST editor for most of the program.

If you use the 'ole' ST sparingly and default to Ladder then good luck staying employed in five years.

Robert Trask, PE

If you are suggesting that people who default to ladder logic aren't "moving forward with the times" then I see a point there (albeit quite a generalization), but I hardly think ST has anything to do with that. ST does not have the power or functionality of a modern programming language.

I agree. A lot of examples I have seen of structured text have been text representations of ladder logic. Structured text is limited because it is implemented on scanning PLCs.

KEJR

In the majority of systems I have been involved with we 'default to ladder logic' at the request of the client. The maintainers of the systems are, by and large, plant maintenance personnel who are very capable with ladder logic. I believe that the maintainers can and do understand ST (or with a wee bit of training they will, being the simple language that it is), but ladder meets their needs. They have a lot of experience working with ladder, so why change it.

Take a look at the Schneider Twido Extreme PLC. It is a 12vdc unit and the twidosoft programming environment will allow you to write a program and switch between view in Ladder and Text. It's environmentally sealed (good stuff) but low voltage DC in and out (which may be okay, depending on what devices you control).