Which software /language are used to develop the RsLogix-500 or Step-7 type of PLC packages inclusive of its various instructions e.g. timer , counter etc. etc. Is it VC++ or TC++ or Visual basic or the combination of such languages. Please help me to know the same.

With the background of long experiences in the areas of industrial automation and application programm development using RS Logix- 500, Step-5, Step-7 etc. can any one suggest what language I should learn to write program similar to PLC ladder logic so that I can develop the same on a PC and download it using serial port to any microcontroller based remote card to control machine function similar to PLC.

 

> Which software /language are used to develop the RsLogix-500 or Step-7 type
> of PLC packages inclusive of its various instructions e.g. timer , counter
> etc. etc. Is it VC++ or TC++ or Visual basic or the combination of such
> languages. Please help me to know the same.

RSLogix supports on relay ladder logic (RLL), and only the varient used by AB in this particular controller.

Step 7 supports Siemens' implementation of the various IEC languages, one of which is also a variant of RLL, but also includes other that may or may not be found to be useful.

> With the background of long experiences in the areas of industrial
> automation and application programm development using RS Logix- 500,
> Step-5, Step-7 etc. can any one suggest what language I should learn to
> write program similar to PLC ladder logic so that I can develop the same on
> a PC and download it using serial port to any microcontroller based remote
> card to control machine function similar to PLC.

Not really. All PLCs are pretty much proprietary. If you want to learn RLL, the best langugae to use is RLL. It does bear a striking resemblence to boolean algebra for logic functions, if that is of any help.

Bob Peterson

 

Hello, Arup;
For your first question, I believe that there is no high-level language used to develop the PLCs you are referring to; they probably used assembly-language adapted to the micro-processor they used on their CPU. Originally, that could have been a 8085 microprocessor; today they use Intewl x86 and Motorolla chips with their own code.

 

Visual Basic fer sure :^)

Actually, I would be very surprised if it weren't VC++ given their bondage to the monopoly. Perhaps even assembler in some places. One need omly look as far as the APIs to see what goes for the
tools. The more system oriented bits,(non interactive) might be C or assembler. Using anything non-MS would, I'm sure, be problematic with the degree of integration required. I am fond of C myself, but then, I don't program for Windows.

Regards

cww

 

Bondage to the monopoly?

Once again, Curt, I'm forced to go "HUH?" when I'm reading your stuff. Visual C++ 6.0, Visual C++.NET (aka 7.0), and the upcoming 7.1 are nothing more than Microsoft's compiler, debugger, and editor for bog-standard C++, all wrapped together in an IDE. Like many people unfamiliar with the platform, you see the "Visual" and ".NET" and immediately think Microsoft is
pulling an "embrace and extend".

Fact of the matter, the latest version of Visual C++.NET is very standards compliant in both library and compiler performance (perhaps moreso than gcc 3.x), No compiler has yet to reach 100% compliance, and this is acknowledged and documented by all. You want to write platform independent code in Visual C++.NET? Go for it. Use the STL, standard libraries, and text
mode all day long, and you'll be easily able to bounce from platform to platform with few difficulties beyond the usual compiler/library oddities.

As for the "interactive" stuff being "bound to the monopoly", I'm curious as to what they're supposed to do. Crossplatform solutions like wxWindows and FLTK might work for simple apps, but how are you supposed to write a ladder editor for ANY GUI system, Windows, Mac, or Linux, without tying yourself to a platform?

You could complain about their use of Windows COM or .NET based middleware, but once again, you complain without offering an alternative. Then again, you admit that you're not a Windows programmer and only use Windows when forced too, so I'm again, not really sure why you're answering question on Windows based products.

Alex Pavloff - [email protected]
Eason Technology -- www.eason.com

 

It doesn't really matter what languages AB or Siemens used. The application package you are going to write will have to be much smaller if you are going to do this by yourself.

I would suggest to put off your decision of what development language to use until you have outlined a design for your software and decided what operating system(s) you are going to target. The software design should tell you what language features and libraries you are going to need. You can then compare this list against what is available on the market. If you have a limited cash budget for this project, your choice of development software is going to be narrowed considerably by that fact.

You haven't stated what the objectives of this project are - whether this is a commercial venture, or just an educational hobby. This makes a difference since in the latter case the process of learning is more important than the end result.

If your objective is to develop a commercial product, I'm not sure what else to tell you. If your objective is educational, then the real question should be what language would you like to learn? You could do what you want with virtually any language, the difference will be in how easily you can do it, and whether the language features assist or hinder you in following proper software design practices.

************************
Michael Griffin
London, Ont. Canada
************************

 

Dear Bob,
Thanks for the messages. Can you provide any online resources for RLL languages. I don't know RLL.The RSLogix-500 etc.appears to be Windows based.Can you elaborate the subject for better understanding.
Arup

 

To Michael Griffin, et al:

I agree with your commentary. Microsoft
has been doing some embedded CE op system
work and will no doubt have some significant
realtime SDKs to experiment with.

Anyone wishing to do some PLC style development
should search microsoft.com for details and
beta privileges.

Mike.

 

My guess would be VC++, but you can write a application package in the language of your choice. The trick is going to be talking to the PLC, your going to need a different driver for each Brand/Product Line of PLC. As far as what language you should learn, I would suggest VB or VC++. Check out "INGEAR" activeX control at www.softwaretoolbox.com they have software to connect VB & VC++ applications to most of the well known PLCs (I know they have a version that will support AB's "SLC" line). There Licensing is on a "Per developer" basis, so that you can write and distribute as many different compiled applications as you want, each one becomes a stand-alone Application. The package lists for about $1,000. I am thinking of using it for a few applications were I need to display a few peices of data from a Modicon PLC on a field PC but can't justify another HMI license.

 

Are you asking what the programming package is written in or what the actual SLC 500 firmware is written in? Are you just trying to write the programming package on your own so you can program SLC 500's? Is this for creating another programming package to compete with RSLogix? I can answer your questions better with more information.

 

Hi Alex

> Bondage to the monopoly?
>
> Once again, Curt, I'm forced to go "HUH?" when I'm reading your stuff.
> Visual C++ 6.0, Visual C++.NET (aka 7.0), and the upcoming 7.1 are nothing
> more than Microsoft's compiler, debugger, and editor for bog-standard C++,
> all wrapped together in an IDE. Like many people unfamiliar with the
> platform, you see the "Visual" and ".NET" and immediately think Microsoft is
> pulling an "embrace and extend".

Gee Alex, I tried to install VC++ on my Linux box without success, even though it said something about WME or better :^) I can install GCC on Windows if I should ever desire, and the rest of the tools _I_ use will also run on multiple partforms, including the QT stuff, I believe. Not "write once, run anywhere" but certainly more portable than an app written for Windows with MS tools. But, don't take my word for it, there are now apps that have a common code base. Check which side of the fence the developement tools came from. Regardless of my opinion, you will note that very, very, few apps are ever ported from Windows to Linux, Even large ISPs find this so difficult that they go the WINE route. This killed Corel. Their native port to Linux was a pretty good if immature, product. The "common code base" product, (Windows first, of course) was a non-starter.

> Fact of the matter, the latest version of Visual C++.NET is very standards
> compliant in both library and compiler performance (perhaps moreso than gcc
> 3.x), No compiler has yet to reach 100% compliance, and this is acknowledged
> and documented by all. You want to write platform independent code in
> Visual C++.NET? Go for it. Use the STL, standard libraries, and text
> modeall day long, and you'll be easily able to bounce from platform to
> platform with few difficulties beyond the usual compiler/library oddities.

But, try to produce a competitive Windows product writing code that will compile somewhere else. It's not the compilers or the IDE, A very large proportion of the "working set" in a Windows application is secret and binary only. I would expect that user code and the standard libraries would be no more than 25% at most. This is not how you segment things to enhance or even permit portability. This is a "feature" of their vast monolithic design, intentional or not. Contrast this to a Linux GUI app where the vast majority of the components are not built into the kernel. In fact, those components are not only segregated, but are OSS and can be ported almost anywhere, even Windows. Of course, the efficiency would kinda suck on Windows as you would still have to use their APIs to do anything.

> As for the "interactive" stuff being "bound to the monopoly", I'm curious as
> to what they're supposed to do. Crossplatform solutions like wxWindows and
> FLTK might work for simple apps, but how are you supposed to write a ladder
> editor for ANY GUI system, Windows, Mac, or Linux, without tying yourself to
> a platform?

Watch closely. It will be happening soon. Actually, it is much easier if you start with that idea in mind than if you are locked in to Windows already. But, you actually helped make my point. _Why_ are wxWindows and FLTK only adequate for simple apps? It's because you can only get at the stuff you need for a competitive Windows app with MS tools. This is what binds you to the monopoly. This is why MS has spent (b?)millions fighting off Java and anything else that smells portable. Portable between Windows and Linux is a big problem. Portable between Linux and anything else is trivial in comparison. What does that tells us?

> You could complain about their use of Windows COM or .NET based middleware,
> but once again, you complain without offering an alternative.

I have, but .NET may well be too late. Too many people are onto what MS is attempting with .NET. As far as COM, I have, in these very pages, offered an alternative in a very simple universal memory mapping scheme. If it's the best alternative in the world or the worst makes absolutely no difference, because as long as people are in service to MS, they can only use MS solutions. That's why your argument is the "let them eat cake" argument, Any other solution is simply impossible unless Microsoft builds it in. So far they have been less than receptive to Open, universal, portable, solutions. But, I'll email Bill again if you want.

Then again,
> you admit that you're not a Windows programmer and only use Windows when
> forced too, so I'm again, not really sure why you're answering question on
> Windows based products.

Because I was fairly sure I knew the answer and I wanted to help. And I have the greatest motivation to be a concerned party. I have the perspective to see what's going on. And I'd like to be able to do automation without the products of a convicted, predatory, monopoly. You see, none of the individual pieces is badly warped, but they all fit together to ensure that, once you start down the MS path, you have little practical choice but to continue. I think that justifies my use of the term "bondage", in line with Webster's definition. Many, of course, would prefer not to see it that way, but, what else would you call it? And as long as this continues, it effectively inhibits the sort of modular, Open, software that is really ideal for automation. And that's what I'm interested in.

Regards

cww

> Alex Pavloff - [email protected]
> Eason Technology -- www.eason.com

 

On March 18, 2003 03:24, Mike wrote:
<clip>
> To Michael Griffin, et al:
>
> I agree with your commentary. Microsoft
> has been doing some embedded CE op system
> work and will no doubt have some significant
> realtime SDKs to experiment with.
>
> Anyone wishing to do some PLC style development
> should search microsoft.com for details and
> beta privileges.
<clip>

I'm not sure you really do agree with me. I advised Arup Basu to postpone shopping around for development software until the system design was more clearly defined. I am of the impression that the project is quite preliminary at this point. There is a lot of work to be done in a project like this before you have to worry about actually writing any software.

Even more to the point, when someone is asking what programming language they should learn (as stated in the original message), I really don't think they want to be looking at "beta privileges" on Windows CE.


************************
Michael Griffin
London, Ont. Canada
************************

 

On March 18, 2003 04:29, Curt Wuollet wrote:
<clip>
> Portable
> between Windows and Linux is a big problem. Portable between Linux
> and anything else is trivial in comparison. What does that tells us?
<clip>

That sounded interesting, until I realised that I can't think of a current "anything else" operating system that runs on a general purpose computer which isn't just another form of Unix (excluding the odd mainframe running ancient COBOL programs). So, you are essentially telling us that portability between different versions of Unix is comparitively easy. That is good to know, but not particularly profound.


************************
Michael Griffin
London, Ont. Canada
************************

 

> From: Curt Wuollet
>
> Hi Alex
>
> Gee Alex, I tried to install VC++ on my Linux box without success, even
> though it said something about WME or better :^) I can install GCC on
> Windows if I should ever desire, and the rest of the tools
> _I_ use will also run on multiple partforms, including the QT stuff, I
believe.

GTK 2.x doesn't run very well on Windows at all. Trolltech's QT tooklit is cross platform, but that's because well, its by a company (Trolltech) that does that sort of thing. Also, QT has their own special macro preprocessor (moc) that makes all C++ code non standard! Horrible! It ties you to their platform! (gtkmm is much better at this, by the way). Also, if you want to use Qt to write a Windows app, well, you can, but it requires Visual Studio 6 and is binary only (for non commercial use). To distribute an app, you need to fork over cash. So no, that doesn't meet your preferred guidelines for free software use. Sorry. You'd better start writing your gui apps in wxWindows.

> Regardless of my opinion,
> you will note that very, very, few apps are ever ported from Windows
> to Linux, Even large ISPs find this so difficult that they go the WINE
> route. This killed Corel. Their native port to Linux was a pretty good
> if immature, product. The "common code base" product, (Windows first, of
> course) was a non-starter.

I'm trying to think of gui apps that have been ported from Unix (any variant) to Windows. Can't think of any off the top of my head. I have seen quite a few expensive apps that have their command line tools ported from Unix though, but that's relatively easy. Cross platform development is hard, irregardless of where and which way you're trying to go. As stated earlier, Qt is proprietary on all platforms save Linux, and gtk doesn't work worth a damn on Windows. FLTK is stale. wxWindows is probably the best choice of all, but even then it suffers in its range of controls compared to any of the native toolsets.

As for Office Apps Other Than Microsoft Office Being Dead In The Marketplace, that has nothing to do with technology.

> But, try to produce a competitive Windows product writing code that will
> compile somewhere else. It's not the compilers or the IDE, A very large
> proportion of the "working set" in a Windows application is secret and
> binary only.

I have an entire 100,000+ line windows app right here in front of me. While I don't have the source to the guts of Windows, I do have all the source for MFC (because that all comes with an install of Devstudio) and ATL (which is just a big template library), and I have yet to run across any "secret" function calls that cause problems or hit any problems that I have been unable to solve. The documentation is quite good, thank you very much.

I have the source code for the parts that I need to fix, and everything else works as documented. Wearing my Windows programmer hat, life is good. Its about the same as wearing my Linux programming hat, except I'd have to say the Visual Studio 6 debugger is a little better than gdb.

>I would expect that user code and the standard libraries
> would be no more than 25% at most. This is not how you segment things to
> enhance or even permit portability. This is a "feature" of their vast
> monolithic design, intentional or not. Contrast this to a Linux GUI app
> where the vast majority of the components are not built into
> the kernel.

And you get this 25% figure from... where? How do you calculate this? Do you could all dynamically linked libraries? The entire Windows kernel? GDI? What? Besides, having the source code for Xfree86 and the Linux kernel doesn't exactly help me debug my gtkmm app, you know. Most of my Windows GUI app isn't "built into the kernel either". Yes, I don't exactly have the source that tells me how my truetype font is being drawn onto the screen. It works as described. Good enough for me.

>Contrast this to a Linux GUI app
> where the vast majority of the components are not built into
> the kernel.
> In fact, those components are not only segregated, but are OSS and can
> be ported almost anywhere, even Windows. Of course, the
> efficiency would
> kinda suck on Windows as you would still have to use their APIs to do
> anything.

What, you mean do you don't use APIs on Linux? You write to the bare metal on Linux? No you don't. If you're not insane, you write to a toolkit (motif, qt, gtk, whatever), because in my experience, I find that writing raw X calls is more sucky than writing raw windows GDI calls. However, I do neither (I use gtkmm and MFC). Or are you implying that performance is worse? I have 2 identical machines on either side of my desk. One runs Windows 2000. The other one runs Redhat 8. Quite frankly, GUI performance on one isn't any better than the other.

> Watch closely. It will be happening soon. Actually, it is much easier if
> you start with that idea in mind than if you are locked in to Windows
> already. But, you actually helped make my point. _Why_ are wxWindows and
> FLTK only adequate for simple apps? It's because you can only
> get at the stuff you need for a competitive Windows app with MS tools.

Curt, its amazing how much you think you need Microsoft for, when you don't even do any Windows development. If I decided tommorow that I hated Visual Studio, I could turn right around and use, say, Codewarrior or C++ Builder or heck, rewrite my app in Delphi or one of the other products that lets me do excellent development on Windows. I could go any buy third party components from numerous companies that kick ass. Yes, I'd have to spend money. Life is hard that way sometimes.

> This is what
> binds you to the monopoly. This is why MS has spent (b?)millions
> fighting off Java and anything else that smells portable. Portable
> between Windows and Linux is a big problem. Portable between Linux
> and anything else is trivial in comparison. What does that tells us?

No, its not. I can't port arbitrary gui apps from Linux to Windows. Sorry. Waving the magic open source wand doesn't make porting issues go away. A "well, it would be possible to port xyz toolkit and abc app from Windows to Linux" doesn't actually make this happen. As you should know too well, you can promise the moon with open source, and you're right, anything is possible, but unless you put your time into programming the thing, all you're going to end up with is a pre-alpha project on sourceforge that helps no one.

> You see, none of the individual pieces is badly warped, but they all
> fit together to ensure that, once you start down the MS path, you have
> little practical choice but to continue.

Horsepuckey. Its possible to develop for Windows with Microsoft tools and maintain indepedence. There are thousands of third party components available for Windows platforms. Heck, I could pick up Codewarrior or Borland C++ Builder and do all my MFC/ATL development all day long with no ill effects. At the same time, its probably not worth it to attempt to develop cross-platform GUI tools when all your customers run Windows in the first place.

Basically, Curt, while you can answer questions left right up down backwards forwards about using Linux in automation and other places, I really wish you wouldn't try to answer Windows programming questions because, well, you give inaccurate answers and add in the "Microsoft sucks" subtext whenever you can.

Alex Pavloff - [email protected] Eason Technology -- www.eason.com

 

Dear Michael,
Thanks for your reply.
Well, basic objective of the 2nd.part of my question was to use 'microcontroller card' instead of PLC for low value machine to reduce cost.
I wanted to write logics using some suitable language (C++ or TC++ or VC++ etc) and load the same into the microcontroller card and use it's I/O's suitably to control the machine as per logics, sequentially, similar to PLC. It will be just a dedicated black box to do a specific task.

Why I wanted to know the 1st.part of my question was that if at all I can write such logics and use the same as stated above, as a 2nd step, how I it can be made little flexable or users friendly.

>From various comments I understand that the platform/constituents of RSLogix-500 type of package is not an easy subject to understand. There are lot of grey areas. This may be written in assembly language related with the the specific processor used with the particular PLC model/series, unknown editor or technique to represent the codes in lad diagram,unknown language to make it very much flexable and users friendly etc. etc and is made to monopolise the product.

I therefore dropping the idea to reveal the technology but still being an application programmer using RSLogix-500, I will always be keen to know what is it all about.

I hope, I can explain Mr.Dave also regarding my questions.

Thank you once again
Arup

 

Hear, hear!

And I think that a RLL development system as a first project is pretty optomistic and ambitious as well.

Regards

cww

 

Hi Michael

No, it isn't profound at all, but, it is still the truth. And the portability is there by deliberate design and intent. To be most charitable, MS at least ignored the portability issue. However, I tend to discount ignorance in this instance. In fact, If one were to design for the least chance of portability, a closed monolith with structure specific APIs would come pretty close. Many criticize the X system, etc. and modularizing everything. But it is design _for_ portability and there's hardly a platform it doesn't already run on. And the rest of the system will run just fine without it when you _don't_ need a GUI. And you can shed almost everything you don't need for a given application yet still have portability. For example, serial to Ethernet gateways have been a frequent topic and need here lately.A headless Linux gateway app will run on a kernel with only networking and utils on a tiny Dragonball or StrongArm SBC or on an IBM sys 360 with 50 full blown instances of Linux. Or nearly any processor family and system size in between. And it would port fairly easily to FreeBSD or AIX or Solaris or QNX. And, I can legally send you and a hundred of your customers a bootable CDROM with the app setup and ready to run with Linux included, with my compliments, for the cost of the media. Or, it will fit on a floppy for those who are hardware challanged. That's pretty fair portability. Or I could build, legally, an extremely concise distribution of Linux specifically tailored to the needs of the Automation market with no bloat, yet allow people to install whatever they desire or meets their needs from any of the other distributions.

That's why it feels like bondage that I can only do Windows if I want to work with PLCs. And with the next version, you won't even be able to _legally_ open an Office document on anything but a Windows machine. Now that's profound.

We are talking about the opposite extremes of portability.

Regards

cww

 

Hi Alex.

[email protected] wrote:
> ------------ Forwarded Message ------------
> From: Alex Pavloff
>
>>From: Curt Wuollet
>>
>>Hi Alex
>>
>>Gee Alex, I tried to install VC++ on my Linux box without success, even
>>though it said something about WME or better :^) I can install GCC on
>>Windows if I should ever desire, and the rest of the tools
>>_I_ use will also run on multiple partforms, including the QT stuff, I believe.
>
> GTK 2.x doesn't run very well on Windows at all. Trolltech's QT tooklit is
> cross platform, but that's because well, its by a company (Trolltech) that
> does that sort of thing. Also, QT has their own special macro preprocessor
> (moc) that makes all C++ code non standard! Horrible! It ties you to their
> platform! (gtkmm is much better at this, by the way). Also, if you want
> to use Qt to write a Windows app, well, you can, but it requires Visual
> Studio 6 and is binary only (for non commercial use). To distribute an app,
> you need to fork over cash. So no, that doesn't meet your preferred
> guidelines for free software use. Sorry. You'd better start writing your
> gui apps in wxWindows.

But my tools are portable, free, and work well everywhere except Windows. Let's stick to the point.

>
>>Regardless of my opinion,
>>you will note that very, very, few apps are ever ported from Windows
>>to Linux, Even large ISPs find this so difficult that they go the WINE
>>route. This killed Corel. Their native port to Linux was a pretty good
>>if immature, product. The "common code base" product, (Windows first, of
>>course) was a non-starter.
>
> I'm trying to think of gui apps that have been ported from Unix (any
> variant) to Windows. Can't think of any off the top of my head. I have
> seen quite a few expensive apps that have their command line tools ported
> from Unix though, but that's relatively easy. Cross platform development is
> hard, irregardless of where and which way you're trying to go. As stated
> earlier, Qt is proprietary on all platforms save Linux, and gtk doesn't work
> worth a damn on Windows. FLTK is stale. wxWindows is probably the best
> choice of all, but even then it suffers in its range of controls compared to
> any of the native toolsets.

But, why _can't_ anyone who isn't an MS partner do well with Windows? It certainly isn't my fault. Or yours. And many vertical GUI apps have gone from UNIX to Windows. There never was much shrinkwrap for UNIX. StarOffice/OpenOffice and Netscape/Mozilla come to mind as crossplatform but they were pretty much snuffed in the MS world and are now coming from the other side.

> As for Office Apps Other Than Microsoft Office Being Dead In The
> Marketplace, that has nothing to do with technology.
But has much to do with monopolies.

>>But, try to produce a competitive Windows product writing code that will
>>compile somewhere else. It's not the compilers or the IDE, A very large
>>proportion of the "working set" in a Windows application is secret and
>>binary only.
>
> I have an entire 100,000+ line windows app right here in front of me. While
> I don't have the source to the guts of Windows, I do have all the source for
> MFC (because that all comes with an install of Devstudio) and ATL (which is
> just a big template library), and I have yet to run across any "secret"
> function calls that cause problems or hit any problems that I have been
> unable to solve. The documentation is quite good, thank you very much.
>
> I have the source code for the parts that I need to fix, and everything else
> works as documented. Wearing my Windows programmer hat, life is good. Its
> about the same as wearing my Linux programming hat, except I'd have to say
> the Visual Studio 6 debugger is a little better than gdb.

Can you run it anyplace else?

>
>>I would expect that user code and the standard libraries
>>would be no more than 25% at most. This is not how you segment things to
>>enhance or even permit portability. This is a "feature" of their vast
>>monolithic design, intentional or not. Contrast this to a Linux GUI app
>>where the vast majority of the components are not built into
>>the kernel.
>
> And you get this 25% figure from... where? How do you calculate this? Do
> you could all dynamically linked libraries? The entire Windows kernel?
> GDI? What?

Working set refers to the code that resides in core while an app is running. It is an estimate as I haven't seen tools for Windows. Shared libs do complicate things, perhaps it's a bad metric. What I'm trying to get at is how much of the app is portable. Let's just say that a lot more of your windows app is windows code and not portable by virtue of being binary only. More of what is running in a Linux app is in portable OSS parts not strictly part of Linux.

> Besides, having the source code for Xfree86 and the Linux
> kernel doesn't exactly help me debug my gtkmm app, you know. Most of my
> Windows GUI app isn't "built into the kernel either". Yes, I don't exactly
> have the source that tells me how my truetype font is being drawn onto the
> screen. It works as described. Good enough for me.

But is it portable?

>
>>Contrast this to a Linux GUI app
>>where the vast majority of the components are not built into
>>the kernel.
>>In fact, those components are not only segregated, but are OSS and can
>>be ported almost anywhere, even Windows. Of course, the
>>efficiency would
>>kinda suck on Windows as you would still have to use their APIs to do
>>anything.
>
> What, you mean do you don't use APIs on Linux? You write to the bare metal
> on Linux? No you don't.

I can if I want to. I can write to SVGAlib or X or Qt or even write directly to the framebuffer. The low level ones would be non-portable of course, except to 100 or so other versions of Linux at the source code level.

> If you're not insane, you write to a toolkit
> (motif, qt, gtk, whatever), because in my experience, I find that writing
> raw X calls is more sucky than writing raw windows GDI calls. However, I do
> neither (I use gtkmm and MFC). Or are you implying that performance is
> worse? I have 2 identical machines on either side of my desk. One runs
> Windows 2000. The other one runs Redhat 8. Quite frankly, GUI performance
> on one isn't any better than the other.

What I was implying is that you will add another layer as you use the windows stuff no matter what. I doubt that would be as efficient as a native app.

>
>>Watch closely. It will be happening soon. Actually, it is much easier if
>>you start with that idea in mind than if you are locked in to Windows
>>already. But, you actually helped make my point. _Why_ are wxWindows and
>>FLTK only adequate for simple apps? It's because you can only
>>get at the stuff you need for a competitive Windows app with MS tools.
>
> Curt, its amazing how much you think you need Microsoft for, when you don't
> even do any Windows development. If I decided tommorow that I hated Visual
> Studio, I could turn right around and use, say, Codewarrior or C++ Builder
> or heck, rewrite my app in Delphi or one of the other products that lets me
> do excellent development on Windows. I could go any buy third party
> components from numerous companies that kick ass. Yes, I'd have to spend
> money. Life is hard that way sometimes.

And they will technically layer on top of the windows stuff also.

>
>>This is what
>>binds you to the monopoly. This is why MS has spent (b?)millions
>>fighting off Java and anything else that smells portable. Portable
>>between Windows and Linux is a big problem. Portable between Linux
>>and anything else is trivial in comparison. What does that tells us?
>
> No, its not. I can't port arbitrary gui apps from Linux to Windows. Sorry.
> Waving the magic open source wand doesn't make porting issues go away.

Between two OSS systems it does. That was my point. And if MS allowed the same degree of access, the porting issues could at least be addressed.

> "well, it would be possible to port xyz toolkit and abc app from Windows to
> Linux" doesn't actually make this happen. As you should know too well, you
> can promise the moon with open source, and you're right, anything is
> possible, but unless you put your time into programming the thing, all
> you're going to end up with is a pre-alpha project on sourceforge that helps
> no one.

That's an interesting perspective. I would say that in aggregate, all the OSS projects on sourceforge and elsewhere have already radically altered the present and more so, the future. And this has helped many people. We each do what we can. Automation is a very hard nut to crack Few populations are so thoroughly locked in.

>
>>You see, none of the individual pieces is badly warped, but they all
>>fit together to ensure that, once you start down the MS path, you have
>>little practical choice but to continue.
>
> Horsepuckey. Its possible to develop for Windows with Microsoft tools and
> maintain indepedence. There are thousands of third party components
> available for Windows platforms. Heck, I could pick up Codewarrior or
> Borland C++ Builder and do all my MFC/ATL development all day long with no
> ill effects. At the same time, its probably not worth it to attempt to
> develop cross-platform GUI tools when all your customers run Windows in the
> first place.

Yes, we do need to fix that.

>
> Basically, Curt, while you can answer questions left right up down backwards
> forwards about using Linux in automation and other places, I really wish you
> wouldn't try to answer Windows programming questions because, well, you give
> inaccurate answers and add in the "Microsoft sucks" subtext whenever you
> can.

Sorry Alex, but having no good OS choices at work really bugs me. It may eventually drive me away from automation altogether. But, I'll do what I can to change it first. For everyone's freedom and to advance the state of the art.

Regards

cww

>
> Alex Pavloff - [email protected]
> Eason Technology -- www.eason.com

 

On March 19, 2003 02:40, arup Basu wrote: <clip>
> Dear Michael,
> Thanks for your reply.
> Well, basic objective of the 2nd.part of my question was to use
> 'microcontroller card' instead of PLC for low value machine to reduce cost.
> I wanted to write logics using some suitable language (C++ or TC++ or VC++
> etc) and load the same into the microcontroller card and use it's I/O's
> suitably to control the machine as per logics, sequentially, similar to
> PLC. It will be just a dedicated black box to do a specific task.
>
> Why I wanted to know the 1st.part of my question was that if at all I can
> write such logics and use the same as stated above, as a 2nd step, how I it
> can be made little flexable or users friendly.
<clip>

I assume that your microcontroller board will use a low cost 8 bit micro and have a low chip count, since your board is going to have to be very cheap to meet your objectives. Given this, we can make a few design assumptions.

First, there will be two pieces of application software involved. One will be something (either an interpreter or a simple loader) which will reside permanently on the board. The other will be some sort of development software which will run on a PC, and which people will use to create the programs for the machine they actually want to control.

The first program could be either an intepreter, or a loader. For an interpreter, you will have to define a small simple programming language. This could be a simplified form of the instruction list (IL) you see defined for many types of PLC. Have a look at some PLC instruction sets for what these look like. You won't need a large instruction set, so you would need to pare any list you may see down to the minimum number you need to have it function (most commercial PLCs have a lot of instructions that are very seldom used).

The ladder programming software package which you would write would allow the user to create the PLC program which gets downloaded to your micro (PLC). I am assuming you want to download the program through a serial port. The interpreter would read this program in and execute it, along with whatever else has to be done in your system (reading and writing I/O, updating the watchdog timer, passing debugging information out the serial port, etc.).

Instead of an interpreter, you could just have a loader which accepts the downloaded program and starts it running. In this case though, the downloaded program is just actual machine code which your programming software generated. In this case, the only difference between using a 'C' compiler and using your ladder software would be how the program looked on your computer screen.

Both approaches would work, and both have their advantages and disadvantages. I haven't done either myself, so I couldn't honestly give you a recommendation as to the best approach for you. Note that in either case your board does not need an operating system provided your intepreter or loader can provide all the features you need without it. For a simple system, an operating system would likely be more trouble than it is worth, as well as adding considerably to the cost.

The second part of your project would be the programming package which people would use to create their machine control program. This would have at least two parts. The first would be the editor which allows the user to draw their ladder diagrams on the screen. The second part would the logic which translate these ladder diagrams into the instruction list programming language which you have designed. Keep in mind that "ladder" is just how it looks on the computer screen. The "real" program is always some form of instruction list (IL).

If you designed your PLC as an interpreter, then you simply download the IL program down to the board (you obviously have to write some sort of downloader for this). You may wish to check the IL program, or do a bit of pre-processing on it before you download it, but you can decide on this later.

If you designed your PLC to run straight machine code, then you need to have something which will translate your IL program into machine code (i.e. you have to write a compiler or assembler) before you download it.

The above is the theory of this sort of thing as I understand it. I haven't done a project like this myself, so I can't give you too much advice on the practical aspects of it. I think you can see though why it doesn't matter what programming language Siemens or Rockwell used for their software. Knowing what they used wouldn't answer any of the real questions which you have to solve.

************************
Michael Griffin
London, Ont. Canada
************************

 

> But my tools are portable, free, and work well everywhere except
> Windows. Let's stick to the point.

No Curt, they're not. Did you read my point? Qt, your GUI toolkit of choice, is not free (speech OR beer) on Windows.

> But, why _can't_ anyone who isn't an MS partner do well with Windows?

I was not aware Borland or Metrowerks were Microsoft partners, yet they seem to do well with Windows.

> It certainly isn't my fault. Or yours. And many vertical GUI apps have
> gone from UNIX to Windows. There never was much shrinkwrap for UNIX.
> StarOffice/OpenOffice and Netscape/Mozilla come to mind as crossplatform
> but they were pretty much snuffed in the MS world and are now coming
> from the other side.

> But has much to do with monopolies.

Yes Curt, we know. If we want to know about your opinions on monopolies we can go read Slashdot for 5 minutes.

> Can you run it anyplace else?

No, but my customers don't run anything besides Windows on the desktop, so who cares?

> > And you get this 25% figure from... where? How do you
> calculate this? Do
> > you could all dynamically linked libraries? The entire
> Windows kernel?
> > GDI? What?
>
> Working set refers to the code that resides in core while an app
> is running. It is an estimate as I haven't seen tools for Windows.

So you made the number up.

> More of what is running
> in a Linux app is in portable OSS parts not strictly part of Linux.

Here's the problem.

OSS != Portable. You are under the impression that the two are equal. They're not.

> But is it portable?

No, but my customers don't run anything besides Windows on the desktop, so who cares?

> I can if I want to. I can write to SVGAlib or X or Qt or even write
> directly to the framebuffer. The low level ones would be non-portable
> of course, except to 100 or so other versions of Linux at the source
> code level.

X is an API.
QT is an API.

Over the last 5 years using various flavors of Linux/Xfree86 and Windows, Linux/X has been slower and much worse than Windows as a GUI environment. I've used both systems. You haven't.

> What I was implying is that you will add another layer as you use the
> windows stuff no matter what. I doubt that would be as efficient as
> a native app.

You think writing X or QT calls means that you have a native app?

<snip rest of the post>

Curt, its obvious you haven't done much GUI development or Windows development. As usual, you're spouting FUD (Windows is slow! Microsoft is evil! Open source magically makes the world a better place!), and I have neither the time nor desire to argue with a zealot that doesn't even care to get the facts on the opposite side of their point correct.

>Sorry Alex, but having no good OS choices at work really bugs me.
>It may eventually drive me away from automation altogether. But,
>I'll do what I can to change it first. For everyone's freedom and
>to advance the state of the art.

Reposting slashdot rants does nothing for freedom, advancing state of the art, or changing anyone's mind. Get off the soapbox, go write some code, come back when you have an alternative.

Alex Pavloff - [email protected]
Eason Technology -- www.eason.com