Re: [foxboro] FBM230 MODBUS RTU Mapping for Micro Motion Coriolis Transmitters
- From: Tom Vandewater <tjvandew@xxxxxxxxx>
- To: "foxboro@xxxxxxxxxxxxx" <foxboro@xxxxxxxxxxxxx>
- Date: Sat, 14 Mar 2015 06:51:55 -1000
Thanks for all of the descriptive help Pablo. It is appreciated. My next step
was heading to the field to see how things are wired. Do things normally look
good in System Manager, (ECB online and DCI Ready), even when field wiring and
settings are not correct?
Tom
> On Mar 14, 2015, at 4:15 AM, Pablo Lioi <plioi@xxxxxxxxxxx> wrote:
>
> Tom,
> @10 configures a 1 second scan rate on the port. If omitted, the scan rate
> defaults to 500 ms.
> TO0 configures a 3 seconds response timeout on the port. If omitted, the
> timeout defaults to a value dependent on the baudrate, for 9600 bps the
> default timeout is 500 ms.
>
> You can find this information in B0700BG, but be careful which revision of
> the document you use. Have a look at the info page of the FBM230 in SDMH to
> determine the version of your Modbus driver. If it is version 1.1 use B0700BG
> rev C. If the driver is newer, you have more configuration options and device
> counters.
>
> Even though you are using RS-485, you have to set the RS-232 switches for the
> port at the TA. Leave all the switches open, except C5 and C6, which should
> be closed. Refer to B0700AH for details. Current revision of the document is
> R, earlier versions of this document didn't mention switch C6, which is a bit
> confusing. Also check wiring and terminations for RS-485.
> Whenever you make a change to the xml configuration file, you should perform
> a "DB Download" in SMDH. This doesn't always work well. I've observed that
> sometimes, after making a change in port configuration and downloading it to
> the FBM230, the port still worked according to the old configuration. The
> only work around I found was re-downloading the driver (SOFT DOWNLOAD), wait
> for the FBM to finish and reboot and then doing a DB Download. Of course this
> means losing all communications on the FBM for several minutes...
> I strongly suggest you use a protocol analyser to look at the line and see
> what's really going on there. If you don't have a protocol analyser, you
> should at least try to poll the slave from a notebook with a Modbus Master
> program. Another good test is to replace the slave with a notebook with a
> modbus slave simulator program.
> Good luck
> Regards
> Pablo Lioi
>
>> From: TVandewater.contractor@xxxxxxxxxxx
>> To: foxboro@xxxxxxxxxxxxx
>> Subject: Re: [foxboro] FBM230 MODBUS RTU Mapping for Micro Motion Coriolis
>> Transmitters
>> Date: Sat, 14 Mar 2015 02:03:49 +0000
>>
>> Pablo,
>> Thanks for all of the information. It is good to know that the Micro
>> Motion interface is using the 40001 holding register range. I have tried
>> all of the PNT_NO settings you suggested but to no avail. My "LPGFLW"
>> MODBUS interface immediately indicates "Device Failed" in System Manager and
>> I get a "W62 - UNRESOLVED CONNECTION" message on the RIN block detail
>> display and everything turns CYAN as soon as I configure an RIN block to
>> read ANY data through the interface.
>> Prior to the first read, everything looks good in System Manager. Even
>> when I remove the read request from the RIN block by placing the block in
>> SIMOPT and downloading again, (which clears the block from CYAN) the
>> interface shows failed in System Manager until I disable the "LPGFLW" MODBUS
>> interface and re-enable it. The system Manager shows everything is good
>> again until I make a data request from the interface.
>> I went back to check the FBM230 .XML file located in
>> /usr/fox/sp/files/devices/3C0304.XML to determine that the communication
>> parameters are set the same in the .XML file as they are in the Micro Motion
>> Coriolis Transmitter. The settings for Port2 in the .XML file are as
>> follows:
>>
>> <name>Port 2</name> This matches the
>> port to which the Micro Motion is connected
>> <mode>RS-485</ mode> The Micro Motion
>> communicates via RS-485
>> <baud_rate>9600</baud_rate> The Micro Motion is set
>> to communicate at 9600 Baud rate
>> <parity>Even</parity > The Micro
>> Motion is set for Even parity
>> <stop_bits>1</stop_bits> The Micro Motion
>> is set for 1 stop bit
>> <data_bits>8</data_bits> The Micro Motion
>> is set for 8 data bits
>> <driver>Modbus+@10+TO0</driver> ???????? What does @10 mean?
>>
>> I am unclear what the "@10" in the last line under , <driver>, means.
>> Does anyone know? I believe the +TO0 refers to the device watchdog timeout
>> value. I have another Modbus interface port on the other FBM230 that
>> doesn't have the "+@10+TO0" and it seems to work okay with just the
>> following:
>> <driver>Modbus</driver>
>>
>> Mahalo for any help anyone can give,
>> Tom VandeWater
>> Control Conversions, Inc.
>>
>> -----Original Message-----
>> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
>> Behalf Of Pablo Lioi
>> Sent: Friday, March 13, 2015 1:04 PM
>> To: foxboro@xxxxxxxxxxxxx
>> Subject: Re: [foxboro] FBM230 MODBUS RTU Mapping for Micro Motion Coriolis
>> Transmitters
>>
>> Tom,
>> In our plant we have two CFM300 Coriolis flowmeters with 3700 transmitters
>> (exact model number is 3700A2B06DUEZNZ).
>> We are reading them with a PLC5 Prosoft Modbus Module, using Modbus RTU.
>> Mass Flow Rate is read from registers 246 and 247 with function code 03
>> (Read Holding Registers). Both registers are then assembled into a floating
>> point register, with previous word swapping.
>> This means that:
>> 1 - They are holding registers.
>> 2 - As the Prosoft Module is 0-based, 246 would be 40247 and 247 would be
>> 40248, in accordance with the manual.
>> 3 - You should read using a RIN block. PNT_NO should be 40247:F4:Wx where
>> "Wx" is to be determined by trial and error, but I would start with W3, as
>> this swaps word pairs in the response message, as our configuration in the
>> Prosoft Module. If this doesn't work, you should try with W1 and W2. If
>> nothing of this works, you should repeat with register numbers 40246 and
>> 40248.
>> I hope this helps. I will post another message with my conclusions so far as
>> to my "FBM230 slave response too fast" problem that may also be relevant to
>> your problem if nothing works.
>> Regards
>> Pablo Lioi
>> Total Austral S.A.
>> Tierra del Fuego
>> Argentina
>>
>>> From: TVandewater.contractor@xxxxxxxxxxx
>>> To: foxboro@xxxxxxxxxxxxx
>>> Subject: Re: [foxboro] FBM230 MODBUS RTU Mapping for Micro Motion
>>> Coriolis Transmitters
>>> Date: Fri, 13 Mar 2015 19:55:13 +0000
>>>
>>> Matt,
>>>
>>> It is a CMF200 Coriolis with a 3700 (3000 MVD series) field mount
>>> transmitter.
>>> Are you communicating FBM230 MODBUS RTU with any Micro Motion Coriolis
>>> Transmitters?
>>>
>>> Thanks for any help you can give.
>>>
>>> Tom
>>>
>>> -----Original Message-----
>>> From: foxboro-bounce@xxxxxxxxxxxxx
>>> [mailto:foxboro-bounce@xxxxxxxxxxxxx] On Behalf Of Kinsinger, Matthew
>>> R
>>> Sent: Friday, March 13, 2015 9:48 AM
>>> To: foxboro@xxxxxxxxxxxxx
>>> Subject: Re: [foxboro] FBM230 MODBUS RTU Mapping for Micro Motion
>>> Coriolis Transmitters
>>>
>>> Which micromotion model? They had some issues with some models, and stated
>>> communications capabilities and available registers, that were not truly
>>> available for non micro-motion device communication.
>>>
>>> Matt Kinsinger
>>> mkinsinger@xxxxxxx
>>> 330-825-1208 office
>>> 330-472-1454 ppg cell
>>>
>>> -----Original Message-----
>>> From: foxboro-bounce@xxxxxxxxxxxxx
>>> [mailto:foxboro-bounce@xxxxxxxxxxxxx] On Behalf Of Vandewater, Tom (HI
>>> Contractor)
>>> Sent: Friday, March 13, 2015 3:20 PM
>>> To: 'foxboro@xxxxxxxxxxxxx'
>>> Subject: [foxboro] FBM230 MODBUS RTU Mapping for Micro Motion Coriolis
>>> Transmitters
>>>
>>> To All,
>>> I read with interest responses to Pablo's FBM230 Modbus interface
>>> issues because I just inherited a failed attempt to interface a Micro
>>> Motion Coriolis Transmitter via Modbus RTU protocol and am trying to sort
>>> out if it is a problem with the FBM230 installation, the Modbus driver
>>> configuration/installation, or the way I am requesting data from the
>>> interface. (I suspect the data request because the interface shows that
>>> the DCI is "Ready" with no failure until I make my first/only data request
>>> from this device). I know this is Friday the 13th but am still hoping to
>>> resolve this issue on this fateful day if possible. All responses are
>>> appreciated. Don't hate me because it is early in the morning here in
>>> Hawaii and you may be dealing with a pile in snow near Foxboro, MA;<)
>>>
>>> My first question to the amazing repository of Foxboro info stored in all
>>> of your heads is this:
>>>
>>> Is anyone out there using an FBM230 and MODBUS RTU to communicate with
>>> Micro Motion Coriolis Transmitters?
>>>
>>> If so, can you tell me whether you use an "RIN" or "IIN" block and what is
>>> in your "Pnt_no" configuration for the Mass Flow Rate register polling?
>>>
>>> The Micro Motion manual I am looking at shows this for the Modbus address
>>> for the Mass Flow Rate:
>>>
>>> 0247 0248 RO Mass flow rate
>>>
>>> I am assuming that since there are two registers to read I probably
>>> need to issue a command that swaps words or even bits, (based on
>>> previous fun I've had), but there is not enough info in the manual
>>> for me to know. Since the leading number for the MODBUS register type
>>> has been omitted from the Micro Motion document it is also unclear if
>>> the data is being stored in MODBUS standard 30001-39999 input
>>> registers, or the 40001-49999 holding registers. I have put both
>>> 30247, and 40247 in the "Pnt_no" configuration with no success. Each
>>> time I try to issue a read request via either an RIN or IIN block, my
>>> "LPGFLW" MODBUS interface immediately indicates "Device Failed" in
>>> System Manager and I get a "W62 - UNRESOLVED CONNECTION" message on
>>> the RIN block detail display and everything turns CYAN. Even when I
>>> remove the read request from the IIN or RIN block by placing the block
>>> in SIMOPT and downloading which clears the block from CYAN and causes
>>> no data requests to the interfac
>> e
>>> the "Device Failed" status remains in System Manager until I disable and
>>> enable the interface. It looks healthy until I make another read request
>>> from the interface.
>>>
>>> Any help here is greatly appreciated.
>>>
>>> Tom VandeWater
>>> Control Conversions, Inc.
>>
>>
>> _______________________________________________________________________
>> 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
>
>
>
> _______________________________________________________________________
> 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
>
_______________________________________________________________________
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:
