Mobus Writes Blocking PLC inputs

[Mark P.]

Mobus Writes Blocking PLC inputs

I know this sounds crazy but I have seen it now with two different programs on two
different FX processors.

What I am doing is writing from one FX master to one FX slave

The master has the program and it seems to send data well.   But depending on the number of writes or where
this is done in the program effects the rungs below it.

It works best when put at the very bottom of my program and worst at the top.

I am guessing that the Modbus writes are taking up too much scan time and blocking other functions in the FX Processor.

Unfortunately this is causing problems.

I have seen when the Modbus Read is at the top, the input light on the board come on, when monitoring It wont be seen
and the logic will not execute.   Block the Modbus Write rung and all works correctly.

How quickly can dCust functions containing something like WRITEMODBUS 13,2,1263,DM[11] be plused ?

How many Writes or Reads should be inside of one dCust ?

Should you use dCust or some other function holder ?

Should the Status bit be used in the rung of function for added reliability ?

Any other thoughts ?

[garysdickinson]

Mark,

You are not crazy.  What you are observing is exactly how the WRITEMODBUS and READMOBUS family of statements/functions operate.  These statements/functions are "blocking" operations.  By this I mean that the execution of the CF is blocked (suspended) until the Modbus communication is completed.

As an example if you have a very simple ladder logic program that calls a CF on each scan to communicate with a Modbus device and this communication takes 1 second, then this will result in your ladder logic program taking a bit more that 1 second per scan.  This, also, means that if an input changes state, the PLC program might take up to a second to respond to the input change.  If the input changes state once a second, then the PLC program will probably miss changes in the INPUT state.

OK. What can you do to to ensure that the PLC remains responsive to changing inputs?

• Reduce the rate of Modbus requests to the slave to the absolute minimum.
• Perform only a single Modbus operation per ladder logic scan.
• Ensure that between Modbus operations that the ladder logic is allowed at least one scan of the ladder logic.

One of your questions has to do with speed. "How quickly can dCust functions containing something like WRITEMODBUS 13,2,1263,DM[11] be pulsed ?". The short answer is 100 to 1000ms.  The answer is depends of things that you don't have too much control over:

• The amount of time it takes for the PLC to handle the WRITEMODUS function and generate a Modbus request data structure.
• The time it takes for the PLC to transmit this data structure. This happens in the low level PLC firmware and is a function of the communication link.  If you are using Modbus RTU (serial link) at 9600 BAUD it will take about 1ms for every 8-bit byte in the request packet to get pushed onto the serial link.
• The slave device has to process the Modbus request.  The slave device has to determine if the slave address matches the address of the slave device. If the address is correct then the slave device has to verify that the rest of the Modbus request is valid and then create a response data structure to be sent back to the master device.
• The response is then transmitted back to the master. Since the data is sent out a bit at a time, there is some minimum transit time to get the data down the wire. If you are operating at 9600 BAUD it will take about 1 ms for every 8 bit byte to be pushed down the wire.
• The master PLC has to wait until the entire response is received and then verify that the response is valid. Only then will your CF continue.
• If the slave device does not respond to the request, the master device will wait for a long period of time before returning control to your CF.  If you follow the Modbus standard, this may result in the PLC locking up (blocking) for 3 seconds before timing out.

You can measure the amount of time a READMODBUS/WRITEMODBUS function/statement takes to execute with the Status(21) function. Status(21) returns a 32-bit value of a 10 MHz counter that is buried in the PLC hardware.  I use code like this for test:

A = Status(21)                        ' time before the statement
WriteModbus ch,id,address,data
B = ABS((Status(21) - A)/1000)   ' elapsed time in ms in B

Another question that you had was, "Should you use dCust or some other function holder ?".  The answer for 99.9% of the cases is "yes".  

If you use "Cust" without the "d" then the custom function will be called on every pass through the ladder logic.  I have invoked CFs with "Cust" but these are very special situations and the CF that gets invoked is ptimized to solve a very special problem, very quickly.

I do not use the READMODBUS/WRITEMODBUS functions/statements for Modbus communications over serial links because of the blocking behavior (and a bunch of other limitations).  I use my own Modbus communication code written in TBASIC.  I use a single CF to format and send the Modbus request.  A TIMER is started by the first CF and after the TIMER runs out a 2nd CF is called to handle the response to the Modbus request.

I can issue a maximum of 20 Modbus commands a second without causing the PLC to miss INPUT events.  This is not possible with TRI's READMODBUS/WRITEMODBUS keywords.

I have have this code in over 40 PLC based systems spread all over the world.  Some of these systems were installed 5 years back.  I have had no problems with this approach.

Best regards,

Gary D*ckinson

[Mark P.]

Thank you !

Glad at least there's a logical answer.

To accomplish some of your suggestions

#2 Perform only a single Modbus operation per ladder logic scan.

#3 Ensure that between Modbus operations that the ladder logic is allowed at least one scan of the ladder logic.

Can I do something like :

inside of Dfuction block.  

x=x+1

if x=2 then
writemodbus ***
endif

If x=4 then
writemodbus ***
endif

etc...  etc..

If x >10 then
x=0
endif

I am assuming every scan it will increase x by 1.

Thank you again

Mark

[garysdickinson]

Mark,

Your approach would work.  However, this requires that the CF be called on every scan.

I'd suggest something a bit different, use the dCust function and trigger it off the 0.1sec clock.  Change your CF to make a decision on each count value.

I would suggest that you NOT use one of the a..z variables as a counter as you need to preserve this value between calls to this CF.  I prefer using the #Define mechanism to "create" a variable out of the DM32[] array.  You could define MBCounter as being DM32[100].  So your code would look like this:

If MBCounter = 0
    Writemodbus ...
elif MBCounter = 1
    Writemodbus ...
endif

MBCounter = (MBCounter + 1) mod 2   'Increment and keep bounded

Best regards,

Gary D*ickinson