Programming DirectLogic 305 PLC's

Automation Direct has a website where you can find manuals and a forum. The forum is at:

best general PLC forum is

I'm familiar with automationdirect's website but the only references to programming that they make in the manuals is when using DirectSoft or a handheld programmer (not suprised). Thanks for letting me know about

it's a great overview of the internal workings of the PLC's, big help.

I still haven't been able to find references to programming the hardware directly, from the PC, without the use of DirectSoft. There was 1 posting in their forums on the subject, but no definative answer. I think it should just be a matter of properly-formatted ascii instructions representing the logic I want, but as to the format and the semantics of talking to the hardware, I'm still unsure.

Thanks for the follow-up!

Why don't you fist learn how to use it the way it is supposed to be used instead of trying to do it some other way? When getting involved in something new it is best to dump one's preconceived ideas.

Walter

Learning DirectSoft is not a problem, but it's not an option for production. The client does not like it, they want a custom front-end application for programming the hardware.

.. and they're willing to pay Big$ to re-invent the wheel?? I wish *we* had clients like that!

Cameron:-)

We're not reinventing the wheel :) If your client is industrial (like a bottle-filling plant), they are probably comfortable with applications such as DirectSoft, because most of the hardware in their facility is industrial-grade.

But imagine you're a theme park and you take a look at DirectSoft, forget it. These folks talk in terms of timelines and events and crossfading curves. All things you *could* pull off with DirectSoft, but manually, very time-consuming, and very expensive. So we are tasked with developing an application that the client is comfortable with, and ultimately downloads instructions to the PLC.

Unfortunately, it seems the PLC world is a completely different animal than the PC world. It should be a matter of sending a string of ASCII across the serial port, representing the logic I want to store. It seems to be much more complicated. I still haven't found anything concrete (neither on the web, nor from manufacturers) that explains the process of "programming" a 205/305 PLC other than to simply "use DirectSoft".

Thanks for that - now we know what you are trying to do. :-)

If it was me, I would work out the *minimum* requirements for the ride and program this into the PLC using DirectSoft (ie. motor interlocks and other basic things required for the ride to operate safely). There may or may not be many of these.

I would then spend my programming time, programming some kind of SCADA front end containing the functions (events, crossfades, etc.) you need and to execute these in the order they require. This SCADA front-end could be an off-the-shelf package you have configured for the ride (quickest solution) or you could write your own in C++ or whatever.

Instead of downloading instructions to the PLC, your front-end software communicates with the PLC (using a serial or ethernet link) using a standard protocol (eg. Modbus) and writes values into internal registers to tell the PLC which event you wish to do next. This way, the client does not need DirectSoft - you do.

I hope this helps. Good luck with your project!

Cameron:-)

I've got to agree with Cameron. PLCs are deliberately meant not to download dynamically modified programs on line. Like you said, it's a different world. To put Cameron's suggestion in a slightly different way:

1 - The PLC contains the fundamental safety program. Don't EVER trust that to the PC. It also contains a set of registers holding PC commands such as start motor, raise ramp, ring bell, etc. These will be executed by the PLC SUBJECT TO SAFETY PERMISSIVES. In this way every reprogramming exercise greatly lessens your liability.

2 - The PC holds the 'recipe' for the ride. It issues higher level commands such as those described above. Try to imagine the worst that could happen if the PC freezes. In fact it may even be a good idea to put a watch dog timer into the PLC to bring things to a safe state if commands stop coming from the PC at regular intervals.

I have done similar things in the past within a DCS where one program held a sequence telling the second program what it wanted done. In one case I even invented a simple 'language' that consisted of valve steps and sequences. The imbedded program then translated these into action. But all of these were subject to safety constraints that were not accessible to the recipe program.

Seriously, if you want non-programmers to operate this you will have to make is idiot proof or you will be assuming their liability.

Walter.