[foxboro] Modbus FBM, was "Back to forcing an ABSCAN to write, etc "

Hi,

> I thought one of the new Modbus FBM's was Modbus/TCPIP..=20
> which is still "serial" but at a greater throughput?=20

No, it supports serial links (RS232 and RS485) with up to 115kBit/s as =
far
as I know.

> If not.. the ONLY advantage would be the flexability of=20
> locations that the device could be installed,=20

No, it's much smaller than an integrator 30, cheaper, faster and =
supports
direct transmission of floating point values in a 4-Byte format =
(compatible
to the Triconex Modbus implementation), so that no conversion loss
(float-integer-float) is existing anymore.

That's cool. ;-)

Best regards -

Marcel Sieling
Systems Technologies

Invensys Systems GmbH
Heerdter Lohweg 53 - 55
40549 Duesseldorf
Germany
Tel.:  +49 (0)30-267-15542
Tel.:  +49 (0)211 5966-171
Fax:  +49-(0)172-50-2673077
Mobile:  +49-(0)172-2673077
Email: <mailto:msieling@xxxxxxxxxxx>=20
Homepage: <http://www.foxboro-deutschland.de>=20
Visit my private (german) homepage: <http://www.powerslider.de>=20



> -----Urspr=FCngliche Nachricht-----
> Von: Daren Bishop [mailto:dbisho@xxxxxxxxxxxx]
> Gesendet: Dienstag, 10. Dezember 2002 19:30
> An: foxboro@xxxxxxxxxxxxx
> Betreff: [foxboro] Re[2]: Back to forcing an ABSCAN to write, etc=20
>=20
>=20
>=20
>      Alex,
>     =20
> I thought one of the new Modbus FBM's was Modbus/TCPIP..=20
> which is still "serial"
> but at a greater throughput?=20
>=20
> If not.. the ONLY advantage would be the flexability of=20
> locations that the=20
> device could be installed, and all we have is the old=20
> "Mountain and Mohammed"=20
> scnenario! In other words.. if you don't move forward, it's a=20
> waste of time and=20
> money. Just another device that doesn't improve performance.
>=20
> Hopefully for David's sake the AB Integrator FBM will be=20
> ethernet or DH+ direct.
>=20
>=20
>=20
> ______________________________ Reply Separator=20
> _________________________________
> Subject: Re: [foxboro] Back to forcing an ABSCAN to write, etc=20
> Author:  <foxboro@xxxxxxxxxxxxx> at INTERNET-MAIL
> Date:    12/10/02 1:00 PM
>=20
>=20
>     =20
> Well, there's a Modbus FBM coming shortly for CP-60s under=20
> V6.5. Still it is=20
> only serial and only Modbus.
>     =20
>     =20
> FBMs for other PLCs and physical layers are in the mill, but ...
>     =20
>     =20
> Regards,
>     =20
> Alex Johnson
> Invensys
> 10707 Haddington
> Houston, TX 77063
> 713.722.2859 (office)
> 713.722.2700 (switchboard)
> 713.932.0222 (fax)
> ajohnson@xxxxxxxxxxx <mailto:ajohnson@xxxxxxxxxxx>=20
> For the latest information on ArchestrA, go to=20
> www.invensys.com/Archestra.html
> <http://www.invensys.com/divisions/Archestra.html> .
>     =20
>     =20
>         -----Original Message-----
>         From:        David Johnson [SMTP:DRJohn@xxxxxxxxxx]=20
>         Sent:        Tuesday, December 10, 2002 11:43 AM=20
>         To:        foxboro@xxxxxxxxxxxxx
>         Subject:        [foxboro] Back to forcing an ABSCAN=20
> to write, etc
>     =20
>     =20
>     =20
>     =20
>     =20
>         If there is not a way to force a write of the data=20
> table in event
> driven=20
>         mode, there should be!
>     =20
>         I can save a tremendous amount of my serial bandwidth=20
> between I/A
> and the=20
>         KF2 if I only write values to the PLC when they=20
> change.  I may have
> a set=20
>         of timer values that change once a week or less.  The=20
> longest period
> listed=20
>         in the book is 1024 seconds.  That would be OK in a=20
> polled situation
> except=20
>         if the operator changes a setpoint from an I/A screen=20
> it might take
> more=20
>         than 16 minutes for the change to be reflected in the=20
> system.  Not
> good.
>     =20
>         So we go look at event driven mode.  Values are=20
> written to the PLC
> only if=20
>         a change is made to the input side of the data.  Changes are
> transferred to=20
>         the PLC at the time that the operator makes the=20
> changes.  Very good.
> BUT,=20
>         suppose the PLC reboots, or fails in some other way=20
> that changes our
>     =20
>         values.  Unless we change the input side of the=20
> block, no write will
>     =20
>         occur.  So what we want to do is check a heartbeat=20
> signal and when=20
>         communication resumes after any absence force a write=20
> of all the
> data in=20
>         the event driven tables.  Then everything will be=20
> synced up.  I
> can't find=20
>         a mechanism to do this.
>     =20
>         I suppose one could code a method that would=20
>         a)read the PLC outputs back to I/A
>         b) compare these to the values of the inputs that we think =
I/A
> should write
>         c) if there is a difference
>             1) change the input value (to what is in the PLC,=20
> to be most
> bumpless)
>             2) change the value back to the correct value
>     =20
>         This seems to be way too much work for a problem this simple.
>     =20
>         Assuming there is not a good way to force a write, what are =
my
> options?
>     =20
>         RANT MODE ON
>         I HATE serial communications to PLCs! PLEASE get an=20
> FBM or CP based=20
>         ethernet solution out soon!  And yes I know about=20
> integrator 50s and
> 70s,=20
>         and yes Alex, I saw some promising things in Orlando,=20
> but I NEED an
> AB=20
>         integrator FBM NOW!
>         RANT MODE OFF
>     =20
>         Thanks,
>     =20
>         David
>     =20
>     =20
>     =20
>     =20
>     =20
>     =20
>     =20
>     =20
> ______________________________________________________________
> _________
>         This mailing list is neither sponsored nor endorsed=20
> by Invensys
> Process
>         Systems (formerly The Foxboro Company). Use the info=20
> you obtain here
> at
>         your own risks. Read
> http://www.thecassandraproject.org/disclaimer.html
>     =20
>         foxboro mailing list:
> http://www.freelists.org/list/foxboro
>         to subscribe:
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
>         to unsubscribe:
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
>     =20
>     =20
>     =20
> ______________________________________________________________
> _________=20
> This mailing list is neither sponsored nor endorsed by=20
> Invensys Process=20
> Systems (formerly The Foxboro Company). Use the info you=20
> obtain here at=20
> your own risks. Read=20
> http://www.thecassandraproject.org/disclaimer.html
>     =20
> foxboro mailing list:            =20
http://www.freelists.org/list/foxboro=20
to subscribe:         =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin=20
to unsubscribe:      =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
    =20
    =20

=20
=20
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
=20
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
to unsubscribe:      =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
=20
 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: