Let's design the Ideal PLC!

[Terry Woods]

Hey! It's the Internet! All of us can voice our opinions on what makes a reasonable PLC! Think in terms of... "What if...".

With that in mind, how would YOU develop the "Ideal PLC" to be programmed and configured?

That is... If YOU were developing the design-spec for a new PLC, what would YOUR spec include?

I will add (impose?) one consideration... "WE", the programmers, i.e., the USERS, are HUMAN! And as such, "WE", the HUMAN-USERS, tend to think in terms of Base-10!

So... how would YOU spec your new PLC?

Think very carefully about this before "Shootin' from the hip!"

What is the most "Natural" and "Intuitive" way to think when it comes to Process Control? And, how can that be applied to PLCs?

The basic idea here is... what does it take to make the PLC predisposed to think more like "WE" do?

As a side question... Are there cases where "machine-think" might be better than "human-think"?

[darrenj]

First suggestion..Tag based programming..I love it!! AB and rslogix 5000 did that right..

Lots of other ideas..just cant get them from the head to the keyboard :banghead:

[CroCop]

Tag based
Text available
For loops, while loops, etc.
Built in function blocks
User defined function blocks
Motion control seamlessly
Ethernet programming is a must (preferrably with a gig connection)
Process control that is flow chart based (I like flow chart sometimes)
I'll add to this.

[Doug_Adam]

1, Standard PC connection type. No special adaptors. In the past, this would have been a straight serial connection such as the Modicon Modbus connection. Now it would either be a USB connection or Ethernet.

2, Support for standard bus types built in, or a card available. I am talking about Profibus, Device net and others.

[jstolaruk]

Tag based, optional finite state machine (FSM) bubble diagram programming.

[CroCop]

Auto configure the drivers (like a USB 2.0 plug in)

[monkeyhead]

Hey! It's the Internet! All of us can voice our opinions on what makes a reasonable PLC! Think in terms of... "What if...".

{...snip...}

Think very carefully about this before "Shootin' from the hip!"

You said a bunch of people on the internet should post their feelings without shooting from the hip? Satan must have just ordered a winter coat.

Anyway, features that make a reasonable PLC? Good instruction set, good programming interface, online debug/edit abilities, and ability to communicate over a plethora of com protocols.

Okay... so that makes a good platform. A reasonable platform has all the tools that are needed to get the job done without re-inventing the wheel.

[marksji]

One big block of memory that can be defined as I need it for any particular job. IE, if I'm writing a program that needs 10,000 timers, but only 100 internal bits, then let me create 10,000 timers and 100 internal bits. If another project needs 100,000 internal bits, but only 10 timers then let me configure it that way.

[Peter Nachtwey]

No one will agree on what the perfect controller is.
You can't implement the features anyway. So many have visited this site and asked about how to implement a PLC or have told us they are going to implement a PLC. Not one has said they have finally done it.

Now why don't we narrow the topic a bit like. How does one implement tag names? How does one implement on-line programming? What can be done to fix AB problem where the data get downloaded with the code? Should the ladder, ST, FBD or IL compile down to machine code or an interpreted P-code?

[CroCop]

All IO cards with built in high speed counters.
Higher resolution/speed stuff like National Insturments (data aq. and all)

[CroCop]

All IO capable of digital in/out, analog in/out

[goxx]

relay inputs/outputs option
special relays, ie 1 second on, 1 second off timer

[HLeap]

I vote for one where Documentation as well as the Ladder Logic is stored in the PLC memory.

[rdrast]

Me?
I want to see the ability to handle Datablocks as well as Siemens S7 (online modifications possible) but still have the unlimited nested-inclusions as Logix 5k allows. I'd also like to see Logix 5k's 'comment fallthrough' on datablocks to go through every level, and not just the initial and terminal.

I also want ultra high speed numerical calculations, in formats from everything from integer to double precision floating point.

For programming, and editing, I'd like to see something that supports languages such as SCP (Siemens), but with a more flexible approach. Like an AB ladder 'Box' construct that you can open up and type an SCP function in.

It must have Ethernet, but should also be able have the ability to talk to any industrial network out there, in both master and slave modes.

Just a few thoughts, just got called to fix a problem.

[Goody]

There should be memory that is just like PC memory. Where you can store just what you want in there. Word doc's - pdf doc's CAD drawings etc. The whole program with comments - labels and code descriptions should be in there.
Just imagine that - you come to a machine you have never seen before and the tech drawings and info are all in there inside the PLC.
With cheap memory today, it should be standard.

[Ken Moore]

The ability to handle ASCII text in native format.
Example:
From withing Structured Text, you simple use the "print" command and it will send whatever follows to the designated com port.

Or using some type of "get" function similar to qbasic, you read the buffer, and store it as text, then you can parse or whatever.

[marksji]

With cheap memory today, it should be standard.

I'll second that one. I just bought some 64meg USB flash drives with our company logo printed on them for $10 each so I know memory is cheap... I'd pay an extra $10 for the CPU if it had that kind of extra space.

[PhilipW]

This $10 for 64MB of memory you bought:

1. Does it run at CPU clock speeds?

2. Spec'ed for 50degC?

3. Is it low power memory? Will it hold up for a few years on a single 3.3v cell?

4. Is it flash, dynamic or static RAM? Can it stand unlimited write cycles?


Just because it is memory, does not make it ok to jam into a PLC willy nilly.

[marksji]

This $10 for 64MB of memory you bought:
1. Does it run at CPU clock speeds?
2. Spec'ed for 50degC?
3. Is it low power memory? Will it hold up for a few years on a single 3.3v cell?
4. Is it flash, dynamic or static RAM? Can it stand unlimited write cycles?

I admit I don't know a lot about memory, but doing a little research on generic USB flash drives I've found that they typically employ NAND EEPROMs. So looking at a few spec sheets for NAND EEPROMs

1. Serial interface with 50ns read time and 200-300us write time.
2. 0 - 70 deg C operating temp, -55 - 150 deg C storage temp.
3. It's flash memory, no battery required to hold data. It consumes 10mA for read or write, 100uA for standby, and 0A when off. Power is 2.7 - 3.6 VDC.
4. Its flash, typical seems to be 100,000 writes in the spec sheets. No static memory (ie the stuff the PLC program should be stored in) can withstand unlimited writes (actually I'm not sure there is any memory that can do this).

I'm not advocating eliminating standard RAM type memory (stuff that has to be battery backed) from the PLCs, just giving us more flash memory and letting us store things in that static flash memory other than the machine code (like PDFs, documentation, etc).

[smiller]

Embedded communications in the programming package. I don't like Linx being a separate program.

USB interface so one cable fits all.

User defined function blocks like Modicon Concept.

Tag name addressing is way cool, good job Logix 5000.

Open communications so different brands can share information EASILY and seamlessly without third party involvement and complexity.

I like the rackless design of the Compactlogix. Expansions are not constrained by extra rack slots, only power supply capacity and DIN rail space.

Lots of memory like the GE PAC line. 10 megs to store documentation, Word files, CAD drawings, spreadsheets, whatever.
I think that GE got that right. Now if they would just update the logic developer instead of warming Logicmaster over yet again. Maybe a USB port in a recessed area for physical protection to have a jump drive attached for storage of additional info would work and be cheap. It would be separate from the working memory so it wouldn't need to meet the rigors of the PLC's memory.

Just some of my thoughts.

Steve

[MikeGranby]

And now the big question... Would people pay extra for all these wonderful faclities? Or would they still buy their stuff from XYZ Direct, and say that in the end, price is what matters?

[marksji]

I won't say that price is all that matters, but to get me to switch from AD PLCs to any of the more main stream PLCs would require a substantial price cut in the main stream PLCs; I don't see any of the features we've talked about so far being worth the existing price gap, much less a larger price gap. I know that the main stream PLCs are worth their price to some, but I don't actually need any of the features they provide that the Koyo PLCs lack.

Just my 2c.

[drewcrew6]

Hey its the internet !

Lets think outside the box

Lets redefine how specs are written so we can scan that into the plc via a usb scanner, LOGIC DONE!!!!
Next create a I/O map and put the whole mess into run.

Obviously we will need to make changes in the future so a new wireless standard is created for plcs so security is not an issue.
Also the plc creates a web page style interface that mimicks the process (could use for HMI with changes locked out) and we can drag and drop from a toolbar what we need.
After all changes are done the plc spits out a new spec sheet to match.


Wouldn't that be nice?


Just a wild thought after a long nite at work.
Drewcrew6

[10baseT]

Why not design one with a microphone , so you can just tell it what to do - no comms , no software , no cables to lose or stick up the wrong holes , just a microphone .
All the software engineer has to do is tell the PLC what he wants it to do ( I think some people think it happens like this already ) and switch to run , also I suppose if something goes wrong , if we built a speaker into it , it could tell us what happened .

Takes the fun out of it , getting something that is easy to configure , doesn't need specialized software or cables , and can be programmed by a chimp .

[drewcrew6]

I don't know of any Chimp that can talk .

10baseT : Why does my previous post offend you?

Just a thought that it gets a middle man out of the road namely the person that writes specs would have to more versed in this new standard of specs, Meaning that more of us would be more involved in the project from the beginning. Hopefully that would correct some of the things that we change once its out on the floor.

Drewcrew6

[10baseT]

I do - I have worked for a good number .

What are you going on about ? What did I say that makes you think you offended me ? It is called humour , or at least an attempt thereof .

I know my post followed yours , but that doesn't mean it was in answer to it . I'm personally reasonably happy with the platforms I work with , but maybe I'm too easily satisfied .

See , we are all different , smiller wants embedded comms , I don't , I happen to like linx - "we" would never agree , it is like asking for us to set a spec for a car , can you just imagine what we would get ?

PS , I'm off to see the chimps tomorrow .

[drewcrew6]

Sorry 10baseT Everyone had reasonable replies except mine so I assumed that your response was aimed at me. Just don't want any hard feelings.

Enjoy your meeting with the Chimps.

Drewcrew6

[10baseT]

Not at all !

These people really do think that a PLC comes pre-programmed , and as such don't see the need for a software engineer .

Strange thing is most of what is on the wish list is available today , just sometimes we don't want to pay for it .

[kamenges]

I'm going to play off of drewcrew6's post a little based on Terry's 'think like a human' axiom.

When humans perform realtime control we don't look at the process in absolute terms. We look at it in relative terms. We say tihngs like 'We are getting close so do...' or 'We are approaching too fast so...'. And we come up with our decisions based on things we have seen in the past. The closer the item we are trying to control matched up with something we have done before the better we will be able to control the new item.

In addition humans don't use a single 'sensor' to make decisions but a weighted combination of no less than three direct 'sensors' as well as scores of 'indirect' sensors. We will perform corrections based solely on our sight. But if we hear something 'odd' we will start looking at other items more closely. In addition we will look at values of other physical machine sensors to augment the direct measurement from our sight.

So, we want a plc that will perform rules based correction based on simply stated limits and desires. We want to be able to enter these rules in simple text either directly or from a list. We want the controller to look at several inputs and appropriately weight them based, initially, on what we believe is correct, but ultimately on how well it controls the process. We also want it to iteratively optimize itself so if it doesn't get it right the first time it sooner or later will.

Sound like anything anyone has heard of before?

Keith

[MikeGranby]

To open this up a bit, as well as what would make a great PLC, what about features that would make a PLC-HMI combination work better together? (I do have a professional interest in this, obviously!)

[10baseT]

AI crosses the mind !

http://www-formal.stanford.edu/jmc/whatisai/node1.html

[burnerman]

Definitely tag based programming - get rid of numeric addressing for timers, counters, registers, etc. (if the programmer wants to use numbers he can assign them himself instead of/as well as descriptive tags).

Plug and play modules - plug an I/O module in and the programming software recognises the module type and prompts you to assign a tag and other config. data (e.g. scale range, signal type for analogs) for each point on that module.

All analog processing carried out in engineering units with selectable decimal point precision.

All the programming/processing carried out in the PLC with the whole project stored in the PLC and "dumb" HMIs driven from the PLC - only one point of contact for the programmer, changes only have to be made to the project not to the PLC and the HMI. (OK , just a thought! What about multiple PLCs/HMIs?).

Decent printout facilities for ladder logic that doesn't use a ream of paper to print out a 100 rung program and makes it 100% clear which tag/value applies to which instruction! (Versapro users will know what I mean)

[504bloke]

I vote for one where Documentation as well as the Ladder Logic is stored in the PLC memory.

I second that, would be nice to have all docs including panel drawings and changes in the plc, say a memory card ?

tag based like logix 5000

Standard serial connection, usb and of course ethernet

Plug in memory options

Full windows programming package available free (Like the G3 HMI)

[marksji]

Full windows programming package available free (Like the G3 HMI)

I'd rather buy my programming package and pay less for each PLC... I only need one copy of the programming software, but I buy a lot of PLCs each year.

[504bloke]

I'd rather buy my programming package and pay less for each PLC... I only need one copy of the programming software, but I buy a lot of PLCs each year.

Id like to pay less for the plc as you state and still have a free programming package.

[marksji]

Id like to pay less for the plc as you state and still have a free programming package.

How would that work? The cost to develop the programing package has to be recouped somewhere... Nobody works for free, not even software developers.

[Pierre]

1. The famous "Who cares" input voltage card.

Whatever you connect fits... 120 Vac or 24 Vdc, Sink or Source, just tell it whats comming in and its done
.

2. Java based programming nested "inside" the box.

You open Firefox and connect to the box and the programming software is there for you.

3. Acces to any level

You want to access the ASM code you got it(with #2)


I must say that with the advent of IEC1131 the world of PLC programming has made a giant leap. And for one thing, its getting better. Now we can go from one brand to many others without to much surprizes. Its not perfect but its an improvement.

[Tom Jenkins]

Excuse me - some of this repeats ideas above. Some of this mixes programming software, PLC capabilities, and HMI capabilities. Also, some of these are found in some PLCs but no PLC has all of this as far as I know.

Tag based programming, but with a "smart" find function so that as I type the list gets smaller until I can hit enter or use an arrow key - don't make me go to the danged mouse for everything.

Storing element documentation and rung comments in the PLC with password protection.

Multiple protocols for serial and ethernet comm ports, software selectable.

The ability to add racks with more ports just like adding I/O cards, including fiver optic and spread spectrum radio.

The ability to use 232 or 485 comms, both with optical isolation, from any serial port by connecting the right pins (and the 232 pinouts should match a PC port!)

Comm funtions for connecting to the PLC within the programming package.

A comm port for fiber optic connection with software selectable serial or ethernet plus multiple protocols.

A dedicated fixed setting USB programming only port on the CPU

LED bargraphs on analog I/O indicating with 8 or so LEDs relative signal strength, with a dip switch or such to designate channel being monitored.

All tag info stored in Excel format so you can use a common database for PLC and HMI and modify it on the fly in Excel and print it and send it to integrators and so on directly without CSV exports and such.

All calculations and non-bit data in IEEE 32 bit floating point format. That analog I/O data and timer pre-sets and timer accumulated values, counters, etc. No integers or double integers or double words or whatever - that way all HMIS can use the same input data format and my head doesn't have to keep track of data formats in each brand!

"Canned" functions for alarms with upper and lower limits and deadband and time delay built into the single function block.

A power supply that automatically senses 230 V 50 Hz or 120 V 60 Hz (I can get this in a lousy $50 power supply - why can't PLC power supplies do this simple trick?)

Full trig and log functions, plus rounding and truncating functions.

The ability to load logic separate from tags separate from I/O configuration separate from register values.

The ability to set individual data and bit as non-retentive during a power cycle

Interrupt driven subroutines as well as conventional subroutines

On-line editing

Universal I/O - 24 VDC or 120 VAC 0r 230 VAC for discrete, 4-20 mA or 0-10 VDC or RTD for analog, selectable channel by channel in software

Ability to get rid of the heat regardless of mounting orientation


How much would I pay for all this - I don't know, but I'd love to have the chance to decide!

[TimothyMoulder]

I hope and pray some vendors get to see this - with the influence this site has, this would be the single most important thread for any of them to see in the history of PLCs.net!

Assuming we haven't chased them all off, of course.

I'll add my wish list when I get a few more moments. Yes, even Unitronics could be improved upon - slightly...

[Peter Nachtwey]

To open this up a bit, as well as what would make a great PLC, what about features that would make a PLC-HMI combination work better together? (I do have a professional interest in this, obviously!)

How about for motion controllers.

I would HMI to have the ability to read arrays of data instead of just tags. I get involved with a lot of motion control applications where the customer would like to edit motion profiles or read the last motion profile. This would be very handy in applications like blow molding, injection molding and other applications where reading the last motion profile is part of the quality control. For the most part our customers have to use PCs or industrial PC with HMI software to do these graphical applications.

Many HMIs don't support long integers or floating point. That makes it hard to communicate with modern PLCs and motion controllers. I am not sure about all the capabilities of your smaller HMIs but I know we have bought about a half dozen for testing with our motion products. Some of these little HMIs are very crippled.

From our standpoint it would be nice if the HMI had the ability to read a word, long integer or float and be able to select bits out of the word or change bits in the word. That way we do not have to emulate bit files or I/O registers like 0x or 1x. We can do everything in long integers and floats.

I just wish the Siemens and Rockwell software could export their data structures in a standard .xml format so the PLCs, HMIs and and motion controllers could import the data structures I have seen where it takes hours to resolve the data base between the PLC, HMI and motion controller.


I hope and pray some vendors get to see this - with the influence this site has, this would be the single most important thread for any of them to see in the history of PLCs.net!

I like these marketing survey type threads and truthfully this is the main reason why I am here. A vendor would be stupid to ignore this good information. In fact I was just reading the comments to one of the programmers here and noting how well we are doing and what features we must add.

[skeet]

[QUOTE=PhilipW]This $10 for 64MB of memory you bought:

I'm not being critical here, just recalling that I bought a Kaypro back in '81 0r '2 for 1500 bucks.

64K RAM, two 5 1/4 drives and a little green 9-inch CRT?

Programmers did a hell of a lot within a small space back then. More memory doesn't mean, necessarily, beter programming, in a PC sense...or...well...any sense....

Programmers of many stripes I've noticed use the "memory" hole into which they might throw a lot of "wing-dings."

I've seen a lot of old 486 INTEL 33 MGHTZ processors run entire sawmill lines just fine, and the thing I always come back to is: is "more complicated" "better"?

Not arguing anything here. Just food for thougt....

Skeet

[skeet]

How about for motion controllers.

I would HMI to have the ability to read arrays of data instead of just tags. I get involved with a lot of motion control applications where the customer would like to edit motion profiles or read the last motion profile. This would be very handy in applications like blow molding, injection molding and other applications where reading the last motion profile is part of the quality control. For the most part our customers have to use PCs or industrial PC with HMI software to do these graphical applications.

Many HMIs don't support long integers or floating point. That makes it hard to communicate with modern PLCs and motion controllers. I am not sure about all the capabilities of your smaller HMIs but I know we have bought about a half dozen for testing with our motion products. Some of these little HMIs are very crippled.

From our standpoint it would be nice if the HMI had the ability to read a word, long integer or float and be able to select bits out of the word or change bits in the word. That way we do not have to emulate bit files or I/O registers like 0x or 1x. We can do everything in long integers and floats.

I just wish the Siemens and Rockwell software could export their data structures in a standard .xml format so the PLCs, HMIs and and motion controllers could import the data structures I have seen where it takes hours to resolve the data base between the PLC, HMI and motion controller.


I like these marketing survey type threads and truthfully this is the main reason why I am here. A vendor would be stupid to ignore this good information. In fact I was just reading the comments to one of the programmers here and noting how well we are doing and what features we must add.



Peter
Yall have done for us ( one of your sawmill-style consumers )lots of Good Things.... I would recommend Delta stuff any day, and that's because I have used it. Are there better out there on the market? I dunno. Maybe. But I haven't used theirs, and yours does exactly as advertised, everytime I have used them. That's all I want, after all

I aint kissin' your ***, Peter...just saying that your product out there follows the correct definition of the word "quality".... "Something that DOES as ADVERTISED."


Ok.... Unintentional Advert ended... Fade to black...and white girls in small swimsuits....

Skeet

[MikeGranby]

Definitely tag based programming - get rid of numeric addressing for timers, counters, registers, etc. (if the programmer wants to use numbers he can assign them himself instead of/as well as descriptive tags).The only issue I have with tag-based programming is that it can lead to horribly inefficient comms if the manufacturer isn't smart enough to let you define watch lists and then read groups of data items in one go. There are PLCs out there (no names!) that have very slow update time as a result of poorly designed tag-based comms. It could be done properly, but often, it isn't.

All the programming/processing carried out in the PLC with the whole project stored in the PLC and "dumb" HMIs driven from the PLC - only one point of contact for the programmer, changes only have to be made to the project not to the PLC and the HMI.This is an interesting one. The same thing could be achieved via an integrated programming package and networked download, but you do have to wonder about a client-server approach to these things. Unfortunately, we don't make PLCs, so it's not something we can make happen from here.

[MikeGranby]

I am not sure about all the capabilities of your smaller HMIsWe do arrays, and 32-bit math, including reals.

[MikeGranby]

Good list, Tom, but...

> All calculations and non-bit data in IEEE 32 bit floating
> point format. That analog I/O data and timer pre-sets and
> timer accumulated values, counters, etc. No integers or
> double integers or double words or whatever - that way all
> HMIS can use the same input data format and my head doesn't
> have to keep track of data formats in each brand!

Not sure about this one. IEEE 32-bit format only has a 24-bit mantissa (including the implicit leading digit) and that's only enough to count up to 16.7 million. Sounds like a lot, but in some applications, it's not enough, especially for production run counting and the like.

[504bloke]

Unfortunately, we don't make PLCs, so it's not something we can make happen from here.

Perhaps heres a niche in the market for you.............

New PLC from a wish list at :site:

[504bloke]

The only issue I have with tag-based programming is that it can lead to horribly inefficient comms if the manufacturer isn't smart enough to let you define watch lists and then read groups of data items in one go. There are PLCs out there (no names!) that have very slow update time as a result of poorly designed tag-based comms. It could be done properly, but often, it isn't.


What about both, got a good plc with efficient comms then use tag based in the HMI. If not and comms are inefficient then go back to the old fashioned way ?

[MikeGranby]

> Perhaps heres a niche in the market for you.............

Don't think we haven't considered it! :) But the problem is more one of marketing and channel conflict. If we start making a PLC and actually get some traction, a lot of our distributors would get heat from their franchise PLC lines. It's a pity, but it's the reality of the market.

[MikeGranby]

What about both, got a good plc with efficient comms then use tag based in the HMI. If not and comms are inefficient then go back to the old fashioned way ?The PLC programming software should definitely be tag based from a UI point of view, and in an ideal world the PLC and HMI software would then work-out a numbering convention for the tags that allows base-plus-count style transactions to be performed, thereby avoiding the awful send-the-name-in-ASCII method that some comms protocols use. At worst, the PLC should be able to allocate the numbering and then allow the HMI to import it, but then there's no way to ensure you get the blocking done properly. At least if the HMI software is involved, it knows which tags are used on the same pages.

[PhilipW]

I've been biting my tongue here, but what does strike me is how well ControlLogix is scoring in this exercise. If I take out the "microphone and speaker/AI/SmarterthanGod" feature the main thing missing is User Defined FB's...which are due in Version 16 I think.
Tag based programming, but with a "smart" find function so that as I type the list gets smaller until I can hit enter or use an arrow key - don't make me go to the danged mouse for everything.
Almost all the RSLogix packages do something close to this.

Storing element documentation and rung comments in the PLC with password protection.
Element comments yes, rung comments no. Passwording yes.

Multiple protocols for serial and ethernet comm ports, software selectable.
The native CPU port is limited to a handful of AB protocols, but third party modules access more or less all of them.

The ability to add racks with more ports just like adding I/O cards, including fiver optic and spread spectrum radio.

Yes. CLX handles all comms other than the Logic processor's serial port in exactly this manner.

The ability to use 232 or 485 comms, both with optical isolation, from any serial port by connecting the right pins (and the 232 pinouts should match a PC port!)
A miss although using a NET-AIC+ will get you pretty much what you want.

Comm funtions for connecting to the PLC within the programming package.
Miss. Personally I prefer the RSLinx approach as more powerful and open to multiple applications, eg being online with the HMI and Programming package at the same time via the same connection.

A comm port for fiber optic connection with software selectable serial or ethernet plus multiple protocols.
A miss. A 1756 Fibre Optic Ethernet module did exist, but seems to have vanished from recent catalogs.

A dedicated fixed setting USB programming only port on the CPU
A miss....but then CLX is usually connected via the ENET port, that I usually configure with BootP....a USB port would not add much. I think there is a new ENET card that will come with IP address swithches and a config port of some kind. The serial port on the front of the CLX logic processor is just not used very much as a rule.

LED bargraphs on analog I/O indicating with 8 or so LEDs relative signal strength, with a dip switch or such to designate channel being monitored. Cool idea, but I can't see it as a commercial flyer.

All tag info stored in Excel format so you can use a common database for PLC and HMI and modify it on the fly in Excel and print it and send it to integrators and so on directly without CSV exports and such. Agreed. I think we are getting closer and closer to this all the time.

All calculations and non-bit data in IEEE 32 bit floating point format. That analog I/O data and timer pre-sets and timer accumulated values, counters, etc. No integers or double integers or double words or whatever - that way all HMIS can use the same input data format and my head doesn't have to keep track of data formats in each brand!
Not always appropriate. It would burden the CPU substantially for little gain really. Besides AB make all the data conversions pretty painless. If you want everything in FP, then yes you can do it. In fact that is pretty much how I do write many of my process oriented programs where scantime is not an issue.

"Canned" functions for alarms with upper and lower limits and deadband and time delay built into the single function block.
Yes. Alarms can be handled like this either on the Analog IO module itself, or with a standard FB instruction.

A power supply that automatically senses 230 V 50 Hz or 120 V 60 Hz (I can get this in a lousy $50 power supply - why can't PLC power supplies do this simple trick?) I suspect there is a design issue buried in here. I agree it is a simple trick, so there must be a good reason why PLC's do not do it.

Full trig and log functions, plus rounding and truncating functions. Tick

The ability to load logic separate from tags separate from I/O configuration separate from register values. Partial downloads.... mmm tricky. Requires that memory is partitioned, and AB have always offered a completely open memory model. Agreed that is would be useful.

The ability to set individual data and bit as non-retentive during a power cycle AB simply make this distinction based on whether is OTL/OTU or an OTE output.

Interrupt driven subroutines as well as conventional subroutines
Yes. CLX offers an Event Task that can be driven from an IO module event, a Motion Event or a Produced/Consumed tag from another CPU.

On-line editing Umm...yes. And true on-line editing at that. Supports multiple simultaneous editing sessions as well.

Universal I/O - 24 VDC or 120 VAC 0r 230 VAC for discrete, 4-20 mA or 0-10 VDC or RTD for analog, selectable channel by channel in software Not very practical. The design requirement for 230vAC is totally different to 24vDC. Universal analog IO is more readily achieveable and I think Spectrum Controls make something close to what you want.

And the guy who wanted more flash memory to store offline data...mmm really big questions over the usefulness of that...it might crank some handles, but certainly not all. However I do spot in the NZ price book a 1784-CF64 a 64MB Flash Memory card....for NZ$170.

[marksji]

A power supply that automatically senses 230 V 50 Hz or 120 V 60 Hz (I can get this in a lousy $50 power supply - why can't PLC power supplies do this simple trick?)

I suspect there is a design issue buried in here. I agree it is a simple trick, so there must be a good reason why PLC's do not do it.

I don't see why there is a problem including an auto-switching power supply in other brands of PLC... AutomationDirect AC powered PLCs have done this for years.


Quote:
Universal I/O - 24 VDC or 120 VAC 0r 230 VAC for discrete, 4-20 mA or 0-10 VDC or RTD for analog, selectable channel by channel in software
Not very practical. The design requirement for 230vAC is totally different to 24vDC. Universal analog IO is more readily achieveable and I think Spectrum Controls make something close to what you want.

If you can make a power supply do the neat trick of universal input, why not an input point?
Universal analog would be cool, but I'm not sure how much cost it would add.


And the guy who wanted more flash memory to store offline data...mmm really big questions over the usefulness of that...it might crank some handles, but certainly not all. However I do spot in the NZ price book a 1784-CF64 a 64MB Flash Memory card....for NZ$170.

Good point. I certainly wouldn't be one of the ones willing to pay through the nose for this even though I would love to see it. At the same time the USB flash memory drives tend to walk off when left in the control cabinet. If there was a usb flash drive integrated with the CPU it would be a lot less likely to go unnoticed when it walks off :)

[PhilipW]

If you can make a power supply do the neat trick of universal input, why not an input point?

Electronics is not magic and there are limits to what can be achieved. I think you will find all AC inputs use a capacitor to limit the current flow to the input isolation diode. For a 230vAC input this capacitor is likely to be rated at 600 or 1000v and needs a value in the order of few tens of microfarads, and thus has to occupy a certain volume. There is a limit to how many of these you can get on a standard IO module format, AND observe voltage creep limits and isolation requirements.

As a result you will find most 230vAC input modules are 16pts max, by contrast 24vDC modules are commonly found in much higher densities...32/64 or even 96pt modules can be found. Designing a Universal module that is economical is pretty unlikely.

Besides I am not even all that convinced there would be that much of a demand for such a beast, even if it were available at the price and format desired. Most projects I have come across use just one control voltage.

[Tom Jenkins]

I know the universal I/O is blue sky, but if you make the design concessioin that a dip switch or such would be required on the card (maybe for groupings of four or eight channels) it is certainly feasible. You would simply be switching from triacs to diodes on the outputs and switch from one set of caps and pull-up resistors to another on outputs. The electronics nowdays are cheap - board real estate requirements are the real problem.

I don't know for sure about demand, but I have been surprised more than once in the field when I expected 24 VDC from a RVSS or VFD and found out there was 120 VAC instead!

[drewcrew6]

A little reality , How about an HMI that the software can "open" the plc program and automatically create I/O screens( for just basic troublshooting to see if "2"or "15" or whetever digital) is on or off. Along with a screen to show analog values. With the use of tag based this should be relatively easy to do especially when working with the same brand of equipment. If these screens are created after a reasonable amount of screens are created then the look would match the common look and feel of those screens upon their creation .

This is more aimed at RsviewMe/Se How about a place to define how a default screen and "objects" look with colors, text, border all defined from the start but you can still change any of those. Alot of time is wasted defining all of this.
I know I could create a "library" but I don't believe I should have to as some projects look one way and others that way. One simple place with checkboxes would suffice. There should also be a way to "transfer" the communications setup in both directions not just the one.

Drewcrew6

[Terry Woods]

Today, while at work, I thought, damn... I wish I had said "no tags".

Now wait, before you go crazy... I totally agree, tags are great! It is the essence of the "C" language! It is the essence of "Virtual-Memory". And those of you that have been around awhile (like you Baker Street Irregulars - you know who you are) know how favorable I feel towards "C" and "Virtual-Memory".

Over the last several years there has been quite a bit of squawking against the idea of using any "C-type" methods in PLC programming. And I remember very well saying... "Like it or not, it's coming!".

But... when I started the thread, I was thinking in terms of those low-end PLCs that don't have the powerful programming software that can provide "Virtual-Memory" management. I was thinking of the addressing of I/O and memory. Why use Octal, or anything other than Decimal, for I/O or Memory? That's just nuts!

But clearly... the AB guys with their tag-based addressing scheme (which has been around, but unused, since the early 80's... the 1980's for those that... nevermind.)

Anyway... clearly, at least so far, that is "the" most important characteristic in the "Ideal PLC". So I must go with it. And so I shall.

However, there are issues with Tag-Based Memory that are not so good... everything is a trade-off don'cha know? I'll think on a explanation.

Now...

"Partial downloads.... mmm tricky. Requires that memory is partitioned, and AB have always offered a completely open memory model."

I beg your pardon... AB has never had an open memory model, at least not with respect to code. That is, not until recently... with the new software... which has finally taken AB beyond the TI model in many respects... but not all, not yet.

TiSoft has been able to load logic alone for quite awhile. Of course that means that the hard-coded V-Mem, Timer and Counter values get loaded. But then, you're starting from scratch, aren't you?

In the TI model, V-Mem is open to any and all uses - you DO, of course, have to KNOW what you are doing!. There is also Timer/Counter Memory, Special Function Memory, Drum-Memory, Sub-Routine Memory, One-Shot Memory, a few other types, and of course, Code-Memory. And all of that memory is SCALABLE! That is, you can select how much you want to dedicate to whatever. Code-Memory is what is left after all other memories are dedicated.

There is, however, a certain limitation... for instance, you can't have only 5 one-shots... the smallest block-size allowed for one-shots is 1K. You could... if you were so inclined, dedicate the entire memory to One-Shots! (Of course, that wouldn't leave any memory for code.)

Just about everything is limited to 1K increments. The on-screen memory manager indicates current memory usage, what memory is allocated to what, and how much memory you have left.)

If you want to change memory allocations... you have to stop the process. This is NOT an on-line-change kinda deal. To do otherwise would be like doing a re-compile while running... not good!

In the earlier AB models, you had to deal with those goofy file-thingees. Sure, they work, but c'mon... the grief you had to go through to access a variable was kinda nuts... yeah? File-type... File Number... Element Number.

How about... Gimme a "V"!... now gimme a number! Done.

Of course, this falls under the intended constraints that I have described at the beginning of this reply.

[MikeGranby]

> Designing a Universal module that is economical is pretty unlikely.

Agreed. There's also the question of spacing requirements to meet UL, which impose a much lower density on 230VAC inputs than on 24VDC.

[jimbo3123]

A little reality , How about an HMI that the software can "open" the plc program and automatically create I/O screens( for just basic troublshooting to see if "2"or "15" or whetever digital) is on or off. Along with a screen to show analog values. With the use of tag based this should be relatively easy to do especially when working with the same brand of equipment. If these screens are created after a reasonable amount of screens are created then the look would match the common look and feel of those screens upon their creation .
Drewcrew6d

Mitsubishi and Toyopuc HMIs both have built-in ladder monitors that allow the operator to view (and edit??) the running PLC program. It is pretty nice, but it requires pretty tight integration on their PLC side.

[MikeGranby]

> Why use Octal, or anything other than
> Decimal, for I/O or Memory? That's just nuts!

The historical reason was to provide an easy indication of the slot and point number within the numbering scheme. So, a PLC which had eight outputs per card might use octal addressing, so that the last digit was always the I/O point number for the specified slot. The even worse examples had mixed-radix addressing, with, say, a decimal slot number followed by an octal point number in the last digit. When you're writing comms drivers for HMIs, you get to experience all this nonsense and more!

[MikeGranby]

Partial downloads.... mmm tricky. Requires that memory is partitionedWhy do you say this? I can think of several ways of doing partial downloads with no partitioning...

[Terry Woods]

Like I said... foolishness, regardless of the "history".

[MikeGranby]

Like I said... foolishness, regardless of the "history".Well, it made sense in its day. When you're working without tags, it's nice to be able to convert a logical address to a physical one in your head -- although I do agree mixed-radix was taking it a little too far!

[PhilipW]

Why do you say this? I can think of several ways of doing partial downloads with no partitioning...
Yeah, but not without some limitations. If you want to download an data file extended for instance, by another hundred words or so, and the chunk of memory required had other data or code already occuping it...then something has give if you want to do it online. All I am saying is that people routinely ask for on-line editing of this or that in an open unlimited fashion, without realising just how much re-arranging and shuffling of live code is involved.

And it all has to be bullet-proof.

Terry,

In the TI model, V-Mem is open to any and all uses - you DO, of course, have to KNOW what you are doing!. There is also Timer/Counter Memory, Special Function Memory, Drum-Memory, Sub-Routine Memory, One-Shot Memory, a few other types, and of course, Code-Memory. And all of that memory is SCALABLE! That is, you can select how much you want to dedicate to whatever. Code-Memory is what is left after all other memories are dedicated.

I'm going to have to take two bites at this, one for the PLC/SLC and the other for CLX.

In the older PLC scheme there a number of default tables, IO images, Flags, Integers, FP's, Timers, Counters and Controls. By default they were of minimum size, eg file N7 was just one word long until you added more members. In other words the fixed datatables occupied a tiny insignificant portion of memory by default. From this point on memory was openly allocated entirely according to what the programmer created, what files, types, routines, etc...you could more or less allocate memory as required. Only proviso, some CPU's did have some limits on data and code memory, but in practise rarely a limitation.

In the CLX memory is for all practical purposes, entirely open. Whether program, or tag, the CPU does not care. That is what I meant by a Open Memory model. By contrast many other PLC's behaved pretty much as you outline for the TI....large blocks of memory fixed to specific purposes.

[Ken M]

This is NOT an on-line-change kinda deal. To do otherwise would be like doing a re-compile while running... not good!
But Terry I thought this is exactly what the final TI 545/555 CPUs did! There was in fact twice as much memory on-board the CPU as you had access to. There was the area you download in to, and there was the compiled version which the CPU actually executed. Now anybody can suffer a memory corruption if noise etc is bad enough. So TI gave you a choice with a couple of DIPswitches about how you wanted the CPU to behave.

If it detected a checksum error in the compiled code, you could either stop the CPU there, or you could elect for the CPU to do an on-the-fly re-compile of the code you'd downloaded and carry right on. I think there was even a counter in the Status Words to tell you how often this had happened. If the checksum error was in the downloaded code, an error bit was set in a Status Word so you knew to do a re-download at the next available opportunity. Meanwhile the compiled code ran on uninterrupted.

Damnit, these guys were good!

Regards

Ken

[FrancisL]

To put all the documentation in the PLC really requires that the PLC has an integrated PC, that may be ok, but I have doubts about that.
My ideal Controller:
Integrated graphics
Object oriented
1131/3 Instruction set
Ability to Create an object (for example a valve, a motor or even say a vessel or an entire process unit) complete with it's graphics, and then be able to create an instance for each very simply, without having to worry about addresses.
And of course this 'PLC' will be a commodity, conforming to a public standard, just like PC's are, so it will be made really cheaply by numerous suppliers.

[RMA]

I'm a bit surprised that so far nobody has mentioned the ability to hot swap H/W, not just the I/O and PSUs, (I had that over 30 years ago on a pre-DCS system), but also CPUs in multi-CPU systems and comms processors.

I know H/W is pretty reliable nowadays but everything fails some time or other. Maybe we're too machine oriented here rather than process control - it may not matter much if you have to power down a machine which can't run anyway because of an I/O fault, but it sure as heck does make a difference if you have to stop a large chunk of a chemical plant because of a fault which only directly affects a very small part of that plant.

[Tom Jenkins]

I used to be very down on tag based ddressing. I still have mixed feelings about it, because the tag base does take a lot longer to set up than V-memory or other fixed addressing schemes. I agree with Terry that the A-B addressing in the SLC seemed to combine the worst of both worlds in some ways.

However, I have come to the conclusion that the increased ease in editing and adding new program segments with the RS-Logix 5000 system offsets the additional work of setting up the tags.

Sorry Mike, I don't know what to say about the problem of grouping tags for communications blocks. I can see where that is a problem, but it may be that fast Ethernet comms makes this problem of lesser practical significance to the end user.

[cjh]

I still have mixed feelings about it, because the tag base does take a lot longer to set up than V-memory or other fixed addressing schemes.

I disagree with this premise. I have yet to be able to call a project complete without documenting what the Xs and Ys and Vs and N7s and B3s, etc... actually are in the application. With Tag based addressing you are documenting and programming at the same time. I think it more efficient and less time consuming that using fixed addressing.

[MikeGranby]

> but it may be that fast Ethernet comms makes this
> problem of lesser practical significance to the end
> user.

That's certainly true.

[MikeGranby]

If you want to download an data file extended for instance, by another hundred words or so, and the chunk of memory required had other data or code already occuping it...then something has give if you want to do it online.Not if there's an internal layer of indirection in the way...

[Andybr]

The problems with tag based addressing detailed by Tom and Mike can almost always be overcome with careful planning and use of UDT's. Once a UDT has been defined for, say, a motor then creating tags can be as simple as entering a Tag number for each motor. I have also found that using a small number of large UDT's to hold SCADA data and enabling UDT optimisation in Linx can make comm's extremely efficient.

[504bloke]

To put all the documentation in the PLC really requires that the PLC has an integrated PC, that may be ok, but I have doubts about that.


Now i dont want to get shot down here BUT i was told from a german siemens programmer that the new S7 had this memory chip on it smaller than the size of your fingernail that could have all your panel layout drawings and documents stored on it as well as the plc program and full documentation on that as well with room to spare for excel spreadsheets and much more............

Not into Siemens i dont know how true or untrue this was/is but the chap who was talking about this was stamped siemens through like a stick of rock..........

This i did think was a good idea.

[Terry Woods]

Ken said...

"But Terry I thought this is exactly what the final TI 545/555 CPUs did!
...
If it detected a checksum error in the compiled code, you could either stop the CPU there, or you could elect for the CPU to do an on-the-fly re-compile of the code you'd downloaded and carry right on."

Your comment is directed at my comment about "changing memory allocations" while the process is running.

I stand by what I said. Considering how long it takes to recompile... if a process is currently running... while a recompile is occurring, no input activity is detected, or at least not responded to, during that time.

As an ultimate fall back for the case you described... hell yes! Recompile! But be aware of the consequences! I might add, that also requires a lot of extra programming to handle the unexpected reality that might exist when the processor "wakes-up" again.

If a programmer wants to reconfigure his memory allocation... safely... he would do well to wait for a down-time, or at least a quiet-time... about 1/4-sec. of quiet-time.

PhillipW said...

"By contrast many other PLC's behaved pretty much as you outline for the TI....large blocks of memory fixed to specific purposes."

What I said was that the TI memory-areas, for any of the given memory-area types, is scalable - NOT fixed. If you wish, you can have 0K (zero-K) available for Drums, or whatever. If you wish, you can dedicate most, if not all, of your entire memory to Drums... up to you... choose wisely, young Jedi!

[S7Guy]

Now i dont want to get shot down here BUT i was told from a german siemens programmer that the new S7 had this memory chip on it smaller than the size of your fingernail that could have all your panel layout drawings and documents stored on it as well as the plc program and full documentation on that as well with room to spare for excel spreadsheets and much more............

Not into Siemens i dont know how true or untrue this was/is but the chap who was talking about this was stamped siemens through like a stick of rock..........

This i did think was a good idea.

Yes, that feature has been available for a few years. You can store whatever you want on the memory card, so anyone that comes after you can upload source code and documentation. I do that with the S7-400s, but haven't tried it with the 300s.

And tag-based programming is awesome. I've done most of my projects that way for the last few years, and it's a relief not to have to worry about absolute addressing for anything but my real-world IO.

[RMA]

Now i dont want to get shot down here BUT i was told from a german siemens programmer that the new S7 had this memory chip on it smaller than the size of your fingernail that could have all your panel layout drawings and documents stored on it as well as the plc program and full documentation on that as well with room to spare for excel spreadsheets and much more............




It's also available (slightly indirectly) on the 300s. You can store anything you want on the MMC, if it's big enough. I had to get a 4 MB MMC for my 317-2 DP in order to do a Firmware upgrade and now I've got enough room to store the complete project (archived) as well as a few of the Siemens manuals on it. Unfortunately, I believe the maximum size is 8 MB and since you have to buy them from Siemens, because they're specially formatted, they are very expensive!

[DenommeX]

My wishlist:

-Faster CPU's (reasons to be explained below)

-Faster Enet - Backplane Communications to allow Wireless data comm.

-Above mentioned voltage sensing - Use micro-controllers(PIC) to poll and adjust the settings.

-Device database loaded on devices - performance curves/specs + preloaded logic that conforms to device operational standards.

-Open Source Software structure - ala Linux - why pay for functionality I don't want or use.

-Heuristic operation as alluded to above - data logged to a spreadsheet within the program memory and analyzed to improve efficiency based on device specs...and previous operation.

-Distributive memory - keep prices down - store data across multiple devices - memory within I/O cards?

Just my musings...

[oldNovice]

I just "completed" my first RSLogix 5000 project and I found that UDT are the best his since .... should I say it ... sliced bread!
I created a UDT and replicated that as many times as required. I also crated other useful UDTs that make the entire software more readable particularly since it is a combination of Structured Text and Ladder Logic.

The reason completed is in quotes is that this is the first phase of a four phase integration of a system consisting of four PC running Visual C++, one running NI software, two chassis based PLCs, and one Softlogix 5800 PLC (my part of the project).

[plchacker]

OK here's my list, most are repeats:


Hot swappable IO/

Tags are great, but there must be a quick and useful search tool. I'd still want numbered addresses for I/O.

Fiber Optic connections between racks. Standard Network Fiber, not some *******ization. Cat 6 is a good second choice.

Com cards that can handle any of the standards out there. Anything from 232/485 to devicenet and profibus etc.

Bluetooth, USB and Ethernet without extra expense. These should be built in, not extras.

The ability to have function block, ladder, C++ or VB, and statement logic in seperate routines, all processed according to your own desires, ie Scan rates(not times) for each routine. (All in STI fassion) This puts a load on the programmer, but offers wonderful tools for high speed applications.

Additional slower memory for documentation beyond the norm. Spreadsheets, DWG files, Database, both Access and SQL.

Intergated HMI. Possibly stored in the slower memory. All in the same package. Attached to simple touchscreens through Fiber, or Cat 5/6

By all means, give people who can operate a keyboard an option. I can type much faster than I can drag and drop. AB5 and AB500 are good at this, CLX is not so smooth.

Configurable Analog I/O on the go. No dip switches inside the card.

At least one high speed counter built in.

SPEED, memory, scans, I/O, 64 bit would be nice.

Redundant where possible. USB memory stick compatible for emergencies.

Several layers of security.

CLX is close, but lacks big-time in some areas.

Wireless communications with security. Its slow, but oh so useful in a large facility. I find it very useful to take a laptop to the area of the machine I am working on (So I can watch the machine.) Think big machines. This is more of a network issue, but very useful. It would be nice if the PLC had this built in, rather than having to set up wireless inside the mill, through IT's control.

[seppoalanen]

There should be memory that is just like PC memory. Where you can store just what you want in there. Word doc's - pdf doc's CAD drawings etc. The whole program with comments - labels and code descriptions should be in there.
Just imagine that - you come to a machine you have never seen before and the tech drawings and info are all in there inside the PLC.
With cheap memory today, it should be standard.I have that one. It is PC, just add some I/O to Ehernet... and Windows is quite well OS.