Re: [foxboro] FDSI driver AB CSP or FDSI Driver Ethernet/IP
- From: Kevin Fitzgerrell <fitzgerrell@xxxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Fri, 1 Oct 2010 11:26:39 +0900
I'm sure your WAG is spot on. I even agree the generic base is a good
idea. Execution is where this failed.
I understand (I think) why we needed separate DCI blocks for the FDSI rather
than extend the existing AIN, CIN, MCIN, as these interact with the FDSI at
a fairly fundamental level. Since these were first announced on the
roadmap, user feedback has been that these need to be function and parameter
compatible with existing IO blocks. As you point out, it's stupid to go RIN
-> AIN -> just to get, say, alarming functionality. If the RIN had
connectable parameters compatible with the AIN, I could easily change over
in a migration without affecting links and function. Same with PAKIN and
MCIN. The critical part that was so badly missed was to give the PAKIN the
capability to present bits in the same orders and with the same outputs as
the MCIN. Why re-invent the wheel?
Even if DCI blocks couldn't be parameter compatible with standard IO blocks,
I still don't understand how we can be this far along (8 years with DCI
blocks? 4 years of AB FDSIs?) and not have resolved manual MCOUT
functionality or PAKIN bit ordering issues... As others have said in this
thread, it appears the FDSI driver development happened in a vacuum. What I
would have loved to see would have been to write the AB30 to FDSI Migration
document first - nail down all the necessary features, functions, example
block structures, etc and then build the drivers to meet that function.
Having said that, I've got to admit it is an ongoing battle in my own
company to get control narratives, truth tables and detailed functional
descriptions written before project engineering is "finished".
Regards,
Kevin
On Fri, Oct 1, 2010 at 10:20 AM, Jeremy Milum <jmilum@xxxxxxxxx> wrote:
> On Thu, Sep 30, 2010 at 7:49 PM, Kevin Fitzgerrell
> <fitzgerrell@xxxxxxxxx> wrote:
> > Foxboro does a pretty good job migrating from other systems, but
> migrating from their own
> > AB30s is apparently too challenging or not taken seriously enough.
>
> I am just making a WAG here, but I feel the issue may stem from a
> design decision to go to a more generic base for the interfaces, i.e.
> the FDSIs rather than all of the disparate integrator code bases. That
> allows them to unify everything under one umbrella and create a single
> programming API for creating the drivers for all of the interfaces to
> MODBUS, PROFIBUS, AB, etc.
>
> But it can come at a an operational cost (as all generic interfaces
> are prone to do): a loss of function if not implemented with great
> forethought. It's hard to be generic and still take the best
> advantages of all the different platforms you need to interface with.
>
> You can see an example of this even with the FBM224 -> FMB232. The 224
> was more limited in what it could interface with, yet only recently
> has the MODBUS driver for the 232 gained most of the functions of the
> 224 (and still lacks some)
>
> We experienced a very great loss of initial function with the starting
> DCI blocks. They were laughable when compared to AINs. They are much
> better now. But why couldn't the AIN itself be adapted? Throw in some
> new SCIx or IOMOPTs, or failing that give us a RIN that is a straight
> copy of the AIN and ADD the new stuff to that. And this goes for the
> rest of the DCI blocks like MCIN and PAKIN. Why lose features?
>
> I wonder if they did a use case analysis of this stuff before they
> re-implemented the blocks as DCIs?
>
> --
> Jeremy
>
>
>
_______________________________________________________________________
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: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
