How to handle command 0x10 by modbus-rtu slave device.

A

Thread Starter

AutomationEng

Dear All,

As I am developing a product which gets interfaced with HART field sensor using 4-20 mA signal. My product has one RS232 port so user can configure any HOLDING register using PC based modbus master software.

Now this Hodfing register map includes some normal device operation related configuration parameters (which user can just configure immediately) and some parameters needs to be configured by doing long-duration process. e.g. it maps HART device's configuration parameters. As it recives command-0x10 combined for normal parameters and HART device configuration parameters, How my product should handle this query??? Because for each HART configuration parameter, it has to generate HART write command (for this my product acts as HART Master) and send it to HART slave device, getting back response etc.

So for this particular scenario, I have some doubts:

[1] As my product receives 0x10 command, it can give back immediately exception response with ACKNOWLEDGE code. So master can know that slave wants to do long-duration process.

[2] If I am following point-[1] and if later on, HART write commands failed by some means, what to do with other normal device config parameters?? Should I write atleast those normal parameters???

[3] What sequence I have to consider, i.e. Should I write first normal parameters or after HART commands result???

[4] If my product is in process, and master sends any another write command, Should I give back SLAVE_BUSY exception response???

[5] If my product is in process, and master sends any READ command, should my product perform it or give back SLAVE_BUSY??

[6] Eventually, after finishing 0x10 command successfully or not, Should I allow any next write command from master??? If master sends same 0x10 command, should I give back cashed response or have to same process again???

I am really in confusion, please help me. how to solve this issue?

Thanks and regards,
ControlEng
 
We had similar issues in the past for a protocol gateway. We located the data communication library SuperCom (www.adontec.com) that also offer MODBUS ASCII, RTU for serial and TCP/IP communications. Slave emulation also included. It is not for free but worth the money. Easy to use modbus. The multi threaded protocol converter is working perfectly now.

Regards
mddp1
 
a) Interesting. Is this intended as a configuration tool, as opposed to an on-line, real-time HART PV & diagnostics value reporting tool?

I'm curious as to how a user would discover which HART parameter was mapped where in the field instrument, to enable a user to address it from Modbus.

Is it used with the instrument's table of configuration parameters, like: 3.4.3.1.5 where, for example:
3 = device setup
4 = detailed setup
3 = output condition
1 = analog output
5 = upper AO limit

Or does your device take care of all of this mapping in an PC application software?

I'll assume it is a configuration tool and base some of my reactions to having used PDM for HART configuration.

b) Since you're dealing with process instruments, failure has to fail safe.

>[2] If HART write commands failed by some means, what to do with other normal device config parameters?? Should I write at least those normal parameters??? <

It isn't clear what can happen here. If the write attempts to write to a read-only register, is that a critical safety failure? Probably not. But does that infer that the map could be incorrect, that the value written to HART register x.x.x.x.x was really intended for x.x.x.x.x+1 and that subsequent values are offset as well?

This situation screams 'feedback!' 'feedback!' to me. The user needs to know what worked and what didn't. You need to know, too, in case you goofed in coding and need to troubleshoot and fix it.

The Modbus side of your gateway is a slave. The failure(s) to write need to be mapped to gateway registers, so that the Master could, if desired, poll the gateway registers to determine what worked, what didn't?

c) [3] What sequence I have to consider, i.e. Should I write first normal parameters or after HART commands result???

Without examples, I have no idea what this means.

d) >[4] If my product is in process, and master sends any another write command, Should I give back SLAVE_BUSY exception response??? <

Why would this happen if this is a configuration tool, unless the user is impatient and figures his first command to write made no attempt to execute? Use the hourglass or a progress bar.
If you're doing PC software interpret slave_busy for the user.

e) [5] If my product is in process, and master sends any READ command, should my product perform it or give back SLAVE_BUSY??

Is the read for reporting PV's? Or for feedback on whether the writes worked properly? You haven't told us what this device is intended to do. Without knowing what it is intended to do, how can an answer be formulated?

f) 6] Eventually, after finishing 0x10 command successfully or not, Should I allow any next write command from master???

I would assume that writes aren't precocious and arbitrary, but that they're intended to change a parameter in the instrument.

Why would you not allow a 2nd write? The purpose is configuration changes, right? Why would the software author presume to be a controlfreak, (pun intended on this forum) and not allow a subsequent update? Of course, the product's scope has not been revealed to us.

Personal experience: I frequently download a config from PDM, and while hitting the download key, notice something else that needs to be changed. So I change it, wait for the update to finish and immediately do another download. Why would you not allow me to do so?

g) > If master sends same 0x10 command, should I give back cashed (sic) response or have to same process again??? <

If the 2nd write is identical to the first because the first one failed, then the error reporting/assessment needs work. Full blown explanations are needed.

An alternative is that maybe the user doesn't trust the system. I don't trust PDM.

I download, upload to check results, and frequently have to correct a parameter that I did NOT change, typically the engineering units, that had been arbitrarily changed back to metric by PDM. So I end up downloading twice, once for changes I want, once for changes to correct what PDM broke.

My advice: Don't shortcut. If the user asks for a read, give him a read. If response time is critical give the user a choice, cache read (quick) or real read (slow)?
 
Top