| View previous topic :: View next topic |
| Author |
Message |
dmitrboristuk
Joined: 26 Sep 2020
Posts: 55
|
| Several questions about the modbus.c driver |
 Posted: Tue Nov 05, 2024 2:27 am |
 |
|
The question concerns time intervals when sending packets. We use MODBUS RTU. How correctly are time intervals formed in the delay functions
in modbus_phy_layer_rtu.c
| Code: |
calculated values for 9600 bod T=11*(1/9600)=1.146 ms/char 1.5T=1.718 ms 3.5T=4.01 ms
104 us/bit
#define MODBUS_SERIAL_BAUD 9600
#use delay(internal=16MHz)
#USE TIMER(TIMER=1,TICK=.1 ms,BITS=16, ISR) // real TICK is 0.128 ms
#define MODBUS_GETDATA_TIMEOUT ((unsigned int16)((TICKS_PER_SECOND * ((1.0/(float)MODBUS_SERIAL_BAUD) * 16.5)) + 1)) //1.5 characters
// 14 // 1.792 ms vs 1.718 ms ?
into
modbus_serial_send_start()
delay_us(3500000/MODBUS_SERIAL_BAUD); // 3.5 character delay 364 us vs 4.01 ms ??????????
into
modbus_serial_send_stop()
delay_us (3500000 / (MODBUS_SERIAL_BAUD / 10)); // 3.5 character delay 3.645 ms vs 4.01 ms ???
|
|
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9221
Location: Greensville,Ontario
|
|
| Posted: Tue Nov 05, 2024 6:05 am |
|
|
'timing' is all based upon the actual clock used so to get the best most accurate 'timings', you need to use quality crystal and 2 caps. For the ultimate timing, use an external canned oscillator that's temperature controlled !
Modern PICs have pretty good internal oscillators in them, that'll work well in the 'human' temperature range but check the specs if the product will be out in the cold or blazing sunshine.
As with all serial data transfers, you need to keep BOTH units within about a 3% (?) spec. If the xmt is 'low' by 2% and the rcvr is 'high' by 2%, then you're off by 4% and might have problems. Sadly this gets obvious when one is warm and the other cold.
The other issue might be distance. On the bench, timing won't change but get some real distance and/or low quality cables, and 'bad ' data will be the result.MODBUS is a short range system so I doubt wiring will be a problem unlike my 15 miles over Bell telephone wires was. |
|
|
dmitrboristuk
Joined: 26 Sep 2020
Posts: 55
|
|
| Posted: Tue Nov 05, 2024 11:24 am |
|
|
| temtronic I didn't ask exactly about that. I asked why the delay before sending a frame is so different from the delay at the end of the frame. They should be at least 3.5T. But at the beginning of sending a frame, the delay is almost 10 times less |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9221
Location: Greensville,Ontario
|
|
| Posted: Tue Nov 05, 2024 5:33 pm |
|
|
Well according to one source, the 'start' and 'end' time needs to be 3.5T or greater.
I'll assume the 'start' is 10x longer to allow for hardware to stabilize before the actual frame of data is sent.
If it's done as RS-485, the master will have to take control, setup the transceiver to 'transmit. without seeing schematics of the devices, I can't say exactly why but based on past serial communication networks I've had to deal with, you need a good 'quiet' start of transmission to get reliable data.
I used 2 start bits for one system....super reliable over 10 miles.
Those that work with MODBUS can better explain the 'whys' of the driver, but I suspect it's a 'generic - good for all' driver but NOT optimized. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19495
|
|
| Posted: Wed Nov 06, 2024 7:20 am |
|
|
The short delay, is the inter packet delay, not the inter frame delay. They
just have the inter packet delay, so you can then send another packet
straight away. A long inter frame delay tends to be more reliable. It's
commonly one of the recommended things to increase if you have
problems. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
