| View previous topic :: View next topic |
| Author |
Message |
notbad
Joined: 10 Jan 2013
Posts: 68
|
| modbus slaves respond to HyperTerminal but not to HMI |
 Posted: Tue Jan 14, 2014 12:44 pm |
 |
|
Hello.
I have two modbus slaves on the bus with an HMI as master.
Slave code is based on CCS example.
They respond to commands I type in HyperTerminal but not to the commands HMI sends. (which are exactly the same)
What do you think is the problem?
| Code: | #include <16F873A.h> //CCS v4.130
#FUSES NOWDT, HS, PUT, NOBROWNOUT, NOLVP
#use delay(clock=3680000) // 4000000
#define MODBUS_TYPE MODBUS_TYPE_SLAVE
#define MODBUS_SERIAL_TYPE MODBUS_ASCII
#define MODBUS_SERIAL_RX_BUFFER_SIZE 64
#define MODBUS_SERIAL_BAUD 115200 // 9600
#define MODBUS_ADDRESS 0x01
#define MODBUS_SERIAL_INT_SOURCE MODBUS_INT_RDA // Uses hardware UART
#define MODBUS_SERIAL_ENABLE_PIN PIN_C5 // Controls DE pin for RS485
#define MODBUS_SERIAL_RX_ENABLE PIN_C5 // Controls RE pin for RS485 (Tied together)
#include <modbus.c>
int16 inputs=0;
int16 outputs=0;
void main()
{
setup_adc_ports(NO_ANALOGS);
port_b_pullups(TRUE);
modbus_init();
while(TRUE)
{
while(!modbus_kbhit());
//check address against our address, 0 is broadcast
if(modbus_rx.address == modbus_address)
{
switch(modbus_rx.func)
{
//*********************************************************
case FUNC_READ_HOLDING_REGISTERS: //read register Dx :0103 10 00 00 01
if(modbus_rx.data[0]!=0x10 || modbus_rx.data[2] || modbus_rx.data[1] > 1 || modbus_rx.data[3] > 1)
modbus_exception_rsp(modbus_address, modbus_rx.func,ILLEGAL_DATA_ADDRESS);
else
{
switch (modbus_rx.data[1])
{
case 0:
modbus_read_holding_registers_rsp(modbus_address, 2, &inputs);
break;
case 1:
modbus_read_holding_registers_rsp(modbus_address, 2, &outputs);
break;
}
}
break;
//*********************************************************
case FUNC_WRITE_SINGLE_REGISTER: //write register Dx :0106 10 01
if(modbus_rx.data[0]!=0x10 || modbus_rx.data[1]!=1 )
modbus_exception_rsp(modbus_address, modbus_rx.func,ILLEGAL_DATA_ADDRESS);
else
{
outputs = make16(modbus_rx.data[2],modbus_rx.data[3]);
modbus_write_single_register_rsp(modbus_address, make16(modbus_rx.data[0], modbus_rx.data[1]), make16(modbus_rx.data[2],modbus_rx.data[3]));
}
break;
//*********************************************************
default: //We don't support the function, so return exception
modbus_exception_rsp(modbus_address, modbus_rx.func, ILLEGAL_FUNCTION);
break;
}
}
}
}
|
|
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9221
Location: Greensville,Ontario
|
|
| Posted: Tue Jan 14, 2014 1:36 pm |
|
|
HMI is busted !
Since you've proven that both the PIC slaves WORK 100% with a PC running Hyperterminal the only logical answer would be that the HMI( or wiring) is at fault.
hth
jay |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Tue Jan 14, 2014 1:54 pm |
|
|
| temtronic wrote: | HMI is busted !
Since you've proven that both the PIC slaves WORK 100% with a PC running Hyperterminal the only logical answer would be that the HMI( or wiring) is at fault.
hth
jay |
RS485 bus termination is problematic. Check the bus is connected and terminated correctly. Just because it works with a PC does not mean it will work with another device.
Another issue is mod bus timing. You need a DSO or other test instrument to look at the timing. For example, one of the controllers I work with expects a slave to respond within 50ms of the last bit of the command being serialized out of the RS485 bus. If the slave does not respond within 50ms then the response is ignored.
A slave device can also respond too quickly, before the master has switched its RS485 transceiver to receive mode. A mod bus device should wait 3.5 character times to ensure the bus is idle before transmitting. If the slave responds before this time then the master may not see a valid response packet from the slave.
From these two points you can see that just because a mod bus slave appears to work when tested with hyperterm, testing modbus with hyperterm is virtually useless.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
notbad
Joined: 10 Jan 2013
Posts: 68
|
|
| Posted: Tue Jan 14, 2014 2:41 pm |
|
|
Thanks for answering.
| temtronic wrote: | HMI is busted !
|
Unfortunately no! I can see It's sending commands. (using a 485 sniffer)
| asmallri wrote: |
RS485 bus termination is problematic. Check the bus is connected and terminated correctly. Just because it works with a PC does not mean it will work with another device.
Another issue is mod bus timing. You need a DSO or other test instrument to look at the timing. For example, one of the controllers I work with expects a slave to respond within 50ms of the last bit of the command being serialized out of the RS485 bus. If the slave does not respond within 50ms then the response is ignored.
A slave device can also respond too quickly, before the master has switched its RS485 transceiver to receive mode. A mod bus device should wait 3.5 character times to ensure the bus is idle before transmitting. If the slave responds before this time then the master may not see a valid response packet from the slave.
From these two points you can see that just because a mod bus slave appears to work when tested with hyperterm, testing modbus with hyperterm is virtually useless.
|
Termination is present. I added a 20ms delay before response; didn't help. HMI's response timeout is set on 500ms.
I don't have a DSO but timings seem OK.
I can't think of anything else. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19499
|
|
| Posted: Wed Jan 15, 2014 1:29 am |
|
|
'Termination is present'. Is it biasing the bus to 'off' when the bus is idle?.
On RS485, there are two parts to the termination. The 'matching', to reduce signal reflection at the ends of the lines, and the biasing, so that an undriven bus is seen as idle.
Some makes of bus transceiver, are built to always see an undriven bus as idle (Texas do some), also some electronic terminators automatically provide biasing as well (Texas and Maxim both do terminators that give this). However if (for instance), the PC interface board provided biasing, while the other boards don't, then though the data packets would be the same, the 'gaps between' wouldn't.
Other thing, be very careful on line feed and carriage return.
Best Wishes |
|
|
notbad
Joined: 10 Jan 2013
Posts: 68
|
|
| Posted: Wed Jan 15, 2014 6:16 am |
|
|
I changed the baudrate to 57600 and it’s responding now.
As my crystal is 3.68 MHz, Is it possible that 115200 is too much to handle when it’s being sent continuously?
Or maybe inaccuracy and tolerance is the problem?
What kind of test do you suggest to find the bug? (Of course without a fancy instrument!) |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9221
Location: Greensville,Ontario
|
|
| Posted: Wed Jan 15, 2014 6:37 am |
|
|
That xtal and baud rates are very good. Only -.18% off. Anything less than 2% should be great.Since both baudrates have the same error rate (-.18%), I suspect 'wiring' issues.You don't say how long the cable is, what type of wiring, etc.For high baudrates you need good connections,preferably with shielded low capacitance cables and either soldered connections or screwtype terminals.
Wither serial data you can go fast but not far OR slow and forever.
As you're using RS-485,consult the datasheet of the device you're using to see what they recommend for wiring.
hth
jay |
|
|
notbad
Joined: 10 Jan 2013
Posts: 68
|
|
| Posted: Wed Jan 15, 2014 7:07 am |
|
|
| temtronic wrote: |
You don't say how long the cable is, what type of wiring, etc.
|
Cable is 50 cm long for now. It's a pair of telephone wires. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9221
Location: Greensville,Ontario
|
|
| Posted: Wed Jan 15, 2014 8:07 am |
|
|
| hmm... about 2 feet over here in Canada...it 'shouldn't' be a problem,however, 'twisted pair' would be better... |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19499
|
|
| Posted: Wed Jan 15, 2014 9:23 am |
|
|
3.68MHz, is only just under 1MIPS.
115200bps, potentially gives a character about every 80 machine instructions. I'd suspect it just can't keep up sometimes with what has to be done.....
Best Wishes |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9221
Location: Greensville,Ontario
|
|
| Posted: Wed Jan 15, 2014 10:20 am |
|
|
| interesting.... there are comments in the original code that indicate it was developed using a 4MHz xtal and 9600 baud |
|
|
notbad
Joined: 10 Jan 2013
Posts: 68
|
|
| Posted: Fri Jan 17, 2014 3:44 pm |
|
|
Sorry for being late. I was waiting for the new parts.
I replaced the crystal with a 11.059 MHz and now it's working on 115200.
Thanks everyone |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
