PLC's with free programming software?

J

juan the sparqi

I bought a Jazz Unitronics, and it comes with a free software, in fact the software is available free at their website. this are great training PLCs and are cheap. with integral switch.
 
E

electricfriends

I'm with you. I don't see why I should pay for software that ONLY program's a company's product when I am paying for the product. Seems like a full fledged software available at no cost would boost hardware sales. Slightly off topic, but I have had great success with the Red Lion G3 series HMI panels. The software is 100% free for download... no limited version, no expiration. Software is well designed and simple to use, yet extremely powerful. These HMI's have drivers for about every PLC on the market and can even be used as protocol translators to have one brand of PLC talk to another.
 
J

Jeremy Pollard

It was thought some time ago that software will pull hardware sales... not the other way around.

I will ALWAYS choose hardware (from a control POV) based on their software offerings, which is why I stick to Rockwell (most of the time) My knowledge base wit it is big as well. I find that most IEC-61131 editors are still very 'young' even tho they have been around for a bit. Its all about being able to use the stuff. No flames please - its all what you are used to, but if I had to choose it would be no contest.

If a company (like Automation Direct) had an inexpensive PLC with dynamite software then the landscape changes. Opto is one that is taking the challenge seriously.

Just some thoughts..... and remember you get what you pay for!!

Cheers from :
Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline[.]com
Control Design www[.]controldesignmag[.]com
Manufacturing Automation www[.]automationmag[.]com
 
I agree with Jeremy on this one. I had a mechanical guy give me a bit of crap for buying Robots over Mitsubishi because Mitsubishi had a solidworks simulation plugin that would help them with mechanical layout. In the end I think I spent 10-30 times the amount of time programming, debugging, and maintaining the software with the Epson than they ever did on the mechanical layout, so I really appreciated the superb Epson software. I can't imagine how much more difficult it would be on an inferior system with cryptic commands. (OK, I'm tooting Epson's horn a bit, they make really good automation software for their robots IMHO).

We do use Mitsubishi *PLCs* with the IEC editor and it is leaps and bounds better than straight up traditional ladder. I would have gone with Rockwell many years ago, but their "user instructions" (aka function blocks) weren't in existence back then and we really needed it for our type of programming. Unfortunately the Mitsubishi software is very strange to use, especially for special function cards like motion and communications.

~Ken
 
C

curt wuollet

Hi Jeremy

The problem I have with the "get what you pay for" argument is that some of the most expensive vendors have incredibly crummy software, with AB being the exception, rather than the rule. And it's sad because the testing is so easy. Hook up to a system (freebie, since that can be major PITA) Unplug a sensor or two. Grab a PLC guy off the plant floor towards the end of his shift. Sit him down and see what happens. If he's looking at logic in seconds and and can figure out how to navigate in a minute or two and finds the problem soon, sight unseen, you've got good software. If he screws around with the software, dazzled by 5 or 10 extraneous windows or has to putz with 5 layers of menus, and can't figure out how to force the sensors, fire the programming staff. Then try that with the nearest electrician. I can think of at least two major brands where the software you have to use almost completely obliterates the reason we're using RLL in the first place. If you spend more time screwing around with the software than finding the problem, it fails.

Regards
cww
 
S
LG PLC's are good, cheap, and the software is free, and very good. I'd say 95% of RSLogix quality. Only drawback is that they're just beginning to build a distribution network in the US.
 
Jeremy Pollard said: "remember you get what you pay for!!". So, how much are you charging us for that opinion?

When it comes to small to medium size PLCs, price, distributor network, and inventory tend to be more important to customers than the quality of the software. I don't want to pick on any brands in particular, but I can think of a couple of major vendors whom everyone has heard of who sold a lot of hardware despite having some truly wretched (and expensive) software.
 
C

curt wuollet

That is a very good term for the Mitsubishi software. I've used it quite a bit and a new puzzle pops up every time you have to do something new. It's part of a trend I've noticed supporting several makes, the software seems to be getting worse rather than better. The whole IEC support thing has mostly added a mess to what they had before. I think the "all in one" approach is not the best idea. Individual products that actually fit the particular and diverse workflow might be better. But, from what I've seen, adding The IEC stuff has been a net loss, even if you use it. That is, I think each schema would be better served by a dedicated tool. The RLL tools had settled out to be reasonably consistent, it wasn't a major battle to switch between brands. But, that level of maturity and consensus seems pretty distant from the effort that was supposed to unify everything. But, what do I know, I'm just an out of work PLC guy out in the woods. The really sharp people at the PLC manufacturers must see sublime order where I see only chaos.

Regards
cww
 
D
CWW has a valid point but also misses another definer. Who is it aimed at? AB products are superb especially when aimed at the hard pressed electrician forced into doing control, on the other hand they limit the abilities of a trained instrumentation/Process engineer and therefore Siemens (for example) would be the preferred choice.

Many manufacturers provide Lite or training software at a massively reduced cost or free.

My belief is you should consider the application and the person putting it in, before picking the product
 
Curt,

With the higher end software (function blocks or user instructions) and many levels of encapsulation you can start to make your PLC code a lot more intelligent such that electricians need not tend the programming software upon failure. At the company I work for we have had a long standing tradition of making our software respond when a sensor is unplugged (or a mechanism jams, whatever) and giving detailed messages to the operator. In this way 99% of the time nobody needs to plug a computer into the rack. The way we do this is to have code that handles timeouts, error messaging, user response, all in one tight little function block that gets used on just about every line of code. Your code gets written and tested once and used everywhere.

So in this case I'm not sure your idea of testing good software is valid. It all depends on the environment. I personally think that a system that requires electricians to log in every time there is a problem is a bad idea. I've heard of many cases from friends that the electricians get in and force something or bypass logic to get something running and end up causing long standing problems that nobody can figure out.

I will say, in the spirit of your response that I agree with you that the user interface need not be clunky, complex, or get in your way, and it is frustrating paying $1200 for a trashy software. I think a high school kid could identify the peculiar issues with the user interface for minimum wage. I will say that the feedback from users is quite disappointing though. I belong to another PLC forum in which the people at Mitsubishi listen in on and the comments from experienced users are down right bizarre. A lot of the comments revolve around trying to make the modern, graphical, tag based editors act like a DOS ladder editor
straight out of 1985. So what happens? The vendor provides support for
2-3 ways of doing something and the software suffers.

I don't think IEC is ever going to be interchangeable between PLCs, and I also think the language definitions are clunky and obtuse at times. I simply use the Mitsubishi "GX IEC Developer" (Popular in Europe) software because it has a number of features that the regular "GX Developer" (i.e. normal US release) doesn't have, such as shared libraries, [somewhat hokey] function blocks, and [also hoky] structured text. To quote a Merle Haggard song "It's not love, but its not bad". In other words, compared to modern programming, PLC editors are very lacking. The PLCs, however, still fill a niche until someone comes out with a competing system (it is happening... Although very slowly...). There is also a little bit of security in the big name PLCs. Kind of akin to the old saying about nobody getting fired for buying IBM. How things have changed, but it took a long time.

We are about to embark on using a Delta Tau Power PMAC for total machine control (Motion, logic, HMI). I received a CPU to play with about a month ago but am backlogged on projects. I am both hopeful and cautious at the same time that this could be a very cool and powerful thing. I am planning on doing the machine control using realtime multithreaded C++ to accomplish the equivalent of "function blocks". I prefer text programming and am looking forward to being able to once again use source control and libraries and things like that. The controllers are expensive, but when you compare them to the equivalent of a PLC with motion the cost levels out somewhat. Of course the price per performance advantage is not really measurable but obvious. So far they give away their software, but I think that is just because it is new. I'm sure someone will want to start charging. For $4k per CPU you think they could include the software into the unit price and average it out!

KEJR
 
J

Jeremy Pollard

Reply to MG - true enuff.. free software doesn't HAVE to be bad.. but the support etc and the feature list would probably NOT be up to snuff in a 24/7 operation. My point was to be careful tats all.

is a link that everyone should watch on what really motivates people...

and there is no charge Michael:) as it is only an opinion!!

Cheers from :
Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline[.]com
Control Design www[.]controldesignmag[.]com
Manufacturing Automation www[.]automationmag[.]com
 
J

Jeremy Pollard

To CWW
Guess that was really my point as well .. is that some vendors have bad software, and I cant rely on that interface to complete a project.

Believe I wasn't beguiling free software (I use Firefox, PDF, Linux, etc), but in the industrial world, nothing that's GOOD is free... and it used to be all about the hardware, but now 'generally' speaking its all about the software

Even GM Windsor demanded flowchart programming.... everyone lost their collective shirts due to a bunch of stuff.... albeit 20 years ago.

Hardware has been commoditized.. imagine a PLC for under 100 bucks with the industrial specs you need... unimaginable 15 years ago..:) but if the software doesn't allow you to do the things you need to do then it is 100 bucks wasted..

Informed decisions that's all:)

Cheers from :
Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline[.]com
Control Design www[.]controldesignmag[.]com
Manufacturing Automation www[.]automationmag[.]com
 
J

Jeremy Pollard

To Ken E - thx for the support..:)

Mits is a weird platform but I know many who use it, and its like 20 years ago again - people use what they know, and they will take the pain to learn it because we can ALL learn it...

But why does it always seem to be hard to do??? Because vendors put their R&D dollars into hardware because of the 20 year-old mindset that companies buy hardware.

If Mits had GREAT software, more companies might be willing to take it for a test drive. Even the Beckhoff's and the B&R's of the world might make a bigger dent if they spent more resources on their software. (I'm not saying the s/ware is bad, just that the learning curve is steep, and it doesn't have to be!)

I have used every software package known to man since 1985ish... I wrote a 500 item comparison article for AB software vendors (remember all of them??), and one of the reasons why Rockwell has the best software is because of guys like Dick Hollenbeck and Scott Zifferer, and Canada's own Neil Taylor.

NO other vendor had the 3rd party support and thus the innovation that Rockwell had. Other vendors are now buying and customizing 3rd party IEC editors.. so they are all suffering from the same problems... mediocrity!

OK I'm done now:)

Cheers from :
Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline[.]com
Control Design www[.]controldesignmag[.]com
Manufacturing Automation www[.]automationmag[.]com
 
B
Siemens now allows you to download free programming software for their S7 line. It is somewhat restricted in that it does not support some of the comm modules, and some of the programming stuff that is rarely used anyway, but for everything else it works.

In fact, even AB has dealt with the expensive programming software problem by selling versions of its software for the lower end PLCs at very reduced pricing. They don't support the odd ball languages like ST but almost no one uses them anyway. For the vast majority of users the "lite" versions do all they want and are attractively priced.
 
In reply to Jeremy Pollard: I'll start by saying that was an excellent link. The points it makes would really resonate with anyone who's ever worked for a large enough company.

As for support, the point was about whether or not a PLC company should charge for their programming software. The company is still selling PLCs and so can support their product either way. To a customer, the hardware plus software is a package, and trying to call them independent products is an accounting delusion.

The "no charge" software is actually quite a bit cheaper to produce because your distribution costs are much lower and you don't have to buy third party copy protection systems. Companies that give away their software aren't giving up as much revenue on it as you may think.

As for features, for 95% of AB's or Siemens' customers if you took half the features out of their programming software it would probably make them *better*. Writing a large complex program is easy. You just sit down with a compiler and bang away at your editor. Writing a small simple program that does exactly what people need is what's hard. So yes, expensive software tends to have a lot of features. That isn't necessarily a good thing.
 
C
Hi D

I did consider that point carefully, that is, could these tools be aimed primarily at new automation. Now, as most folks here know, I'm not high on any of the big names, but I do concede that RSLogix, albeit really expensive, has been the high point in usability, so far IMHO. But I have commissioned new works, none very large, and I have been known to put programmer as profession on my tax return and I have also been that harried maintenance guy. And I think those limitations imposed on a "trained instrumentation/Process engineer" are not necessarily a bad thing. I've unscrambled huge bowls of BASIC spaghetti code and programs cobbled together over many years by dozens of programmers, and programs in little known and best forgotten programming languages. Some of the most difficult jobs I have had to do were figuring out what the Hell was going on in programs liberated from those limitations. That's not to say that these programs might not be perfectly clear to the original programmer(s) and, no doubt, there is a document someplace that would brightly illuminate their thinking and make troubleshooting reasonable. But, so far, this type of programming has been, by far, the most effective tool in ensuring that no one else can fix the damn thing in a reasonable amount of time. More effective by far than the feeble locks and "privacy" functions. It takes an extremely objective viewpoint to see the beauty of expression and esoteric elan of such a program when the plant is silent and the entire management team is huddled around where you are trying to appreciate it. It gets back to why we use RLL and indeed, PLCs in general. If the purpose is to obfusticate, some of these bags of blocks and lists of pointers would put the winners of the Obfusticated C contest in awe. Being that harried maintenance guy, however, begins to really, really, suck.

Regards
cww
 
In reply to Ken E: Having basic sensor diagnostics displayed on an operator interface has been common practice for at least the past 10 years, if not longer. However, PLC programs have bugs and diagnostic messages are not always helpful, so it's often up to the night shift electrician to get the machine going again, one way or another. He's the guy left holding the bag when all the engineers have gone home for the day.

Supporting an existing program is not the same thing as writing a new program from a blank piece of paper. He doesn't need to know how how to analyze what a machine needs to do or how to structure the software appropriately. However, he does need to be able to read what is there and possibly fix minor bugs, or at least give the machine enough of a kick in the right bits to get it going again.

For every full time programmer who writes PLC programs for a living, there are at least a dozen electricians who need to use the software occasionally. And they don't just need to use what one vendor is selling today. They need to support everything that is in their plant, no matter who built it or how old it is. I'm a lot more concerned about those people than I am about the guy who only has to look at the program when he first writes it.
 
C
Hi Ken

I can speak to this from the heart, since much of the printing equipment (EU) that doesn't use Siemens, uses Mitsubishi. In fact that's one of the things that cushioned the blow of getting downsized. They, of course, use IEC Developer. I don't know if it's changed, but Mitsubishi will not support IEC developer in the US. And I had to argue with them to buy a copy. I should have taken the hint. The newer releases of GX Developer were a bit bizarre, I wrote that off to cultural differences. But IEC Developer bore little resemblance and to me, seem so illogical that intuition played little part and it had to be learned and memorized by rote. I found it nasty to work with in my situation. I suspect that it was not my particular legion of idiosyncrasies that was the problem, it wasn't flying off the shelves and the name was often preceded by unflattering adjectives when talking to other users, even in polite discussions. On the other hand, I quite agree with the policy of including diagnostics so a sensor failure doesn't require a major effort. And I agree in principle with the function block idea, just not when they are undocumented black boxes so that you can't tell what is supposed to be happening. And yes, I even applaud some of the machine vendors in the degree they were able to make the code tell you what's wrong. But, some of the post processing equipment was so complex, with so many conditionals, that added to the abstraction and black boxes, it's supportability in the real world could only be compared to potted hardware. Yes, you can fix it, it's just not anything like practical to do so. It need not be said that management doesn't like to hear that and probably won't believe that and assumes that your being an idiot or lazy is the _real_ problem. What we need is a way to advance PLC programming without giving away the benefits of using PLCs.

Regards
cww
 
Top