Let's design the Ideal PLC!

[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.

 

[MarkTTU]

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 .
Drewcrew6

d

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 partitioned

Why 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".