ModbusSlaveRequestReceived

199 views
Skip to first unread message

Matthew Brown

unread,
Feb 14, 2008, 7:24:03 PM2/14/08
to NModbus
I am now trying to use the ModbusSlaveRequestReceived event in
ModbusSlave, but have come across a problem, but it may just be a
misunderstanding on my part.

I need to get the start address of the data, the type of the data, and
the data itself. The event arguments object provides the FunctionCode,
the SlaveAddress, the TransactionID, and byte arrays with the entire
MessageFrame and another one with the ProtocolDataUnit part.

I can parse for the information I need, but I don't think such
duplication of effort was the intention when the event was added.

I have tried to cast to various other types and even use the ModBus
const values such as Modbus.ReadCoils to determine the type, but the
accessibility is too strict. The public const values in ModBus.cs are
hidden in an internal class, for example.

I also thought that I could just parse out the address and the number
of data points and then use the DataStore, which I do have access to.
However, the event is fired before the DataStore is updated, so the
correct data is not there, yet on writes.

It seems that the simple fix is to fire the event after the DataStore
is updated and to make ModbusMessageImpl and ModbusMessage public
classes. I haven't tried that yet; I wanted to see if I wasn't doing
anything wrong before editing the code and building the dll myself.

If my analysis seems correct, then I don't mind trying it and
submitting a patch or something.

Scott Alexander

unread,
Feb 18, 2008, 1:56:55 AM2/18/08
to NModbus...@googlegroups.com
In the interest of simplicity of use and maintainability I have chosen
not to expose the underlying message implementations.

What I would recommend is adding an additional event to the DataStore
class which provides the information you requested (start address of


the data, the type of the data, and

the data itself).

I will have some time next week and will look into adding this.

Let me know if you have any questions.
Scott

Matthew Brown

unread,
Feb 19, 2008, 12:27:18 AM2/19/08
to NModbus
Ok, I will wait. That's good anyway because I don't have VS.NET 2008,
only 2005 and the latest version doesn't build on 2005.

Matt


On Feb 17, 10:56 pm, "Scott Alexander" <sja...@gmail.com> wrote:
> In the interest of simplicity of use and maintainability I have chosen
> not to expose the underlying message implementations.
>
> What I would recommend is adding an additional event to the DataStore
> class which provides the information you requested (start address of
> the data, the type of the data, and
> the data itself).
>
> I will have some time next week and will look into adding this.
>
> Let me know if you have any questions.
> Scott
>

monica...@gmail.com

unread,
Feb 18, 2008, 2:24:42 AM2/18/08
to NModbus

That would be awesome, since I tried to build NModbus and realized
that it required VS.NET 2008, which I do not have.

I'll be looking forward to it.

Matt


On Feb 17, 10:56 pm, "Scott Alexander" <sja...@gmail.com> wrote:
> In the interest of simplicity of use and maintainability I have chosen
> not to expose the underlying message implementations.
>
> What I would recommend is adding an additional event to the DataStore
> class which provides the information you requested (start address of
> the data, the type of the data, and
> the data itself).
>
> I will have some time next week and will look into adding this.
>
> Let me know if you have any questions.
> Scott
>

fredrik...@isg.se

unread,
Mar 5, 2008, 10:44:55 AM3/5/08
to NModbus
I've been looking for a better event model quite long, and this is my
contribution:

The Idea is that after the DataStore has been updated, an event is
fired. You can probably include the updated data in the event, but i
haven't tried that yet.

Changes below:

in ModbusDataCollection.cs

........
namespace Modbus.Data
{

//new Delegate
public delegate void DataChangedDelegate(int address, int count);

/// <summary>
/// Modbus Data sections support addresses 1-n so we always pad the 0
element with a default value in a ModbusDataCollection.
/// </summary>
public class ModbusDataCollection<TData> : Collection<TData>
{
private bool _allowZeroElement = true;

//New event
public event DataChangedDelegate DataChanged;

//New helper method
internal void FireDataChanged(int address, int count)
{
if (this.DataChanged != null)
DataChanged(address, count);
}

/// <summary>
/// Initializes a new instance of the <see
cref="ModbusDataCollection&lt;TData&gt;"/> class.
/// </summary>
public ModbusDataCollection()
.......




in DataStore.cs
.......
internal static void WriteData<TData>(Collection<TData> items,
ModbusDataCollection<TData> destination, ushort startAddress)
{
int startIndex = startAddress + 1;

if (startIndex < 0 || startIndex >= destination.Count)
throw new ArgumentOutOfRangeException("Start address was out of
range. Must be non-negative and <= the size of the collection.");

if (destination.Count < startIndex + items.Count)
throw new ArgumentOutOfRangeException("Items collection is too
large to write at specified start index.");

CollectionUtility.Update(items, destination, startIndex);

//new call to event
helper.

destination.FireDataChanged(startIndex, items.Count);
}

............


This gives the possibility to do something like:

private void StartSlave(int port)
{
m_modBusSlaveListener = new
System.Net.Sockets.TcpListener(port);
m_modBusSlaveListener.Start();

m_modBusSlave = ModbusTcpSlave.CreateTcp(1,
m_modBusSlaveListener);
m_modBusSlave.DataStore =
Modbus.Data.DataStoreFactory.CreateDefaultDataStore();

m_modBusSlave.DataStore.HoldingRegisters.DataChanged +=
new Modbus.Data.DataChangedDelegate(HoldingRegisters_DataChanged);

m_modBusSlave.Listen();
}

void HoldingRegisters_DataChanged(int address, int count)
{
for (int i = address; i < address + count; i++)
{
DoSomeThing(i);
> > > submitting a patch or something.- Dölj citerad text -
>
> - Visa citerad text -

Matthew Brown

unread,
Mar 8, 2008, 1:14:14 AM3/8/08
to NModbus

I like that. It still needs VS.NET 2008, though. Any chance of getting
this code folded into NModbus soon? I'll likely have VS.NET 2008 in
the next week, but the sooner, the better.

Matt
Reply all
Reply to author
Forward
0 new messages