I've never had the need to do it but...
I think you could play with the mappings of the parameters while in "Generate"
In "Use parameters mapping" change the selection from "Use columns names" to
"new" and make a new one.
then map everything as custom and you would be able to map DEV_ID to whatever
column you wish.
Or at least that would be my first shot.
Good luck
--------------------------------------------
El mié, 2/8/17, Vandewater, Tom <dmarc-noreply@xxxxxxxxxxxxx> escribió:
Asunto: Re: [foxboro] EVO - ECB Name v. ECB DEV_ID
A: "'foxboro@xxxxxxxxxxxxx'" <foxboro@xxxxxxxxxxxxx>
Fecha: miércoles, 8 de febrero de 2017, 01:36 pm
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.
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx
[mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Neufeld, Brahm
Sent: Tuesday,
February 07, 2017 8:10 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] EVO - ECB Name v. ECB
DEV_ID
Tom V's email
had some great info to consider.
Our site
has some ECB's with different names than the
DEV_ID's. Back in the ICC days our site decided to do
something like name the CP "C3AF00", then
they'd name the device "C3A184" but name the
block C3AF18_4. Not sure of the exact reasoning.
In order to have a DEV_ID
different from the ECB name with FCS, you can't have any
deployed blocks referencing the ECB, nor can the ECB be
deployed. You can rename DEV_ID's with DirectAccess,
with something like this:
<UpdateECBAttribute
Compound=”C3AF00_ECB” ECB=”C3AF18_4”
ParmName=”DEV_ID” ParmValue=”C3A184”/> NOTE -
doesn't work before FCS 6.1 (issue #1272350)
I can't recall the steps
to do this manually but I KNOW it's possible... I had to
do a whole bunch of these, so I did a few manually then made
a DA script to do the rest.
Not sure how useful this info is with BulkData
& SaveAll imports... we learned all of this through a
different set of circumstances!
Brahm Neufeld
_________________________________________________________________________
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
_________________________________________________________________________
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
