Dear Clyde!

We can write any strict requirement in the specification, but can guaranree it only with some probabilistic clauses. It is the key statement. The statement is simple and does not assume the myth about "determinism".

Agreed, the bus latencies can be a problem, as well as a lot of other issue, e.g. what is value of the time stamp if the sensor provide very large error? Result is the same - uncertainity. (and I omit the duscussion on the idea to time stamp data by the reciever side)

====
Best regards, Vladimir E. Zyubin

 

In reply to September, Clyde: If you are applying the time stamp at the point where you generate the data then you don't need a "real time" fieldbus. The time stamp takes care of that for you. If you are applying the time stamp at the other end but your trends are slow, then just about any fieldbus would be "real time" enough. The real question is what time resolution and accuracy do you need, and what fieldbus meets that specification?

The statement you quoted from me about "hot air" I think is fairly clear as to what it meant. If a particular application requires a "real time" fieldbus, then it requires it. Most applications do not. The "hot air" comes in when people speak as if real time fieldbuses are needed everywhere when clearly they are not. The hot air is being generated as part of marketing efforts to convince people they need the latest proprietary solutions in an over crowded market.

Have a look at what most people on this list use to control machinery - PLCs programmed in straight forward ladder logic. That is not a real time platform and hooking a "real time fieldbus" up to it doesn't make it one. If most people needed "real time" the PLC as we know it would be dead.

Mr. Zyubin doesn't like the term "real time" because he feels the amount of confusion it causes outweights the benefit of providing a semantic shorthand for certain types of applications. In a sense he is right, because we are having this conversation at this moment.

The question for selecting any fieldbus should be, does it meet the requirements of the application? If yes, then it is "real time enough". If it doesn't, then it isn't "real time enough". In that sense, any fieldbus can be "real time" for some applications and not for others.

When you are looking at fieldbuses from the standpoint of deciding what your plant should use, then that becomes as much a commercial decision as a technical one. If you have only one application for a special technology, if often makes sense to just worry about it for that one application.

It is easy to get yourself into a situation where your standard components are over-specced for most of your application because you are trying to find a universal solution. Instead you end up finding that all your machines are more complicated and expensive than they need to be because every component has to meet the most extreme requirement of any machine in the plant. Then your favourite vendor brings out his next generation of incompatible product and you find that your expensive standardisation effort was all for nothing.

On the other hand, you don't want a plant with one of everything in it. That is expensive and complicated too.

In each application there is a suitable trade-off between standardisation, special features, cost, and simplicity. That trade-off needs to be determined by experience and good judgement. I don't know what you need for your applications, but I know that just about any fieldbus would do for most.

 

<snipped lots of great info from Michael Griffin about testing response time over Ethernet>

Michael-

Thanks for the wonderful example! That's the kind of real-world stuff I like to see. Incidentally, we've been using Ethernet to control "real-time" I/O since the turn of the century! (That just sounds cooler than "8 years," doesn't it? )

However, as devil's advocate, I'd like to point out the following two lines:

"...The tests were conducted on an isolated network through a low cost switch...
I believe that Ethernet collisions are a red herring in this type of application..."

I think collisions ARE an issue. The thing is that they are relatively easy to eliminate. You mention this in your post, using a setup that inherently no collissions. Use switches, make sure everything is at full-duplex, try to minimize the number of device-to-device connections, and don't have any broadcasts. If you really have a lot of stuff broadcasting all the time, you can step up to a managed switch and have it block broadcasts. An example we found on our corporate network was a printer that had AppleTalk and NetBEUI turned on by default, sending spurious data out to announce its existence. Try not to have stuff like that on your mission critical network.

-James Ingraham
Sage Automation, Inc.

 

Dear Vladimir,

Very philosophical... I believe the issue to be much simpler - an inevitable consequence of events. Known and therefore predictable within the domain of the hardware. An area of predictability provided the hardware came from the OEM/advertising manufacturer.

Real time on the other hand simply refers to events happening within defined time period of each other (check & see immediately), not necessarily sequential, but could be.

Regards,
CWS