I am looking for some information on what determines\influences how an M series serial card queries Modbus slaves when operating in RS485 half duplex mode.
Does it just work through the devices and data sets sequentially with values being updated as it works through the devices?For example, if I have slaves that vary in their response time but none that exceed the timeout, I could easily take several seconds to work through all the data sets.With quick responses, I could work through quite a few devices in less than a second.
Does the control module scan rate influence the scan order or interval of the devices?
For example, if I reference a dataset register in a module that is executing at 500ms, will the serial card poll the slave every 500ms? If I also have a module, executing at 2S, referencing a different device, will the serial card schedule those queries every 2 seconds?
We are working to integrate some legacy networks and it would help to better understand how Modbus queries are scheduled.
Thanks!
In reply to alex:
Andre Dicaire
In reply to Andre Dicaire:
Found a document on line from Mynah that talks about optimizing Modbus TCP communications with the VIM. search for "VIM polling mynah"
This shows the VIM view of the configuration in diagnostics, with Devices configured under ports of the four emulated cards. Each Device has TCP level diagnostics indicating message retries and no responses. The document discusses optional configuration parameters to manage the communications and these are either set in the DeltaV configuration dialogs, or in some cases at the Dataset. You should be able to find this with a google search.
Dave Harmon
Automation Specialist
In reply to Dave Harmon:
Dave, the Enhanced Modbus Programmable Serial Card firmware was released in Jun 2021. NK-1800-0392. The KBA indicates the Time Delay setting in the Advanced Tab of the port.
From BOL:
Select a value to determine the time the Serial Card delays between requests for input data and/or requests to write output data to the Modbus Device.
This value is used to slow down Modbus master requests being transmitted to slave devices that require a time delay between requests.
The default Transmit Delay value is 0 because most Modbus devices do not require any delay.
Configuration dialogue:
I believe the VIM has same delay option. EIOC/PK modbus TCP does not have a delay option and polling cannot be adjusted.
This is not a typical device for it to reset values simply because a Modbus read was made. The DeltaV system cannot be configured to make a timed call for data directly from a Modbus Device to a Control Module reference.
Assuming there is no other device configuration option that would allow normal Dataset polling of data without resetting accumulated values, this appears to be not possible.
Thinking outside the box:
Since this is such a unique device in its behavior, it cannot be combined with other devices on a segment since it needs such a long delay between reads. You would only be able to combine other devices with the same interval requirements. Say we have 3 such devices that need to be "read" every 60 seconds. (I'm assuming only one Dataset per device).
Configure the serial card port to a 20 second Time delay. With three datasets, this should result in a read of each device every 60 seconds.
What if we only have 1 such device but need 60 second read frequency?
We could configure Port 2 of the Serial card as a slave and configure two Dummy Datasets there. That gets us back to 60 second cycle. We can configure up to 32 Datasets per port. If we have one real Dataset in this device to read, we can have 31 dummy datasets in Slave port (or maybe 29 for a nice even 30 total), which would give us 600 second polling cycle. the 29 datasets in the Slave will burn 580 seconds and the real dataset in the device takes us to 600.
The control module might execute every second, reading the stored Modbus IO value in the controller IO Map. When it changes, you can use the new value as needed.
What if the accumulation can be the same from scan to scan? Then we don't know exactly when it updated and reset. Maybe we need to track which data set is being read. Assuming Dataset 29 is always ahead of our Real Dataset, we configure the dataset 29 to a time value parameter. Then we read this same register by the Master port and read the value, which only updates every 600 seconds. Comparing this to the current time, we know how much time has elapsed since we scanned the data set, and when the value changes we know dataset 29 was just scanned. If we put the same time integer into Dataset 1, it should show a 40 second interval, and we know the real dataset was read half way through this interval. Anyway, the point is, we can predict when the real register should report a new value. If the accumulation is identical, we still know it happened. If it is different, we now within a second by detecting the change.
I have no idea if this would work for what you need. It's expensive to dedicate a serial card to one device. But this is the only way I can think of creating delayed polling that lets the device accumulate a significant value between polls.
I get what your proposing and agree that would be a way of allowing the device to accumulate and report. I didnt think of the accumulated time of multiple datasets to extend the polling delay, your brilliant! I need to get with the manufacturer. I will be using a serial card regardless for the modbus comms, and with its location ill have to just add one. The other option is to put a data aquasition module in between the device and the card and allow the module to regulate the polling to the device.(Device is a weather Station) They make a data logger for the device but it doesnt have an output. I guess thats the consequence of spending $2k on a device instead of $15k. Thanks Andre!