(resistant) DIEMATIC boiler Modbus Slave

[p.piwowar]

I have a gas boiler with DIEMATIC regulator with Modbus protecol. I have found somwhere a specification so I connected to a PC with DAQFactory. DIEMATIC is Modbus master device so it requires slave. DaqFactory monitor displays all traffic, so I could see /003/ requests to the device #99 (and others 20-24, 71-73) but DaqFactory never respondes to these. - no Tx:

I have the right software version (Slave supported).

Device number is set for 99

Channels/Modbus Slave# are set in range 1..123 per request

Rx: /099/003/000/001/000/123/ ...

The only strange thing I see in the Modbus data traffic is that every sequence is followed by 3 (three) zero bytes, like

Rx: /099/003/000/001/000/123/CRC1/CRC2/ 000/000/000/

[AzeoTech]

The three /000's at the end probably won't matter since you have a proper frame. There are a couple possibilities as to why DAQFactory isn't replying:

1) did you set the slave ID to 99? Device.mydevice.ModbusAddress = 99 where mydevice is the name of the slave device you created.

2) did you specify Slave #'s in the channel's you'd like to make visible? Note that you never create channels with a device type = the slave device, you simply assign Slave #'s to existing tags on other devices

3) Since you are requesting 123 values, you MUST have a corresponding Slave # for all 123 values in DAQFactory, otherwise DAQFactory will ignore the request. I'd start by seeing if the DIEMATIC can just ask for one value. If you don't have 123 channels, create Test channels and use them as spacers.

[p.piwowar]

I have done these 1, 2 & 3 very carefully:

A. For 123 vales as device # 99

B. For 2 values as device #71

DaqFactory never responds...

Interestingly, ... if I do it with a cheap software modbus slave simulator my PC (same hardware environment) responds

Why DaqFactory does not?

NB. I am still very far from achieving my goal to use DaqFactory to monitor and set boiler parameters since I can not see Diematic's reaction even to this software simulator..... Maybe someone on this Forum have done it....

[AzeoTech]

Please post your .ctl document. There is often misunderstanding on how to setup Modbus Slave. I believe you have a simple setup issue.

[p.piwowar]

Here you are.

This is the simplest .ctl as a respnse to:

Rx: /071/003/000/017/000/002/CRC1/CRC2/000/000/000

Looking forward for your opinion why DaqFactory never responds to this

start.ctl

[AzeoTech]

A number of reasons. Well, actually probably only one, but there are a number of problems. The reason you never get a response is that your channels never get any data. Doing: ch16[0] = 0 does nothing because ch16 isn't an output channel. Its not really anything actually because Modbus Slave devices don't do anything. This is a concept that for some reason gets everyone so perhaps we need to reevaluate it:

You should never have channels with Device Type = your Modbus slave device. Your channels should all have Device Types equal to Modbus Master types, or other device types (like LabJack or otherwise) that actually return data. Then in the Mod Slave # column you put what Modbus tag # you'd like DAQFactory to respond to for that value when it receives a modbus request on the slave device. That way you can use the DAQFactory Slave protocol to return values from multiple devices.

So, change your channels to something that actually gets data into the channel. Use the Channel View -> table tab to see if there is data, or just create a variable value control to view. If you don't have any hardware now, use the "Test" device with I/O type "A to D" and Timing 1. Then assign Mod Slave #'s based on what your requesting. In this case, 17 and 18.

[p.piwowar]

Of course it is working now! Your explanation of slave concept in DaqFactor is cristal clear. Thank you a great deal.

Regards, Pawel

[p.piwowar]

Bigger problem now. After getting a new hint how to connect to Diematic, I have learnt I do not really need the slave functionality. Thanks for good lesson anyway....

This is a system with 2 masters, says the manufacturer. The Diematic master talkes to the bus and them makes 5 second silence for another master to pool data.

What is the way to implement this machanism in DaqFactory?

DaqFactory is checking if the bus is busy. After 0.5s of silence it has 4.5s to pool data as master.

[AzeoTech]

I assume DAQFactory and everything else is on the same 485 bus? Anyhow, you could test for 0.5 seconds of silence by setting the timeout on the port to 0.5 and doing this:

while(1)
   device.mydevice.purge()
   try
	  device.mydevice.read(1)
   catch()
	  break
   endcatch
   delay(0.05)
endwhile

The loop will break out when the read() times out indicating nothing was there to read for 0.5 seconds. Then you could do your Modbus calls. That'd get you started, but my guess is you'll get out of sync after a while. You really need to read until you get a value, then go into this loop to wait until its silent.

[p.piwowar]

Yes, it works now. Thanks!

I have to come back to strange Three Zeros. Remember? Every Modbus sequence on Diematic RS485 has extra 3 zeros.

If DaqFactory waits form the right moment to be master of the bus and sends a request (/010/003/000/001/000/123/CRC1/CRC2) it gets response ONLY, if there are 3 zeros at the end (/010/003/000/001/000/123/CRC1/CRC2/000/000/000). No 3 zeros - no response. No matter how many data it tries to read, when, etc. (*)

Question: Is there any way to (1) modify Modbus protocol slightly or should I (2) create my own protocol with built-in waiting for bus-free and functions 03 & 16 which I need to operate with Diematic with ?

Clearly (1) whould be much simpler.

* I use PLANET ICS100 RS-232/422/485 over Fast Ethernet Media Converter to communicate between Diematic and DaqFactory. Not much to change in RS485 port parameters there, so I do not think this is a serial port related issue.

[AzeoTech]

The 0's are coming from the hardware. DAQFactory doesn't create traffic on it own! I wouldn't worry about it though, since DF will ignore it.

As for your question, use the built in protocol and the direct Modbus functions from script, not channels, though you can stuff the results into channels. Should be quite easy to do.

[p.piwowar]

I must say it is not so easy for me. If I use function ReadHolding it never adds 3 zeros at the end. Without these 3 zeros Diematic never responds to any request. If I use low level Write instead with a proper Modbus command string with 3 zeros at the end, I can them read data with low level Read function and only them it works. I do not know how to make ReadHolding adding 3 zeros at the end ?

[AzeoTech]

I'm sorry, I thought the reply from your device had the 3 zeros. Here is one possible way that would work, but wouldn't be terribly efficient

1) add a new sequence called "SendThreeZeros" In it put:

delay(0.1)

device.mydevice.write(chra({0,0,0}))

2) in your sequence with the readholding, right before you call the readholding() function, do:

beginseq(SendThreeZeros)

So, the readholding() will run, but concurrently, the SendThreeZeros sequence is running. It will pause 100 milliseconds which should be long enough for the readholding() to send its packet, then three zeros get added to the end. Then the device will respond and the readholding() will get the result. This works because we are ignoring the lockport() that readholding() does internally. You probably can shorten the 100 milliseconds, but it needs to be a little. Also, make sure the priority of sendthreezeros is at or lower than the priority of your polling sequence

[p.piwowar]

Thanks! This is a nice trick. It works (with frequent errors) on a PC which is not so busy with other applications and DaqFactory with only few sequences running. In my real case (PC is really busy) this does not work so I have decided to write my own functions 03 and 16 with three-zeros handling built in.

[p.piwowar]

More... For a "busy" PC this does not work since Diematic expects three zeros to be send right (short period) after ReadHolding sequence. When the time period is too long between them, Diematic does not treat it as a valid sequence.

[AzeoTech]

Well, truthfully you really should be complaining to Diematic about their improper Modbus implementation. A customer of ours found an issue with a rather big PLC company's Modbus implementation by using DAQFactory, pointed out to them and they actually fixed it.

[p.piwowar]

Thanks for great support. I doubt Diematic would be happy at all that people are hacking into their Modbus interface. Their package for PC connectivity costs some 2.500 Euro + VAT .....

[AzeoTech]

That's probably why they added those three zeros, to throw off standard Modbus applications. If you want, we can create a modified version of our Modbus driver that adds three extra zeros, but we'd have to charge you a small engineering fee for the change. Email us directly if you'd be interested in this.