Foundation Fieldbus Microcontrollers

[Anand P. Paralkar]

Hi Everybody,

I am trying to build a positioner with Foundation Fieldbus support.

The system architecture would consist of:

a. Analog In (4 - 20 mA for position set-point input in manual mode).

b. Analog Out (4 - 20 mA position output to the pneumatic block).

c. Microcontroller to implement the PID control loop with support for
Foundation Fieldbus. (The primary role of the Foundation Fieldbus
interface is to accept the position set-point and to provide the
current position feedback in auto mode.)

I would like to know of any popular/standard microcontroller that offers:

1. The required peripherals to implement a Foundation Fieldbus
solution. (Preferably a dedicated peripheral such as a serial
port for Foundation Fieldbus.)

2. The complete Foundation Fieldbus software stack.

2. A reference design showing how the microcontroller that implements
the PID loop is interfaced to the physical layer.

I have tried searching for these type of microcontrollers on the
internet with few meaningful results.

I observe that there are some "ASICs" offered by a few not-so-popular
vendors that contain:

1. The dedicated Foundation Fieldbus controller.
2. Microcontroller interface.
3. The MAU or PHY interface.

Any comments on why the big players do not offer something similar or a
full-fledged solution?

Thank you for you for your help.

Thanks,
Anand

[Tim Wescott]

The reason the big players aren't in the market is because they feel that
the market isn't big enough for the trouble. This isn't surprising:
there are scads of CAN-enabled micros out there, because just about every
car in production has CAN on it these days -- and there are a lot more
cars than there are oil refineries.

So I'm not at all surprised at what you've found -- it's typical of the
size and nature of the market for the communications link that you want
to use. The best you can do is to suck it up and use what's there.

The only thing that I can suggest is that

(1) You may be able to implement the logic on an FPGA -- but I don't know
what analog requirements you may be left to fulfill.

(2) You don't have to buy the software stack from the same vendor as the
hardware, as long as everything plays well together.

(3) If you can make a microprocessor talk on FF correctly, and if you can
make a microprocessor successfully implement PID control correctly, then
making a microprocessor do both should be trivial.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

[Jamie]

FF is just a descriptive pipe dream, putting it bluntly that is.

If you want to do some research on bus type systems look at these.

ModBus:
http://en.wikipedia.org/wiki/Modbus

That is a very common protocol these days, even if it is old.

DeviceNet:

http://en.wikipedia.org/wiki/DeviceNet

This uses the CAN system originally done years ago by Bosch and
maybe closer to what you're looking for. This is, the layer is done
on the same type of physical transport but the protocols are more
advanced.


ControlNet:

http://en.wikipedia.org/wiki/ControlNet

THis is closer to what you're looking at but is old, if you use the
Device net, it springs from the COntrolNet which started from the
FieldBus. You may not like this one because it uses a single line. You
do see this in cases of fiber use.


Allen Bradley has a DH and DH+ (data highway) that is done over a few
busses, it is more of a protocol than anything else.

If you look at PLC's for automation, you'll find a lot more

Jamie

[Bruce Varley]

"Anand P. Paralkar" <anand.p...@gnospammale.com> wrote in message
news:9sdlrs...@mid.individual.net...

As others have pointed out, it's a consequence of the nature of the market.
The core business is selling devices that the process industries can use,
such as transmitters and packaged signal converters. Companies that sell
that gear are likely to have their own componentry, which sometimes
supplements the basic standard involved with supplier-specific
'enhancements' (sometimes they don't deserve that qualifier). Either way,
they're obviously not going to be amenable to supplying those devices to
outsiders.