Hello Guest it is March 18, 2024, 11:25:48 PM

Author Topic: Modbus and Timing  (Read 16266 times)

0 Members and 1 Guest are viewing this topic.

Modbus and Timing
« on: March 08, 2009, 01:15:59 PM »
I have a few questions about Mach3 and how it handles timing with respect to Modbus:

* I see several references to "Timeout 1234 ms" in the Modbus plug-in saying to set it to ~50ms.  What exactly does this setting do?

* If you have a given configuration within the Mobus Serial Plug-in set to Refresh it's output every 1000ms and you have a brain configured to update that configuration (much more often than ever 1 second), does the plug-in wait until the 1000ms refresh time is up to send the update or does it send the update (over modbus) at the moment it's commanded?

* I've seen references (in the modbus video?) about staggering the Modbus Refresh intervals.  Do these intervals all have their own timers?  It would seem that if I set one on 25ms and another on 100ms updates that on every 4th update to the 25ms timer that it would also occur at the same time as the 100ms timer.  Is this correct?

Thanks
Re: Modbus and Timing
« Reply #1 on: March 08, 2009, 05:16:16 PM »
Hi,

The Modbus timeout defines how long the Modbus Master (Mach3) will wait for a slave (ModIO) to answer a request.It is the time between sending a request and receiving a reply. Usually50ms- 200ms is a good timeout value.

The Master can only send one request at a time, so it can't send the next one until it receives the reply for the current one.

This timeout delay should not be confused with the refresh rate. The refresh rate (25Hz) is how often the Master sends the request. With, 25Hz, requests are send every 40mS. Most slaves will respond within a few millseconds of receiving the request. Depending on you baud rate, and length of request/reply you can calculate the round trip time per message transaction.

Note: Everytime Mach3 sends a Modbus request, the timeout timer is started, when the reply is received, the timer is stopped. If the timer reaches the timeout value, Mach3 stops waiting for thecurrent  reply and moves on to sending the next request.

The transactions are scheduled as per the modbus configuration definition. The user only has control over how often the requests are sent, and not when. Mach3 when and what gets sent.That said, Mach3 attempts to send the requests to the slavesat the defined rate. It should be noted that if you set up too many requests at too high a rate, Mach3 will not be able to keep up . In this case it just does the best it can.

When scheduling the requests think about the data you are reading/setting, and set refresh rate appropriately.

I hope this helps.


Cheers,


Peter.


----------------------------------------------------
Homann Designs
http://www.homanndesigns.com
email: peter at homanndesigns.com
Re: Modbus and Timing
« Reply #2 on: March 08, 2009, 09:17:58 PM »
Peter -

Thanks for the feedback.  That fills in my holes on what Mach3 is doing.

Thanks
Re: Modbus and Timing
« Reply #3 on: May 03, 2011, 10:19:32 AM »
hi peter
i have some questions about this thread.
i attach my configuration and now

1-about refresh rate,i used two configuration :
   Cfg0 and Cfg1
   i set refresh rate to 25 and According to You ,is about 40ms .
   mach3 send this algorithm : 01 02 00 00 00 10 79 c6  01 10 00 00 00 07 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 6f
   This algorithm is consecutive ? OR is similar this : 01 02 00 00 00 10 79 c6---(40ms delay for reply)--- 01 10 00 00 00 07 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 6f---(40ms delay for reply)---
   please explain .

2-you say about timeout :
Quote
It is the time between sending a request and receiving a reply
  then should Timeout < refresh rate
   Is this correct?
**Even a clock that does not work is right twice a day**
Re: Modbus and Timing
« Reply #4 on: May 03, 2011, 05:45:07 PM »
Hi,

The refresh rate is the rate at with the master Mach3 will send the requests, so if you have to cfgs set up, it will send the first request (cfg0). As soon as it receives the reply for cfg0, Mach3 will send the next request (cfg1) and wait for the reply.

Once the reply from the cfg1 is received it then waits until the next refresh cycle, say 40mS, before starting again.

In response to a request from a master, the slave should reply as quick as possible as any delay stops the master from issuing the next request.


The timeout value, of say 100ms, is the time that the master waits for a reply before abandoning the transaction and moves on to the next request (cfg).

I hope trhis helps,

Cheers,

Peter.
----------------------------------------------------
Homann Designs
http://www.homanndesigns.com
email: peter at homanndesigns.com

Offline simpson36

*
  •  1,369 1,369
    • View Profile
Re: Modbus and Timing
« Reply #5 on: May 16, 2012, 03:54:45 PM »
In response to a request from a master, the slave should reply as quick as possible as any delay stops the master from issuing the next request.

In interrupt driven slave would be a good way to do this, but so far I have not found any way to get a signal from Mach that a Modbus request has been sent. If such were available, it could be used to trigger an interrupt in the slave and add reliability to the comm.

Is there a 'proper' way to query Mach on this?  I have a number of workarounds, but it still seems to me that there should be some way to monitor MACHs modbus.

If Peter Homann does not know of one, then it surely does not exist.  

Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: Modbus and Timing
« Reply #6 on: May 18, 2012, 06:31:00 AM »
In interrupt driven slave would be a good way to do this, but so far I have not found any way to get a signal from Mach that a Modbus request has been sent. If such were available, it could be used to trigger an interrupt in the slave and add reliability to the comm.
But then it wouldn't be the MODBUS protocol it would be something else. Remember anyway that in MODBUS there can be ANY number of slaves - what would you do? have an interrupt line from the master to each and every slave? Also if your concern is that the master may "die" you'd have to monitor that with a third party (watchdog) anyway - something that's died can't tell you it's died.

I've looked at your other thread and if I've understood you correctly you're concerned what happens if the master "dies" for some reason then just have a brain (your watchdog) monitor a master/slave heartbeat reg/flag. That will tell you not so much whether the master has died or a slave has died - just that they're no longer playing catch for whatever reason.

Ian

Offline simpson36

*
  •  1,369 1,369
    • View Profile
Re: Modbus and Timing
« Reply #7 on: May 18, 2012, 07:46:41 AM »
But then it wouldn't be the MODBUS protocol it would be something else. Remember anyway that in MODBUS there can be ANY number of slaves - what would you do? have an interrupt line from the master to each and every slave?

I have made a decision about using MACH modbus, but I will address your comments, since you were good enough to respond.

The master could certainly generate an error indicating which slave did not respond, but as you point out, it is what it is, and it is modbus.  Unfortunately, saying anything that is percieved as negative against MACH around here is like you're insulting somebody's sister or something. I'm not trying to change modbus, and I am not bashing MACH.  Just trying to find out what is and is not available in MACHs implementation, which for example is not the entire Modbus set. That is important stuff to know if one is going to use MACH modbus, you would agree?  Documentation is next to none and what does exist is often contradictory (TCP variable access, for example). So again, it is what it is, and you need to try to get info from a support forum.

In any case, one 'interrupt' line would be enough. One E-stop line is enough, yes?

Mach has one E-stop monitor available to the brain, which I rout to a physical pin. From that pin, I can do with it as I need, with as many devices as I need.

Quote
Also if your concern is that the master may "die" you'd have to monitor that with a third party (watchdog) anyway - something that's died can't tell you it's died.

I don't think I said the master would die. I said if anything goes wrong with the com. as you noted later in your post. Something that dies can definitely tell you it has died. That is called failsafe and is the purpose of the default charge pump, is it not?

Quote
I've looked at your other thread and if I've understood you correctly you're concerned what happens if the master "dies" for some reason then just have a brain (your watchdog) monitor a master/slave heartbeat reg/flag. That will tell you not so much whether the master has died or a slave has died - just that they're no longer playing catch for whatever reason.
It is the entire com link, not just the master as noted earlier, but the master seems like the logical place to monitor from. Most of the time it is my software causing the problem, so what I want to know is if it has responded to the master. Hard to know that from the slave end.

As I said in those other posts, I am already timing the loops so I can see if the 'game of catch' ends, but only after a delay and it would be a guessing game in any case because the loop times are not consistent.  I am not sure why that is yet. Could be a bunch of different causes. I would need to wait until after the longest historical loop time passed before having confidence that there is an actual problem. The master would be the best place to snoop on things because it knows quickly if there has been no response.

"have a brain (your watchdog) monitor a master/slave heartbeat reg/flag."

Is there such a thing as a heartbeat flag? That would do the trick. This is what I asked at the beginning and have gotten no answer to. Where is the heartbeat flag. Modbus times out, but nobody knows if that event is available in MACH, so I have assumed it is not. 
Ian
[/quote]
Re: Modbus and Timing
« Reply #8 on: August 30, 2017, 03:11:13 AM »
Dear mr. Peter
i want to use to modBus for Mappping Home/ limitswitch  inputs.

is the the response speed of the all system is eunght for this function??

somebudy told me its not recomended to do homing/ limitswitch because of the little Delay !

please ley me know your idea!
regards'
Ghantos