Any Volunteers?

C

Thread Starter

Curt Wuollet

Hi all
After most of a week transferring automation software from several vendors
to the several flavors of monopolyware and the attending aggravation that
should not be a part of just getting a newer laptop to work. And after much
hassle with moving authorizations around and talking to suspicious support
people convinced that I was trying to steal this drek, I am again moved to
action in the hope of alleviating this sorrow and misery.

I want to convince at least one leading PLC manufacturer or relabeler to
at least cooperate with an effort to produce an OSS PLC programming
toolset to run on Linux. A ladder editor, compiler, online viewer, etc.
I had hoped that this would be a reality by now, or at least that there
would be closed software running on Linux, but it seems someone has
to start the ball rolling.

How many folks out there would be interested? I can not commit
deeply on development due to time constraints, but I have thought
things through a little and would be happy to approach those vendors
who would stand to gain the most through such an effort.

Top on the list would be the Automation Direct folks of Koyo. Not
only are they aggressively competing on price and merit, the Koyo
line of PLCs have been prominent in the industry under many and
surprising names and a lot of people are familiar with them and their
predecessors. They are keen on gaining an advantage and this might
well provide it at minimal cost to the company. A win/win proposal.

So, are there enough of you TI, Simatic, GE programmers of yore and
current AD fans who are tired of running other people's software to
at least form a discussion group?

Regards
cww
 
My congratulation and the best of luck for you.
In fact I think is time to get us release from microsoft domain, once for all.
 
B

Bob Peterson

I can't imagine anyone caring enough about the price of AD software at $400 to want to spend the effort to do this open software style. $400 is what - maybe a half a day of someone's time, and a project like this is a multi-thousand hour effort.

AD might be willing to help you get it running on a Linux Windows emulator, and maybe even support it there directly, but I just don't see this as a viable project to take on from scratch. Just not the down side benefit.

I think if you want something OSS, get some guys together who can put together a runtime PLC engine, a RLL editor, I/O drivers, and a debugger/viewer that runs in Linux.

The scope of such a project is probably not much different than you propose and likely to be actually useful.
 
S
That's rich. Franklin Vissarionovich Roosevelt having the gall to dare
talk about "freedom", a word whose definition he DELIBERATELY spat on and
destroyed in the impressionable minds of an entire generation. I dance on
his grave.

Anyway, I'm not much of a byte banger, but I would be more than willing to
be whatever help I can. I've written DF1 drivers, so this is not entirely
new to me, though I would probably be more comfortable trying to come up
with something for AB.

--
Steve Myres, PE
Automation Solutions
(480) 813-1145
 
M

marc sinclair

Hi,
I think at least if we make an effort it may spur the big boys into action,
and the time I spend reporting bugs (that I know won't be fixed) and getting
tokens repaired, and the cash I spend buying the latest version of software
that does nothing more than make previous versions obsolete could all be used
to produce something I could use.

I'm in

Marc Sinclair
--
http://www.germainesystems.co.uk
 
M

Michael Griffin

In reply to Curt Wuollet - I am interested in discussing this to at least see what you have in mind. I had been thinking about attempting something similar by myself this summer. How straight forward this would be though depends upon the target PLC.

My own thoughts though had been along the line of first writing a soft logic PLC interpreter and simulator that is instruction list and memory address compatible with an existing conventional PLC (i.e. as similar as possible, but without worrying about binary instruction code compatibility), and then writing the programming software. Once the programming software was working, it could then be modified to also target the conventional hardware PLC.

The end result would be a soft logic system that closely emulates a conventional PLC, and programming software which can be used for both the soft logic system and the conventional PLC. I think there are a lot of advantages to this approach, which I would be prepared to justify in detail later. One of the reasons though is there would be something useful in the end even if it wasn't possible (for whatever reason) to use the programming software with the conventional hardware PLC. There are additional strategic and tactical reasons for this approach which can be discussed if you are interested.

The other thought I had was that the programming software should be cross platform to make sure it had the widest appeal. I have a few ideas on how to achieve this, but I haven't sketched them out and done the research to see which are the most practical. There were a couple of criteria I felt were important though. One was ease of development and another was to accommodate fast incremental development. The reasons for these were to be able to see some tangible results as early in the development cycle as possible and also to make it easy to add new features one at a time.

I am not sure if we have the same goals in mind, but if not we could at least see what we could do to co-operate on this. I haven't so far taken this any further than thinking about the general requirements. I would like to stick with traditional PLC concepts, and to limit any innovations to making those concepts easier to implement.
 
C

Curt Wuollet

They're actually doing that at MAT/plc. This is a synergistic project to allow folks to work in a rich environment for free rather than working in a poor environment for big bucks. Hard to see the downside. I would gladly specify X rather than AB if X let me get rid of crashes, dll conflicts, service packs, dongles, silly eulas, licenses and all that crud that has nothing to do with my job. More importantly, my productivity with the enormous toolchest Linux supplies compared to the pitiful few tools I have now could only multiply. I spend more time getting the stuff to run than on task And it I naturally want to type at my desk and install with my laptop, it's big bucks or screwing around with a key floppy like 1983. It was an epiphany, Bob, all the hassle and BS I went through to bring up a newer laptop was artificial crap brought on by the software being closed and proprietary, from the mysterious crashes and reboots to the getting ancient floppies to read to transfer authorizations to the blah, blah, blah needs SPx. None of it was necessary or had anything to do with building ladder logic, it was just an expensive and frustrating waste of time.

I'd like to have one ladder editor and within reason, compile the output for AD and AB and GE and Siemens. PLCs are similar enough where this is doable. It's not a huge leap once you have the ladder to produce several slightly different versions of IL You could do that much with no cooperation at all.

Regards

cww
 
C

Curt Wuollet

I would be comfortable with that also. But a lot depends on whether AB would be comfortable with it. Glad to have you interested.

Regards

cww
 
P

PRAN Sammsanti

Dear All,

Upgrading, Upgrading, it is an endless thing. Look at the way OpenSource social is developing software, it might take some time but finally we got something.

I am in.

Cheers,

PRAN Sammsanti
 
Hello,

As for a soft logic PLC interpreter/simulator compatible with an existing PLC, there are already several open-source projects out there doing exactly that, targeting various PLCs and/or the IEC standard. If you start from one of those, you'd only have to do implement program upload/download (and perhaps change the simulator to emulate the actual PLC including all bugs rather than
an idealised version).

Jiri
--
Jiri Baum <[email protected]> http://www.baum.com.au/~jiri
 
C
Excellent! I have been doing a little research and the first big need, an OSS ladder editor may be easier than I'd thought. It seems there are things happening with ClassicLadder, the good guys at NIST have got it grafted into EMC and if we can work with the author we might have the graphics framework to add backends to. Actually ClassicLadder is a long way towards this goal but was aimed at a standalone LPLC rather than a hardware PLC programming tool. Might be some licensing problems though, I need a chance to see if we can get source. And for those to whom freedom is not so important, there is a Windows version it seems.

Regards

cww
 
C
There are a lot of approaches and many efforts going on so, I'm sure there is a lot of common ground to be sought. I was encouraged that NIST made use of ClassicLadder rather than invent their own. For us to really make full use of the OSS advantage it would be good if we can use as much of what is already done as possible and pull people in. If you compare our community working together to each and every automation vendor reinventing the wheel, we should be able to do the job better than they can. Those of us with some time might check out ClassicLadder and what NIST has done and some of the other projects around, There might even be enough stuff to make this a simple integration effort. I've been thinking on how to approach plc makers with a business case.

Regards

cww
 
S
I don't understand. What are they going to do about it if they don't like it? One issue is their lame policy of asking for a software serial number on support calls for HARDWARE.

That's alright. I'm nore than happy to help with a AD based project too. Re: your reply to Mark about a single editor that could produce code for many PLCs. I think the hard part might be stupid ladder rules that differ from brand to brand. For example, AB doesn't allow one shots on branches unless there is an output on the branch. AD, on the other hand, if you have multiple output branches, will not allow contacts on the first branch.

I still think it's doable, with a lot of work. I think someone (in Canada, I think) did this already, or at least had dedicated edirors for different brands of PLC that shared the same UI. I think it may be the company AB purchased and turned into Rockwell Software.
 
M

Michael Griffin

In reply to Jiri Baum - Which open source soft logic interpreters/simulators are compatible with which existing conventional PLCs? I haven't seen any working ones. I have seen several which are based on their own architecture, but that is not what I was referring to. Note I am referring to something that interprets the instruction list directly, not something that compiles it to 'C' source.

Being "compatible" with IEC 61131-3 doesn't mean much, as even a single manufacturer can produce two different product lines which are both "IEC 61131-3 compatible" but which have almost no resemblence to each other. I think being IEC compatible is less important than simply being widely used.

I am interested in an OSS soft logic system that emulates an existing conventional PLC family so that the same PLC program could be run on either with little or no change. An exact emulation of a specific CPU model though isn't necessary. From a PLC programming standpoint it could appear to be just another CPU in the same family. This would make adoption easier as the same PLC program could be used (with little or no change) in either the conventional or soft logic PLC (which reduces the risk of trying it out). It also takes advantage of existing PLC programming skills, documentation (programming manuals), programming software, etc.

As far as "upload/download" is concerned nothing too elaborate is required for a PC based soft logic system. The "upload/download" need only consist of copying (or FTP) a file to or from a particular directory and sending a "restart" signal to the soft logic program. There is no reason this file(s) couldn't be in the original editor source format, and include the symbols and comments (helpful in trouble shooting).
 
D

DAVE FERGUSON

Since there already is a standard for the languages 61131-3 (I think) that defines the programming languages, ladder, stl, function block, etc., the rest is about interface and converters to the different PLCs.

Dave
 
Hello,

Frankly, an editor could probably do a better job of keeping track of such stupid rules than a human can. You'd just write standard ladder, and the editor would rearrange it into whatever vendor-specific contortions are required.

Mostly it would be just standard compiler techniques, except that with ladder you want it to be bidirectional, so that you can load an existing AB program into the universal editor (for instance), preferably without each translation adding more and more code.

Jiri
--
Jiri Baum <[email protected]> http://www.baum.com.au/~jiri
 
C
Well, they could afford to tie you up in court for a couple decades or so. But mostly because it would be a lot easier if they cooperated a bit. You could RE their download/upload protocol but they, of course would immediately jigger a few things so your program doesn't work and release a new version. This is what MS is doing about Samba and OpenOffice and anything else that might compete. And they get the revenue from a forced upgrade. But the time has come, I think for folks to play nice with OSS projects that can only serve to expand their customer base and lower their support burden, That's why a company like AD who has already released some protocols and could use some more notoriety and buzz may well be a better bet. The climate for persuasion is better.

Regards

cww
 
C
Exactly, and specifically with compiling to the form needed to download to the various PLCs and decompiling the upload. This is minimum functionality with online editing being nice if possible. But I could live with the type of process on a Micrologix 1000 or say DL205 if online monitoring can be done. I sent an inquiry to Host engineering who does software for AD to see if data is available. I wouldn't lean too much on the standards as I've seen no two systems that will accept the same program except for very simple stuff. Of course, _we_ might be able to do that, since we're not motivated by lock-in. At least for a reasonable subset.

Regards
cww
 
W

William Sturm

Funny, my Linux experience has been quite the opposite of yours. I spent months trying to get Linux working on an embedded PC project before I threw in the towel and switched back to Windows. In the Windows environment, I had a program running in a few weeks.

The problems in Linux were mostly related to the lack of industrial hardware support. The drivers for Galil and A-B were either out of date or non-existant. Also, the lack of an IDE made it harder, in my opinion. Recovering from power loss situations were also a concern. I let my son use Linux and I had to boot from a CD and run fsck at least once a week.

I am currently using a non-embedded XP setup, which may run headless. I now have my choice of Visual Basic, Visual C++, or .NET and many third party and/or vendor supported drivers. I am hoping to switch to XP Embedded, but I need to evaluate the cost/benefit ratio.

I know that many of the programs that run on Windows have their issues, but I don't see how switching to Linux will solve that.
 
B

Brian E Boothe

are we opening up a open source Continium here <> / for a softlogix
derivitive >? whats the base ? fill me in ,, im in with both feet
 
Thread starter Similar threads Forum Replies Date
M General Software Chat 2
Top