BigE (Customer) asked a question.
How to create and test a program for Modbus Client/Server
Am attempting to use BRX as a Modbus TCP Server for the first time. How do I allow the client to access PLC physical IO? Example how to trigger physical input X0 or output Y0? How to allow client to read numerical data? Will be setting up two BRX plc to test. Have successfully created programs allowing BRX to be the master/client with other third party devices so I understand the basics of setting up Modbus RTU and TCP and using the MWX and MRX instructions.
Take a look at Help Topic DMD0251. This will provide a lot more detail, but here is a quick snippet:
"All Modbus Read and Write requests from external devices will be serviced from the four built-in memory blocks that are reserved for use by theDo-more controller's Modbus Server (Slave) device, they are: MC (ModbusCoils), MI (Modbus Inputs), MHR (Modbus Holding Registers), and MIR (ModbusInput Registers). The Modbus Server only has access to the MI, MC, MIR,and MHR memory blocks in the controller, it cannot access the other (native)memory blocks or the I/O in the controller."
I hope this helps.
Typically you don't directly control I/O of a PLC (the PLC ladder logic does that). If you want a "dumb" I/O system, look at the BX-MBIO or BX-EBC100.
Not sure how a Modbus client can trigger a physical input (X0). If you just want to see the internal memory change, the Modbus Server memory areas are what emulate a Modbus Slave (Server), i.e. MC (Coil) MI (Input) MHR (Holding Register) and MIR (Input Register). Note that these blocks are 1-based addresses, so Modbus Holding Register 40001 is actually MHR1 (mask off the leading "type" address for the Do-more Modbus address).
If you are not wanting just dumb I/O, but you want to actually control Y0 both via ladder logic rung and via a Modbus Master, please explain what you are wanting. Possibly you want some subset of Y's controlled via the PLC but other Y's controlled via the Modbus Master, or you want the PLC to control the Y's, but then have a mode of the PLC logic where the Modbus Master can have control (e.g. auto vs. manual/override control???), or ???
I actually want a client/master to be able to control the "system".
Basically like having a remote operator terminal. So we'll say X0 is start,
X1 is stop, X2 is reset, I want the client to be able to start/stop/reset
the system. I don't want the master to be able to override the ladder logic
control and energize any output any time as this would mess up how the
"system" is controlled.
I may allow client to manually control physical discrete outputs for testing
purposes..
Then the client will need access to numerical data such as motor amps,
system pressure, etc. A pressure setpoint (currently a V memory in my ladder
logic) and other numerical entries needs to be written to PLC by the client.
I understand that I need to use the "M' based memory. I don't know how to
incorporate into my ladder logic.
The client is a BACnet based BAS. The customer requires me to supply the
Modbus registers
Eric Epema
Tech Support/PLC Programming
416-744-4276 X226
Treat everything as internal memory. Write ladder logic that drives the outputs appropriately and overrides the local inputs appropriately. You probably just want to use MHR memory for all of your "I/O". You may want to use MC's. You can't write to MI's or MIR's, hence why you limit yourself to MHR and possibly MC's for all your "remote terminal" access. If they wanted to MONITOR ONLY X's and WX's, you could use MI's and MIR's for that purpose (in addition to using MHR and MC's for numeric and discrete "i/o" sourcing).
I am going to test this using 2 BRX. Any suggestions for a simple test run would be great. I am a self taught (untrained) "programmer" who excels when
I have a sample to work with
Eric Epema
Tech Support/PLC Programming
416-744-4276 X226
These same bits can be assigned to an MC if desired?
So I can use MHR as a memory location readable by Client correct?
Eric Epema
Tech Support/PLC Programming
416-744-4276 X226
Hi @BigE (Customer)
The following post may help you out.
https://accautomation.ca/modbus-rtu-click-plc-master-to-brx-plc-slave-communication/
This uses a Click PLC as the Client (Master) and the BRX Do-More as a Server (Slave).
Regards,
Garry
https://accautomation.ca/series/brx-do-more-plc/
We use a Click as a crash test d*mmy - it's inexpensive, easy to use, and has RS232, RS485, & Modbus TCP as well as EthernetIP.
Cheers,
Bushpig
Am now trying to scale analog values directly to a holding register. Example WX0 In to MHR100 Out using 6553 In Min, 32767 In Max, 0 Out Min and 65535 Out Max. With this scaling I am seeing an output of -1 when input is full 32767. I expected to see 65535.
In Do-more MHR block data type is a signed 2's complement 16 bit integer by default, so MHR has a range of -32768 (0x8000) to +32767 (0x7FFF). To utilize MHR100 as an Unsigned Value, cast it as MHR100:U and you will get the expected result, where -1 integer as a hex value in memory is 0xFFFF, which as unsigned evaluation becomes 65535. So change your SCALE output parameter from MHR100 to MHR100:U. Also, in a Data View or Trend View, do the same, enter the cast MHR100:U. You could just make a nickname for it, e.g. MyAnalog mapped to MHR100:U (yes, include the cast). Then just use MyAnalog instead of MHR100 or MHR100:U (the proper iterpretation), that way your code, Data View, Trend View, HMI et. al. will always look at it as a 16 bit UNSIGNED (instead of signed).
Realize that "on the wire" Modbus protocol, it's just a hex value (no implied type, just 2 BYTEs 0x0000 thru 0xFFFF), so when a client reads Holding Register 40100, it will receive the value 0xFFFF over the wire.