Thanks for that feedback Mr. Ricker. Could be useful to know sometime in the
future.
TJV
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On ;
Behalf Of William C Ricker
Sent: Wednesday, February 08, 2017 9:45 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] EVO - ECB Name v. ECB DEV_ID
Mr. VandeWater
"... disregards the exported ECB block name and replaces it by creating a new
block named the same as the DEV_ID parameter of the exported block..."
Yes, you have it exactly. I expect the IACC import would be no different.
What we have done is just what Arlie Bright suggested, using a Direct Access
script.
The script itself was generated by macros in a spreadsheet. The process then :
1 - import the SaveAll to BulkData
2 - Generate the ECBs
3 - Run the script with a line for each FBM
DirectAccess Syntax:
<RenameECB Compound='60CP01_ECB' OldName='110402'
NewName='BP0002' />
4 - Generate the rest of the data base
But it is always preferable to reduce the number of steps, or data
transformations needed to do such conversions, as each one provides an
opportunity to inject errors into the process.
This method does work, and in future, if ECBs are built (rather than imported)
tot editor does allow the ECB Block name and DEV_ID to be different.
WCR
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Vandewater, Tom (Redacted sender "TVandewater.contractor" for DMARC)
Sent: Tuesday, February 07, 2017 7:37 PM
To: 'foxboro@xxxxxxxxxxxxx' <foxboro@xxxxxxxxxxxxx>
Subject: Re: [foxboro] EVO - ECB Name v. ECB DEV_ID
To All,
I am still interested in knowing the answer to William Rickers original
question:
"In an EVO 6 system, when importing a SaveAll into BulkData and generating
blocks, it seems the block name for an ECB must always be the same as DEV_ID.
Does anyone know of a way to divorce these two? So that the DEV_ID and ECB NAME
can be different values, or, described differently, so the ECB Block name is
not overwritten by the value of DEV_ID."
If this does happen then I assume the same would happen if my client
were to export from their existing IACC database and import into "Control
Software" From what I understand everyone saying, it appears it disregards
the exported ECB block name and replaces it by creating a new block named the
same as the DEV_ID parameter of the exported block. Am I understanding that
correctly? That could be pretty bad. I say this because of the following
reasons.
I have seen the same name used for the ECB block, but a different
DEV_ID parameter name used when replacing 100 Series FBM's that had letterbugs
ID's that weren't compatible with the replacement 200 series FBM's. In those
cases we kept the ECB block name the same as the old 100 Series Letterbug ID,
but changed the DEV_ID parameter of the ECB blocks to be the new 200 series
physical location letterbug ID. This kept us from having to change the IOM_ID
parameter setting configured in all of the AIN, AOUT, CIN, and COUT IO blocks
spread throughout different compounds in the host CP. The IO blocks continued
to reference the same ECB block name which, in turn, used the new DEV_ID equal
to the new 200 Series Letterbug ID.
I have used the same ECB block name vs. DEV_ID parameter strategy to
combine four FCP270's that each had four 200 series baseplates, (Baseplate 0,
1, 2, 3), into a single FCP270 containing 16 baseplates. (Baseplate 0, 1, 2,
3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F). That required the use of a pair of
FEM100's but it allowed the customer to eliminate a lot of critical
Peer-to-Peer communications that they were forced to configure prior to the
time that the FCP supported more than four 200 series baseplates. It also
freed up three FCP270 FT for future projects.
Cheers,
Tom VandeWater
Control Conversions, Inc.
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at 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
