[SecurityHat:ON]
Be careful where you put those VFD controllers on your TCP/IP network. Some
are susceptible to being taken offline by network events like broadcast
storms or port scans. I don't know the exact make/model of the ones
affected unfortunately, that info wasn't in the experience report.
There has been at least one documented outage caused by a two VFD devices
controlling what were supposed to be redundant motors in the power sector,
relating to the internals hanging up and failing the controller. The
failure mode from the network wasn't anticipated.
[SecurityHat:OFF]
Mike
On Wed, Nov 18, 2015 at 6:56 PM, Vandewater, Tom (HI Contractor) <
TVandewater.contractor@xxxxxxxxxxxxxx> wrote:
Chad,
I think you are right that you are overlapping addresses. That is
probably why you got the Duplicate Channel error on the Foxboro side prior
to MODBUS+DUPS modification in ECB201. The PAKIN/PAKOUT blocks read/write
32 bits by default so if you were reading packed Boolean values with a
PAKIN from MODBUS input register 30001 it would really be reading 16 bits
from 30001 and 16 bits from 30002. Likewise, if using a PAKOUT to write
holding register 40001 you would be writing 40001 and 40002 by default.
For a PAKIN reading contact input 10001 you would really be reading
10001-10032. To complicate issues some MODBUS implementations from
different vendors require Word/Byte swaps and some interpret individual
bits within the bytes in reverse order. There are a host of options within
the Foxboro MODBUS interface configuration to reverse engineer all of the
crazy things vendors do with MODBUS. If you see a MODBUS Address Point ID
in a Foxboro interface such as 40001:F4:
W3 you will know that the 3rd party vendor has done something funky to
bastardize MODBUS for their advantage.
Although it involves creating more blocks I prefer to use
individual BIN or BOUT blocks instead of PAKIN/PAKOUT blocks when unique
discrete values such as motor run status, valve limit switches, discrete
alarm statuses are being passed to/from 3rd party interfaces. The BIN's
and BOUT's read/write individual bits rather than groups of bits. It is
much easier for anyone to understand exactly which bit is being
accessed/written. Beware of the default feature of the BIN block however.
There is a parameter named .SELOPT whose default value is set to 1. SELOPT
= 1 means that the block will always initialize with a FALSE/ZERO value
regardless of what the actual MODBUS register value currently holds. This
means that if the BIN block alarm state is set to alarm on a FALSE/ZERO
input it will alarm anytime the block is downloaded even if the actual
MODBUS value is TRUE/1. It also means that any downstream logic/shutdown
block that uses the BIN's .CIN parameter could get t
oggled when modifying/downloading the BIN block. To make the BIN block
react like any other Foxboro block that hold the last value during
initialization, ALWAYS be sure to set .SELOPT = 0. Would really like to
locate the programmer responsible for the default SELOPT=1 setting so I
could smack him up side his boney head;<) Thanks again to Anthony
Stankiewicz for tipping me off about .SELOPT. It is easy to miss when
reading the BIN block documentation.
Cheers,
Tom VandeWater
Control Conversions, Inc.
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Chad Ziesemer
Sent: Wednesday, November 18, 2015 1:02 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Anyone using Cutler Hammer SVX drives with Foxboro?
Thanks for the tip Tom, I tried it and DUPS resolves the duplicate address
Foxboro error too. One other thing I'm noticing is if I have the PAKOUT
set-up without the *:C16 or *:C8 addresses (matching the table length
provided in the manual) and I toggle higher numbered bits on the packout,
the drive itself faults on a comms error. I have to have the DUPS
parameter in to make this work or the DCI blocks will show the "duplicate
address" error, so I'm assuming I'm overlapping addresses accidently. I
never quite figured out exactly what addresses on the drive I was toggling,
but it was none too happy.
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Vandewater, Tom (HI Contractor)
Sent: Wednesday, November 18, 2015 3:42 PM
To: 'foxboro@xxxxxxxxxxxxx'
Subject: Re: [foxboro] Anyone using Cutler Hammer SVX drives with Foxboro?
Chad,
Great write-up. I have sent similar stuff to the list to document
what I did for future reference for me, (and anyone else it might
benefit). I have even had new work referrals as a result of these
postings, (a side benefit of taking the time to document;<)
One thing you mentioned jumped out at me because it created some problems
for me in the past. You said:
" I ran into a lot of "duplicate address" errors when I put in multiple
DCI blocks."
The child ECB 201 only allows one DCI block reference to a MODBUS contact
input/output or register within its interface. By changing the ECB201
DVOPTS parameter as shown below you can have duplicate references.
from
DVOPTS: MODBUS
to
DVOPTS: MODBUS+DUPS
Regards,
Tom VandeWater
Control Conversions, Inc.
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Chad Ziesemer
Sent: Wednesday, November 18, 2015 11:27 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Anyone using Cutler Hammer SVX drives with Foxboro?
I wanted to follow-up to stuff the archive for anyone searching in the
future, including myself when I forget how to do this again in 2 weeks. We
successfully have a trial Cutler Hammer drive communicating well with an
FBM 232. So far we are able to control anything that can be done with hard
I/O and get any information available from the keypad.
Here's the set-up that worked:
Drive: Cutler Hammer SVX 9000 series
Drive option card: Modbus / TCP IP OPTCI-V, installs in expander slot D
Alternative: Eaton DG-1 series is supposed work exactly the same way but
has the Modbus comms card integrated as standard
Configuration: In the keypad change remote control option to "fieldbus"
and remote reference to "fieldbus".
FBM 232 connected to the comms card through a generic unmanaged Ethernet
swtich (was a Netgear JGS524, will be a phoenix contact) Also connected
with a crossover cable while troubleshooting and that worked as well, the
manual says explicitly it wouldn't work, not sure why.
ECB 200:
DEV_ID: GNBA08
HWTYPE: 232
SWTYPE: 232
PORTEX: 1
FILEID: GNAA08.XML
FSENAB: 0 (default)
FSDLAY: 1000 (default)
WDTMR: 10 (default)
SFILEID: MODBUS.ZIPH
SYSCFG: 1000 (default)
SYSOPT: 0 (default)
ECB 201:
NAME: VFD100
HWTYPE: 232
SWTYPE: 232
PARENT: GNBA08
DVNAME: 192.168.100.100
DVOPTS: MODBUS
PORTNO: 1
ERROPT : 0xFFFE (default)
All other options blank (default)
GNAA08.XML:
IP address: 192.168.100.99
Subnet mask: 255.255.255.0
Default Gateway: 192.168.100.99 (I have no idea what to put here or if it
even matters but it's working)
DCI block for controlling drive:
This is where I had the most troubles, I'm just barely understanding
Modbus life after all of this but it seems to be working well, so take all
this with a grain of salt. I ran into a lot of "duplicate address" errors
when I put in multiple DCI blocks. I learned that I need to add the :C16,
:C8, etc in the PKCOGP (where 16 represents the length of bits? in the
address space). According to the drive comms manual at address 00001 there
are 16 consecutive bits. When I left it without the :C16 it defaults to 32
bits and it didn't communicate.
Name: CONTROL
Type: PAKOUT
IOM_ID: VFD100
PKCOGP: 00001:C16
PKCOPT: 1
All other values default
Now toggling the following bits does the following (full memory map in the
cutler hamer manual)
IN_1 starts/stops
IN_2 fwd/rev
IN_3 fault reset
IN_4-IN_16 FBDIN1-10, I don't' use these or know what they do yet
Name: FEEDBACK
Type: PAKIN
IOM_ID: VFD100
PKINGP: 10001:C8
PKIOPT: 1
PAKCIN: 0
UPDPER: 10000
SIMOPT: 0
1 is ready confirm
2 is run confirm, 3-8 are other nice things to see
Then I added IIN blocks for any other value we want to see. One example
is torque feedback:
TYPE: IIN
IOM_ID: VFD100
PNT_NO: 410301
All other parameters default
All the other nice to know things are in addresses 410301 - 410325, so I'm
thinking I have to set up an IIN block for each one I care to watch.
Hopefully someday this helps someone else out there!
Chad Ziesemer
Control Systems Engineer
Cell: 920.427.9147
Desk: 920.886.2376
Galloway Company
601 South Commercial Street
PO Box 609, Neenah, WI 54957-0609
From: Chad Ziesemer
Sent: Thursday, November 05, 2015 5:20 PM
To: 'foxboro@xxxxxxxxxxxxx'
Subject: Anyone using Cutler Hammer SVX drives with Foxboro?
Is anyone else out there using Cutler Hammer (Eaton) SVX series drives at
their facility with Foxboro? I'm setting up a trial to communicate all of
the drive info into and out of Foxboro via an FBM 232. I'd love to hear in
general what your control set-up looks like and what your experience was:
smooth sailing or rough sledding.
Also I'll take this opportunity to see, is there anyone else on this list
using Foxboro reasonably close to Neenah, Wisconsin? We've got a small
group of engineers here that would love to network with someone local and
see what we can learn from each other.
Chad Ziesemer
Control Systems Engineer
Cell: 920.427.9147
Desk: 920.886.2376
Galloway Company
601 South Commercial Street
PO Box 609, Neenah, WI 54957-0609
_________________________________________________________________________
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
----------- Please note that my email address has changed. Please update
my contact information to reflect my address as forwarding for the old
address will end on January 1st 2016. The only change is modifying the
domain name of the email address from @ppetrol.com to @parpacific.com.
_________________________________________________________________________
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
