Emerson Exchange 365

• Not Answered

Serial Card Series 1 Refresh Rate

I have a M-Series Serial Card (Series 1) where I have configured Port 1 to be RS485 at 9600 Baud rate and my data is only refreshing every 4 to 6 seconds.  I have set the module to execute every 1 second and sample data every 2 seconds.

Does the serial card only sample data when there is a big enough difference in the data?  Is there a way to get it to sample faster?

I have confirmed through a separate Modbus tool that the data from the device is refreshing at least 1 time a second.

Any help would be greatly appreciated.

Thanks!

• serial card data refresh rate

ksupak

• 11 Oct 2017 8:06 PM
• Cancel

8 Replies

• Matt Forbis

  

  • 11 Oct 2017 8:47 PM

  How many registers are you reading on that serial link? You could be saturating the link if you are trying to read a lot of data. You could take the 9600 baud and back calculate based on how many registers and also include the overhead of the protocol and find the maximum number of registers that could be read and still be updated at a 1 second interval. Most registers are 2 bytes and there is some overhead associated with it as well, so in that case, you probably are looking at a max of about 400 registers if you still want a 1 second update rate. If you have a fully loaded serial port (1600 registers), you could be in that 4-6 second range.

  • Cancel
• ksupak

  

  • 11 Oct 2017 8:51 PM

  In reply to Matt Forbis:

  Matt I appreciate the quick response. We are only polling about 40 input registers and our CPU free time on the controller is near 100%.

  • Cancel
• Matt Forbis

  

  • 11 Oct 2017 9:05 PM

  In reply to ksupak:

  With only 40 registers, I don't think it's an update rate. Serial cards should poll the data as fast as it can and with a small amount of data, 1 second should be no problem. That would lead me to think something else might be going on. Some things to consider: Do you use landing modules as an intermediary between your serial registers and the control modules? These used to be common place to both split apart registers into bits as well as handle odd scaling situations. If so, is the scan rate on that module slower perhaps? Another thing, is there anything in diagnostics that might indicate an error on the link or a timeout happening? In the past, sometimes requesting a non-existant register could potentially cause weird behavior. Finally, there is a transmit delay that can be configured on the serial port. Usually this is left at 0, but if it's not 0, it could explain slowing down of the serial card.

  • Cancel
• Mike Link

  

  • 11 Oct 2017 9:24 PM

  From DeltaV diagnostics right click on the serial port and check out the Port Statistics, you'll probably want to reset them and then watch for a few minutes. You should have no Errors, Retries, or Timeouts. I would also be curious to know the scan times. Also how many IO cards are on the controller, are there a lot of other bus cards on this controller?

  • Cancel
• ksupak

  

  • 11 Oct 2017 9:36 PM

  In reply to Mike Link:

  Hi Mike thanks for your quick response - I'll check this tonight. In the mean time... some of my analog inputs have blue question marks on them (and most don't) but the data is refreshing on all registers in the online view for the module. Could that indicate timeouts or another problem?

  • Cancel
• Matt Forbis

  

  • 12 Oct 2017 1:02 PM

  In reply to ksupak:

  Something in your post triggered another thought. Are you looking at your data update rate in something like watchit or operate, or control studio online? Control studio online has about a 5 second update rate on the display even though the module is executing faster than that. If you look at the data using watchit that will update at the same rate as the module.

  • Cancel
• Andre Dicaire

  

  • 12 Oct 2017 4:22 PM

  In reply to Matt Forbis:

  Lot of things being talked about here.
  
  As Matt points out the serial card polls data as fast as it can based on the number of Data Sets and their size. If you have devices that are not responding, then there will be time outs, which trigger retries and this can hold up the response from the working device. So verifying the diagnostics and port statistics is a solid first step. You can also view the data from the data sets in directly in Diagnostics to see how well things are going. If your data set size or starting register is not valid, the entire dataset would be marked BAD. Assuming all data sets are good, the poll time on the Modbus size will be proportional to the data size and baudrate. So 100 Integers will be 200 bytes or 1600bits. The data will come in as fast as the card can poll. There will be the overhead for the calls and delay time between packets etc. Baud rate is the big determining factor.
  
  Next the Serial Card sits on the LocalBus IO carriers. The local bus is scanned asynchronously, and uses exception flags to maximize throughput. In v12, I checked and the minimum scan time of the IO bus (i.e. one IO card) is 20 ms. The Controller selects each card in turn and lets the card send its data. Some cards, like a 8 channel DI have very little data, while some (Serial cards, BUS cards) can host a lot of data. The card is the master of this connection, but the controller manages the time each card can own the bus. The limit is about 1 ms. If you have a mix of IO with the maximum of 64 cards, the total IO scan could be upwards of 60 to 80 ms, but most controllers see an update rate between 30 to 50 ms. If a card has more data than it can send in a scan, the rest is sent in the next scan. This typically only impacts Bus or Serial cards with a large amount of data. ( 40 integers is not a lot of Data).
  
  The IO is updated into the controller's IO Map, and control modules read and write to this memory based on the module scan rates, no faster than 100 ms. Cards send data by exception so it is rare to see cards take multiple scans for data. Outputs are written from a module and therefore do not change until the module runs. This sets the Output Value as changed and needing update, which is handled by the IO update task. Outputs can be seen to update at the terminals within a scan of the IO bus.
  
  So, as Matt suggested, start by diagnosing the behavior of the Card and its ability to read and write to all datasets and devices without error. Retries will have a big impact on data latency at the card level. All your data sets may be "GOOD", but if there is a second device that is no longer present, that will delay all data updates.
  
  For 40 integers from one device, there is no reason, even on a controller with 64 cards, that the IO updates would have a lag exceeding 80 ms.
  
  Matt Suggested Watchit.exe. A small footprint data viewer that connects directly to the DeltaV communication layer at the workstation, and allows you to view (and trend) any value. This bypasses update rate settings in Operate or Control Studio and is another way to determine if the issue is between the control module and the workstation, or between the comm layer and the application. With DeltaV we dynamically adjust the update rate of values based on the destination application. When Control Studio opens on line, it uses a slower update rate. The default is 15 seconds, and it can be set to 3 seconds. Watchit can be set to request data as fast as 100 ms. However, data will only update when the module executes, so updates will come as fast as they can. The default for Operate is 1 second and Watchit also defaults to 1 second. If the module is a 1 second execution scan rate, 1 second is perfect.
  
  Hope this is useful.

  Andre Dicaire

  • Cancel
• ksupak

  

  • 13 Oct 2017 11:28 AM

  In reply to Andre Dicaire:

  I had other serial devices that were still commissioned in the port but they have long since then been disconnected - polling them was causing a lag. I removed them and then set the transmit delay to 0 and this seemed to fix my problem. Thanks for the information and helpful discussion.

  • Cancel