MRAM comes to market

monkeyhead

Member
Join Date
Sep 2004
Location
I'm right here
Posts
656
http://www.cnn.com/2006/TECH/ptech/07/10/magnetic.memory.ap/index.html
http://en.wikipedia.org/wiki/MRAM

-- 4 Mbit (marketing murmers have promised as high as 25, but so far Freescale is the only one to come forward with an actual product.)
-- Retains memory through a power outage.
-- On par for speed with DRAM.
-- Won't degrade over time like flash and blows flash out of the water speedwise.

This one's got PLC written all over it.

Can't wait till they start stamping these things out hard drive sized... talk about a snappy damn computer.
 
Interesting link. I'm old enough to have worked with the original ferrite core memory boards.

If MRAM is ever used in volume then it certainly has the potential to change automation industry hardware dramatically. Ultimately it could go a long way to eliminating the distinction between "soft" and "hard" PLC's.
 
In all the times I've read about 'core' memory, it never realized it was non-volatile.

So it sounds like MRAM will have the advantages of old school core but with speeds comprable to what's on the market today.
 
I wouldn't be too hasty on the "soft/hard" plc thing. Yes, they could have a huge impact on automation hardware, but the difference between soft and hard plc's - aside from the predictable obsolesence of PC hardware of course - is in the OS.

PLCs have a reduced instruction set and are designed to do a limited amount and kind of work reliably. PCs use general-purpose consumer OS that crashes if your kid looks at porno. Even so-called "self-contained" soft PLCs, like Beckhoff and VLC, depend on Winblows to do alot of the grunt work of keyboards, mice, displays, hard drive management, abstraction layers - you know, all the stuff Winblows stinks at...

This development, while significant, is significant for other reasons besides this.

TM
 
Not in any particular order...

Tim said,

"PLCs have a reduced instruction set and are designed to do a limited amount and kind of work reliably."

As far as limited amount of work, and limited kind of work, you are absolutely correct! I have ALWAYS proclaimed that a PLC operating system is nothing more than a "limited", that is, "crippled", PC system. ALL PLCs are nothing more than PCs with "limited" functionality!

Now, as far as that word... "reliably"...

Are you saying that a PLC will "reliably" do exactly what it is told to do? The same applies to ANY program, in ANY computer, in ANY form!

The question is... is the program "reliable"?

Any idiot can jump in a TRY to program a PLC. However, does that make the program "reliable"? OF COURSE NOT! Nor does the simple exercise of entering a program into a PLC make it more reliable than entering the same program into a PC! Any idiot-programmer will screw-up either system!

If the guy doesn't know what the hell he's doing, doing it on a PLC will NOT make it run more "reliably"!

Then Tim said...

"...obsolesence of PC hardware..."

This is a bit tougher to address...

In a PC, the key component to I/O is a "card". The "card" plugs into a slot. I began working with ISA-slots. That moved on to EISA-slots, then PCI-slots.

The Mother Board holds the slots... as time goes on, Mother Boards tend to move forward and adjust to the latest popular card-types. But then, as time goes on, you should expect that the card that you are currently using to maintain I/O communication should be updated to the latest slot-type. After all, essentially, it's nothing more than a physical change.

Tim said...

"...but the difference between soft and hard plc's... is in the OS."

As far as the O/S goes...

I've NEVER maintained any kind of faith in any Windows systems for Automation. But, I've ALWAYS maintained faith in DOS! DOS is pret-ty damned SOLID!

I'm working with two primary systems these days; one is DOS-based, the other is Windows-based. The DOS-based system (TI) NEVER fails! The Windows based system (AB) OFTEN fails!

Bottom Line...

Soft-PLCs are coming! In fact, they are already here! AND they are running in a PLC! The PLC happens to be the PLC that runs ControlLogix-5000!

Except for the constraints imposed by AB, such as the loss of Indirect Addressing (God! What a loss!), ControlLogix-5000 is operating in a manner that is exactly the same as a normal PC!

The key-point here is the way that ControlLogix-5000 handles Inputs. At any given time, if your 5000 code refers directly to the particular Input, it WILL NOT be referring to the Input Image Table! Instead, it will refer to the current condition of the input, between scans! This means... you DO NOT have the typical, expected, Snap-Shot of the Input conditions!

Why?

Because there is no Input Image Table! There is no Input Image Table unless YOU actually go through the steps to create one! And THAT, creating an Input Image Table, is the very technique used by Soft-PLCs to mimic regular PLCs!

It is getting to the point that the only difference between Hard-PLCs and Soft-PLCs is the actual hardware, and of course, the logo printed on the various parts.

As it stands, Large PLCs, with modules that plug into slots, have been reduced to a series of "bricks" with inter-connecting cables.

The problem with these is that, when an Output is lost (burned, failed, whatever), you have to replace that entire "brick" (if you don't happen to have spare outputs in that brick). There is no individual Output protection. Of course, that can be handled by installing individual, external, protection for each Output. (That is a concept that I have been promoting forever!)

However, looking into my "8-Ball"... I see... it's foggy, but... I see... Outputs consisting of "Triggers"! Nothing but "triggers". That is, the output DOES NOT consist of current that is capable of handling the particular load... rather, the "trigger" is applied to a unique, external, individual module which controls a unique output device!

In other words, the PLC Output simply passes a "trigger-signal" to something like an individual OPTO-22 Output Module. I also see that the "trigger-signal" is protected, internally, by a short-circuit scheme, just like what you find in many sensors these days.

When that happens... the difference between Hard-PLC and Soft-PLC will be nothing more than blind loyalty to... a has-been.

I can't hardly wait!
 
I gave very serious thought to concluding my last post with a two-word paragraph: "Hi Terry!" :p

Terry Woods said:
Tim said,

"PLCs have a reduced instruction set and are designed to do a limited amount and kind of work reliably."

As far as limited amount of work, and limited kind of work, you are absolutely correct! I have ALWAYS proclaimed that a PLC operating system is nothing more than a "limited", that is, "crippled", PC system. ALL PLCs are nothing more than PCs with "limited" functionality!

I was thinking of you as I wrote it :) Not kidding, really was!

Terry Woods said:
Now, as far as that word... "reliably"...

It depends...

I will submit that the parts in a PLC are better quality than in your average Dell. I've yet to lose a Unitronics hard drive, or an AB floppy drive (lost a few of their floppies over the years, tho')

That's why I harp on the OS. Some people like Linux because it's free, but power users like it because it's trustworthy. You said it yourself - DOS is INFINITELY more durable than Winblows has ever been, and any softPLC that starts from Bill Gates' bloated albatross has "built their house upon the shifting sands".

As for a garbage program - I'll get semantic on you :

A PLC will run a good program reliably with predictable results.

A PLC will run a garbage program reliably with unpredictable results.

A PC with Windows will run either kind of program - with unpredictable results. Even a good program is reduced to the level of the lowest common denominator - the OS.

Terry Woods said:
The Mother Board holds the slots... as time goes on, Mother Boards tend to move forward and adjust to the latest popular card-types. But then, as time goes on, you should expect that the card that you are currently using to maintain I/O communication should be updated to the latest slot-type. After all, essentially, it's nothing more than a physical change.

Precisely my point. The new MRAM is ultimately a physical change, and will enhance performance over slower flash-based products - but it will do nothing to improve a poor-quality OS.

Terry Woods said:
Soft-PLCs are coming! In fact, they are already here! AND they are running in a PLC! The PLC happens to be the PLC that runs ControlLogix-5000!

I can get a VLC-based "Embedded PLC" running under Windows CE from Pheonix Contact - but I'd sooner build my controls system around a parrot. Nothing but "soft in a hard box".

http://www.123compute.net/dreaming/knocking/alex.html


Terry Woods said:
The key-point here is the way that ControlLogix-5000 handles Inputs. At any given time, if your 5000 code refers directly to the particular Input, it WILL NOT be referring to the Input Image Table! Instead, it will refer to the current condition of the input, between scans! This means... you DO NOT have the typical, expected, Snap-Shot of the Input conditions!

I've spent two weeks doing intense programming on a Trio motion controller, and I like it! But getting my brain into BASIC after so long in ladder was a struggle at first.

One thing I did not care for was the lack of an input image table! I LIKE that my inputs are fixed and determined at the start of the scan. I LIKE that my outputs are set at the end, and ONLY at the end. If I need to do something immediately, I have Immediate instructions for that.

Why?

Determinism. I want total control in an orderly manner. The idea that I could write a ladder, check an input in two different places in that ladder, and get two different results - it's chaos, man! Human sacrifice, dogs and cats living together - mass hysteria.

Terry Woods said:
However, looking into my "8-Ball"... I see... it's foggy, but... I see... Outputs consisting of "Triggers"! Nothing but "triggers". That is, the output DOES NOT consist of current that is capable of handling the particular load... rather, the "trigger" is applied to a unique, external, individual module which controls a unique output device!

In other words, the PLC Output simply passes a "trigger-signal" to something like an individual OPTO-22 Output Module. I also see that the "trigger-signal" is protected, internally, by a short-circuit scheme, just like what you find in many sensors these days.

This one I don't quite grasp - sounds like any basic IO network. Devicenet, modbus, take yer pick. I can get an encoder module from Beckhoff, tie it to my trusty Unitronics Vision 280, and do simple servo control. I wouldn't, because the comparatively slow scan time of a V280 (6-8 mS typical) would not be responsive enough for most applications - but I COULD!

Having been victimized by the tag team of VLC and devicenet on numerous occasions (in the dropped-the-soap-in-the-prison-shower sense), I can personally attest that this combination of soft and hardware is still hindered by it's lowest common denominator - Winblows.

Terry Woods said:
When that happens... the difference between Hard-PLC and Soft-PLC will be nothing more than blind loyalty to... a has-been.

I can't hardly wait!

I simply beg to differ. While the day may yet come when PC control gets reliable enough to be trusted, I don't expect to see it actively ousting the PLC before I retire. These workhorse controllers are just more dependable, and it will be many years before PC controls can overcome the damage done to their reputation 10 years ago when everybody thought they were the cat's meow - until the Y2K bug. And Michelangelo. And PCI displaced ISA. And...

TM
 
A few topics

On MRAM
As a manufacturer I find MRAM very interesting and will look into it. At this time battery backed up ram is a big pain in the .. because our product requires fast memory which also means high power. We could use two different memories but that means needing buffers to keep the two memory types separate. It also mean we must account for fast and slow speed ram areas with different wait states. All this increases costs. I am sure the MRAM cost MUCH more than the ram we use now. Eventually the extra cost of the MRAM will be compensated for by simpler design, less heat and less space. At that time MRAM will rule.

On reduced instruction set PLCs.
I bet that the Control Logix and S7 have MORE instructions than a typical micro controller. The difference is that a micro controller or DSP will have more addressing modes than just direct and indexed addressing. I think the DSP I use has 11 addressing modes. I don't think the average PLC programmer would know how to use them.

Even the programming language C has less that 30 reserved symbols or words.

On soft vs hard PLC
I know how PLCs are environmentally tested. I doubt a PC could handle the shaking, the thermal shock and the electrical tests.

On determinism.
Determinism is a must for motion control and many other real time applications. TM, has given a couple reasons but I don't think they are the most important. I think it is important to have a repeatable process. It is important that a motion profile is executed exactly the same way for each piece. It is important that the change in state in I/O be detected at known intervals so registration applications always perform the same way.

I can graph the motion of a flying shear at the 0.5 or 1.0 millisecond increments and compare one graph to the next so the effect of gain changes can be seen at these fine increments.

I see the lack of determinism as one of the few weak spots of the Control Logix but that is OK. When people want something deterministic they can contact me. We execute our control program synchronously with the control loop and target generator. This has numerous advantages over executing a basic in the background. How much would it mean to you if your PLC had a .5 or 1 millisecond scan?
 
Terry makes some very valid opservations from his position high in the mountains of Utopia.

IN A PERFECT WORLD I would tend to agree that systems based on PC technology are a good way to go. However, as others have already pointed out, standard PCs won't handle industrial environments anywhere near as well as a PLC. The exception MAY be industrial and embedded PCs, but they tend to resemble PLCs as much as they do PCs.

But even outside of that replacement availablility is a real issue. I can't get my 3 year old Dell 2400 anymore. But I can call my AB distributor and get a 15 year old PLC5/20 today. If everyone had a Terry Woods on site to straighten out all the driver issues you run into as you change PC platforms it wouldn't be a big deal. But the fact is that most do not. So while you can easily argue the relative benefits of every company having a Terry Woods on staff, it is a rather utopian position to believe that all of them will. Given that, I would rather take my PLC5/20, where I can jam an EEPROM into it's mouth and slam it in the rack and be back up in 5 minutes, over a PC.

Keep in mind that I am speaking for 99% of the automation market here. As Peter pointed out there are obviously application where performance is paramount. In that case it makes sense to get out on the edge a little farther. But for most of the market the baseline stability, simplicity, reliability and maintainability of most PLC systems is hard to argue with.

Keith
 
The PC I use on the Internet does not have RSLogix5000 loaded on it, and that one is away from home on site at present, so uploading an example is not simple for me to do right now...but:

Every time you create an array, all the array elements are denoted with a number in square brackets, eg:

An array of DINT's called History, say 100 elements long is:

History[0]
History[1]
.
.
History[99]

Now if you have another variable, say Index (DINT), then there is no problem writing:

History[Index]

It works with arrays of UDT tags and two and three dimensional arrays. The only limitation I have found is that you cannot nest array elements , ie it will balk at:

History[AnotherIndex[Index]]
 
PhilipW said:
History[Index]
That is indexed not indirect addressing.

PhilipW said:
It works with arrays of UDT tags and two and three dimensional arrays. The only limitation I have found is that you cannot nest array elements , ie it will balk at:

History[AnotherIndex[Index]]
Index1 = AnotherIndex[index];
History[Index1]

This is still nested indexed addressing. This is not using addresses or pointers. I can see where you might call this indirect because of the extra array. You must have an application where you shift or rotate the indexes instead of moving the data base. This makes accessing the data simple because a certain event will always be at a fixed index.

Now you have me wondering if our controller can handle the nested indexing. I will try it.
 
Fram

FRAM has been has been around for awhile. This is what we use when we want non-volatile ram. If you look at the specifications you can see that it is too slow for DSPs and other faster processors that we would use. Therefore we can't use FRAM as main memory.
http://www.ramtron.com/doc/Products/nonvolatile/default.asp

What we will do with this is save off only memory locations that need to be saved like production counters. We can save the initial values for parameters in flash. When a power loss is detected we can save away just the few items that need to be backed up in the millisecond or so before power is really gone.
 
That is indexed not indirect addressing.

I am well aware of the semantic difference between indexed and indirect addressing, and I read Terry's long rant on the topic a week ago.

An Index is a value that indirects to an offset within an array. Checking the bounds of an Index for valid values is a fairly simple matter.

A Pointer holds an address that indirects to any other address. Checking that you always have a valid pointer is one of the more challenging tasks in computer science.

Indexing is simply a subset of the more general case of Indirection. Given that it that fulfils almost all indirection requirements in the automation game, and is simple and robust...my answer is "So what".
 

Similar Topics

I'm a beginner in the automation field and I've set up an automation system connecting several devices (datalogger, radio, etc.) via Modbus RS485...
Replies
5
Views
240
struggling to find documentation on this, I have it in my head that it overwrites itself but i dont know where i have got that from. when it...
Replies
0
Views
898
Hello, Now here is my problem guys. I weigh my weight and i wait for the slow_fill_required_weight to be lesser than my slow fill limit which is...
Replies
7
Views
1,830
Good Evening , I took notice that the majority of the gearboxes we have in our plant are SEW Eurodrive . I started wondering , of all the...
Replies
14
Views
4,224
Hi, I have CRU320 CPU with two RMX128 modules on Primary and Secondary rack works as a redundant system. Some how if the fiber link between two...
Replies
0
Views
1,578
Back
Top Bottom