EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: CARS:Modbus - function 06 (write single register) issue
From: Nick Levchenko <[email protected]>
To: Mark Rivers <[email protected]>, "[email protected]" <[email protected]>
Date: Sun, 17 Jul 2016 13:42:49 +0000
Hi Mark,
First of all, thanks a lot for such extended and detailed response! Really appreciated.

As I mentioned before, I’m fairly new to EPICS but I think I got a fairly good understanding of your explanations.
It sounds like we found some common ground on “proposed syntax of specifying an offset of 0 and a length of 0 to mean "use asyn addr field as absolute 16-bit address"”. I agree that this syntax should be allowed for FC06 and (after looking at Modbus spec one more time) possibly for FC05 (what do you think?).
Now to initial read for the “bumpless reboot”… I have a bit of a concern with this. It is quite possible I’m seeing it wrong and you’ll correct me but nevertheless…
The way I’ve always used Modbus writes was asynchronous (button push, or some script). There might be hours, days or months between two writes to the same address. In the meantime there are potentially other clients (SCADA, HMI, some other expert software) that could write to the same address, or even the PLC itself can change values. Bottom line, I NEVER trust my client (SCADA) to have a valid value in its output tag. And it actually isn’t a problem at all because next time I change a value or push a button, a NEW value will be written. So I don’t care that I didn’t have up-to-date value beforehand. This obviously works fine as long as you use FC06 to write. If you use FC16, you REALLY need to have up-to-date values, otherwise you’re going to overwrite them with some old data that is not valid any longer (because some other client changed it since).
So, from this perspective, I don’t see how initial read will help? Yes, it will update my “ao” records with the values from the PLC but it will only do it once, on startup, right? Which to me means that as soon as few seconds later the values in “ao” records are potentially not valid any more. As I explained before this is not a problem if I use FC06 to WRITE, but if someone wants to use FC16 (not that I ever did) they will have to be very careful. Ultimately it seems that the only time you’d use FC16 is when you are sure there is NO ON ELSE changing values of those registers (including the PLC itself) as EPICS will be overwriting them every time.
I think there might be a better way of dealing with FC16.
I “wiresharked” your driver comms and found that the way you deal with “bo” records of type asynUInt32Digital is
1.	bo value changes in EPICS
2.	Driver READS the whole register (16 bits) from the PLC
3.	Driver replaces ONE bit that “bo” is linked to
4.	Driver WRITES the full register back to the PLC
And this might be a way to deal with FC16 (and FC15 for that matter), what do you think? If one value in the range changes, the driver should not rely on the values from the original “initial read” but instead should re-read the whole range, change one register to a new value and then write the whole range.

Anyway, to cut my blabbering short… I’d be very happy and thankful if you could implement “offset 0, length 0” for FC06.
As for all other discussions, we can take it up later as a separate topic. I’d love to catch up with you at the next EPICS meeting, as I had few other thoughts, too.

PS: As for reading strings functionality… sounds interesting, although I have to say it sounds more like the driver will be doing application’s job since strings have nothing to do with Modbus standard as such. You’ll probably be using FC03, pulling the data and building the strings yourself, right?

Regards,
Nick Levchenko
Control Systems Engineer
Integrated Control System Division
European Spallation Source ERIC

________________________________________
From: Mark Rivers [[email protected]]
Sent: Saturday, July 16, 2016 9:55 PM
To: Nick Levchenko; [email protected]
Subject: RE: CARS:Modbus - function 06 (write single register) issue

Hi Nick,

I apologize for my delay in answering your original message on this topic.  I understand the issue you are describing.  The reason for the restriction to a block of 123 words for each asyn modbus port driver is that even output records are allowed to do one initial read operation during device support  init_record.  This is so that the initial value of the output record can match the actual hardware value.  This is commonly called a "bumpless reboot", i.e. one can reboot the IOC and the output records match the hardware without modifying the hardware.  It is more efficient to do that initial read as a single block read of up to 123 registers than to read one register at a time.  That is the motivation for the current design.

That being said, I can understand that there are times that the 123 word restriction is a pain, so I am willing to figure out a solution.  Your proposed syntax of specifying an offset of 0 and a length of 0 to mean "use asyn addr field as absolute 16-bit address" sounds reasonable.  It would only be allowed for Modbus function code 6.  The question then arises about how to handle the initial read of the register during device support init_record.  This currently works as follows:

- If the pollMsec argument to drvAsynModbusConfigure is greater than 0 then the driver reads the entire block of registers once when the driver is created.

- When device support init_record calls the asynInt32->read() function the driver returns the value for that register from the block that was read in the previous step, and returns asynSuccess (assuming the initial read was successful).

This mechanism won't work for the proposed new driver behavior, because the driver would need to read the entire 16-bit address space, reading at most 123 registers at a time.  Many of those read operations are likely to fail, because the device will not implement the entire 16-bit address space.

An alternative does exist.  As described above, currently the asynInt32->read() function for MODBUS_DATA returns the register value from the last poll, including the initial poll.  It does not actually cause any I/O operation to occur.  The driver could be changed so that it does an actual Modbus read of that single register at the asyn addr under the following conditions:
  Function code == 6 AND
  Offset == 0 AND
  Length == 0 AND
  pollMsec > 0

By requiring pollMsec > 0 you can disable the initial read if desired.  You could even create 2 drvAsynModbus drivers that handle the entire 16-bit address space, one with pollMsec=0 (disallow the initial read) and one with pollMsec>0 (allow the initial read).  Then you can select the behavior you want on a per-record basis by choosing one driver or the other.

Reading the registers one at a time will not be as efficient as block reads, and so iocInit will take a little longer, but that should be fine.  It will be backwards compatible, because offset=0 and length=0 is not currently allowed.

Does this sound reasonable? If so I will begin to work on it.

On a somewhat related note, I have received a request to support reading strings from Modbus devices using the asynOctet interface.  Apparently some vendors store strings in a series of registers, 2 characters per register.  Of course there is no standard as to whether the first character will be in the high or low byte of the register, so I plan to implement both options.

Mark
_______________________________________
From: [email protected] [[email protected]] on behalf of Nick Levchenko [[email protected]]
Sent: Saturday, July 16, 2016 1:53 PM
To: [email protected]
Subject: CARS:Modbus - function 06 (write single register) issue

Hi everyone,


I have started to use Modbus (Asyn) driver (CARS:Modbus, Mark Rivers) and so far it looks great. I’ve gone through instructions under http://cars9.uchicago.edu/software/epics/modbusDoc.html and successfully got comms going.

Now that I’m starting to work further and actually create records I realised that I have a bit of a problem.

What I’m planning to use the driver for is only WRITING values from EPICS to PLC (Siemens S7-1500 in case you’re interested).
The values are only written when IOC changes them (for example user pushes the button on GUI), i.e. asynchronously. Therefore I want to use Modbus function 6 (write single register).
As per instructions I added the following to my command file to create modbus port:
drvModbusAsynConfigure("modbuswrite",        $(PLCNAME), 0, 6, 0, 123, 0, 0, "S7-1500")
where 6 is the modbus function, 0 is memory offset, and 123 is the number of words.

And this is when I realised I have an issue. In this set up I have to specify offset and length. These parameters make perfect sense for Modbus function 3 (where the driver will poll all these registers), but (as far as I know Modbus protocol) for Modbus function 6 they are actually not required at all. The modbus message looks like:
06 0001 0003 XXXX(CRC)
06 - function
0001 - modbus address to write to
0003 - value to write

Basically Modbus allows writing to ANY offset on the fly. So what I’m trying to understand is why does the driver force me to specify offset and length for FC03?

The reason it is a problem for me is that I will have a lot more than 123 words to write, therefore currently it looks like I will have to repeat drvModbusAsynConfigure quite a few times, have multiple Modbus port names and then write my records accordingly (recalculating offsets for every next port). This is going to be very painful.

I was trying to be sneaky and use:
drvModbusAsynConfigure("modbuswrite",        port1, 0, 6, 0, 0, 0, 0, "S7-1500")
hoping the driver has allowed for that, the response was
drvModbusAsyn::drvModbusConfigure, port modbuswrite memory length<=0

I also tried
drvModbusAsynConfigure("modbuswrite",        port1, 0, 6, 0, 124, 0, 0, "S7-1500")
the response was
drvModbusAsyn::drvModbusConfigure, port modbuswrite memory length=124 too large, max=123

So, clearly, there are some checks in driver code there.

So, what I’m trying to understand is why does the driver require offset and length for FC06? Is it really necessary, etc.?
I was almost thinking that something like:
drvModbusAsynConfigure("modbuswrite",        port1, 0, 6, 0, 0, 0, 0, "S7-1500")
can just create the connection and then driver would form Modbus message based on the offset from the record.

I sincerely hope I haven’t made this too confusing and it makes sense. I’d love to get community's thoughts on this.

Thank you in advance!


Regards,

Nick Levchenko
Control Systems Engineer
Integrated Control System Division

European Spallation Source ERIC
P.O Box 176, SE-221 00 Lund, Sweden
Visiting address: Tunavägen 24, Lund

Mobile: +46 721 79 23 64
Phone: +46 46 888 33 64
E-mail: [email protected]

www.esss.se


References:
CARS:Modbus - function 06 (write single register) issue Nick Levchenko
RE: CARS:Modbus - function 06 (write single register) issue Mark Rivers

Navigate by Date:
Prev: RE: CARS:Modbus - function 06 (write single register) issue Mark Rivers
Next: About Visual DCT hulusi
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: CARS:Modbus - function 06 (write single register) issue Mark Rivers
Next: Re: CARS:Modbus - function 06 (write single register) issue Pearson, Matthew R.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Jul 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·