Programming DirectLogic 305 PLC's

Does anyone have information/examples/tutorials/books/etc on programming the DirectLogic family of PLC's (205/305/etc)?
Let me explain my situation: We had originally opted to control the hardware via a PC over ethernet. We would use the KepDirect EBC I/O Server to interface our software with the hardware. That would (in effect) make the PLC "dumb" as it would slave to the PC
The powers that be have since nixed that idea, and have decided to run native from the PLC itself. So this leaves us a couple options. We could use DirectSoft32 (or some other UI) and program that way, and then download the instructions to the PLC.
But I'm looking for a way to use our existing application (UI), and then program the PLC directly, sort of like a customized replacement for DirectSoft32. The idea being, we can create our sequences and logic in our app, and then download to the PLC and run without the PC connected anymore.
Can anyone point me in the right direction? This is my first venture into the world of PLC's. Controlling one via the KepDirect Server is easy enough, but I know nothing of directly programming one.
Thanks in advance!
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Automation Direct has a website where you can find manuals and a forum. The forum is at: http://forum1.automationdirect.com/cgi-bin/Ultimate.cgi The best general PLC forum is www.plcs.net.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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 www.plcs.net 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!
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

.. and they're willing to pay Big$ to re-invent the wheel?? I wish *we* had clients like that!
Cameron:-)
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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".
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

had
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:-)
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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.

*we*
not
front
standard
the
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
A guy on ebay sells active x drivers

had
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.