Let's design the Ideal PLC!

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

Don't we have H/W failure any more?

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