New features wanted!! Apply here!

[ATU]

The 64k suprised me for several reasons:

1. I was comparing that to the AB Compact logix controller. Perhaps, this was wrong of me to do so.  If this CPU would have similar features to that controller, the memory size in that CPU is 750k to 8 meg. If this CPU has the configurable tag and program module style layout as CL then it would tend to have larger programs. 64k is far off from 750k.   Of course their price tag is way up there too.

2. I don't know what the data area size was going to be, but comparing it to past AD CPU's, it is ususally about the same size as the ladder.
Some major complaints I have from some of my customers is that they have run out ladder or recipe data space.  These are small to medium size complex assembly machines with 100's of part numbers.  They have reluctantly switched to CL for some of these reasons.

3. New CPU's don't come arround very often and this one has to be able to satisfy your needs for several years to come. Comparing the leaps seen in the PC environment in memory sizes, I expected more of a jump in memory size. Of course, I don't know what your price/performance constraints were, what PLC market you were aiming at or if you wanted to stay in the same memory range as current AD CPU's.

[franji1]

Sorry if I mislead anybody.  The 64K is 64K instruction words.  I'm guessing when quoting memory, people assume bytes.  I was referring to program memory and (improperly) assumed everybody knew the units were ladder words (most instructions are 1 word, but others are more).  Therefore, program memory in terms of "bytes" is (for now at least) 256K Bytes.

Data is a completely different story.  That is usually given in BYTEs since some areas of memory are bits, some 16 bit words, some 32 bit words, others are groupings of common data for a single "entity" (think PID structure in the current ADC PLCs).  Data memory does NOT come out of this ladder program memory - there is not a common "pool".  Again, apologies for not going into enough detail.

[Controls Guy]

So how data memory is there to be?  Or is that firmed up yet?  I agree that I hardly ever hit the limits of ladder memory size, but like the other poster I like to store recipe data in the PLC and total data memory is usually what dictates the limit on how many recipe slots I can give them.

[BobO]

So much is already real, but a few things are still speculative. Some things are simple reallocation of available resources, and some are architecturally limited. Without going into detail, there will be four types of memory: ladder, documentation, image register, and bulk storage. Ladder doesn't have many limits, other than the need to maintain two copies for runtime updates and what is reasonably useful. Documentation doesn't really has practical limits either, but will be set to what we thing is reasonable. Image register has architectural limits, but will be plenty bug...considerably larger than current systems. Bulk storage...suitable for use with recipes and such...will be huge by comparison.

The key thing is to understand that bulk storage doesn't require the level of performance that ladder or image register does, and image register has other factors like battery life and access speed that must be factored in. When people look at the size of a USB drive or gigabyte ram, they immediately think that all memory is free. Problem is that there are very specific criteria for building a PLC and a ton of trade-offs that are not at all obvious. Yes, dynamic rams are huge and reasonably fast...but you can't keep them alive for 6 months on a button cell. Fast statics (cache ram) are blazingly fast, but can't be held up with a battery for long periods. Battery backed statics can be held up for long periods but are small capacity and slow. Anyway, you get the picture.

It does help us to understand what you are running out of and why. Where certain things are arbitrary, we'd really like to give you what you want.

[Controls Guy]

What is the form factor?  An earlier post suggested this is a new processor for 205 series racks.  Is this so, or a new system from the ground up, including mounting and I/O? (Or both, a new system plus retrofit processors as well)  Also, if you get a chance, could you speak to the items I mentioned on page 6 of this thread?

[BobO]

Initial is 205. Also planning version for Terminator. A new platform will be dependent on market response, but is certainly being considered.

We are still not wanting to publish specific features yet, but I'll say that some of what you mentioned is definitely going to be included. We have placed considerable emphasis on strong data typing and program modularity. This control engine will be a significant step up from previous DL CPUs, but hopefully will be familiar enough to most users to be an easy transition.

[Controls Guy]

You've definitely whet my appetite!  Don't worry too much about ease of transition; just make the best tool you can and I promise you we'll figure out how to put it to use!

Oh, another thing:  symbolic constants, I guess you could call them.  In the old TI5x0 and 5x5 days we called it K-memory.  Registers which would hold a number which could only be set at program time and could not be altered at run time.  So a constant, but referred to by register location.  This helps program clarity vs. literal constants, expedites changes if the same constant is used in various locations, and is good for "machine description constants" that are necessary when subsequent machines are qualitatively but not quantitatively identical.  Identical operations but need to know the length of the machine, or number of processing stations, etc.

The SLC has the rough equivalent of this if you set the protection for a given data file as "static" meaning it cannot be altered either by the processor or by a terminal or MMI remotely.

I once asked a RS tech guy how this could be done in a CLx and he said to set up a variable and load it with the desired value.  I asked him if he saw any problem with advising me to use a "variable" when what I was looking for was a "constant".  He didn't see a problem.

[ATU]

Speaking of Data Types.  One powerful feature in CLx that few programers probably take advantage of is the ability to create your custom data structures. When used in the right circumstance, this is a great feature and can also conserve memory space. One instance being that I had to handle a large array of string variables. The standard size for a string is around 80 bytes, but I only needed strings of 16 characters. So I set up a custom data type that consisted of 25 small 16 byte strings along with other mixed data types. Then I was able to create a large array of this data type. If I were not able to do this, it would have used a great deal of storage space with the default string size. Perfect for recipe creation. Is something like this going to be available?

[Controls Guy]

Not to hijack the thread but I think CLx fails to realize the potential of it's vision in several ways.  Supposedly a motion platform, you can't put AXIS's in user-defined data types nor put them in arrays. So you can't have Hoist[this].Velocity or even Hoist[3].Velocity.  Array indexing is also somewhat hobbled by the fact that you can't do Array1[Array2[n]].  Sorry BobO, I know you didn't set up this thread for us to talk about other products!  ;-)

[BobO]

Yeah, but in a way I did. The point of this thread is to provide us ideas on how to proceed with new product development. I would say that one of the better ways is to understand what the competition did poorly.

Motion is clearly something that we haven't done very well. That it something we'd like to change in the future, driven by the new control engine. I love to hear more thoughts on that over time.

Interesting thought on K memory. That is one of the more cogent explanations for why you need it, although I confess until now I couldn't have told you why it was a good thing. You use K memory like we use 'defines' in C parlance. Don't know if K memory is the best implementation for that, I think we could come up with a 'define' mechanism that would do the same thing.

Thanks for the input!!

[Controls Guy]

I actually have always thought of them as C #DEFINE's.  Great minds, I guess.  The only situation in which I can see any advantage to having K-memory vs. DEFINE's  is if another programmer comes along without the PC version of the code and uploads.  I assume the DEFINES would get converted to the constant on download and a virgin upload might show them as literal constants vs. symbolic ones.  OTOH, might be good for "know how protection"!

[Controls Guy]

Oh, yet another thought (YAT).  I like the AB flat-memory approach to PID loops.  PID is just a ladder instruction like anything else, and you can have as many of them as you have room for the data blocks.  I've run into the PID limit on AD PLC's several times or had to select a processor by how many loops it would support.

You blow those guys away with the built-in tuning screen, though.  I agree with the other guys about the desirability of having the trends continue to acquire and log even when a different loop (or no loop) is being viewed.  I realize memory might become an issue if you just by default did all the loops all the time, but maybe more fine grained manual control of the operation.  Maybe let us choose a couple loops and maybe even tailor depth and acquisition period to trade off between memory utilization and number of loops trended.

[BobO]

The new PLC will store essentially everything necessary to regen the full offline project, so one way or the other, we will find a way to get back to the original symbolic constant. We already brainstormed a bit and have a very workable plan. The question with most of this stuff is whether various features will be in rel 1, or 2, or 3 of the new control engine. Unlike previous controllers, we are moving to a view that the controller is nothing more than MIPS and megabytes, and that the control engine itself upgrades with the DirectSoft version.

Our current PID implementation is exactly as you describe, and you still get the loop tuning tools...although they are a bit different (and simplified) from the original DL implementation. We are using a more 'tinker toy' approach. Alarming in all forms, and ramp soak, filtering, etc., are all separate instructions. Rather than trying to create a single very complicated instruction, we chose to allow folks to stack just what they needed and keep stuff very simple.

As an example of what that buys us: You will be able to create a new program, add a couple of simple rungs, download to the PC-based control engine simulator, turn on the Sim's built-in FOPDT process simulator, pull up the PID trend view, and autotune the loop...in less than 5 minutes. Cool huh?

[Controls Guy]

Not just cool, but...WAY COOL!

[Controls Guy]

Massive kudos on nimble response to customer input!  AB can't even blow me off that fast.