| View previous topic :: View next topic |
| Author |
Message |
Dutch Guy
Joined: 20 Mar 2018
Posts: 21
Location: University of Antwerp
|
| Weird consistent values in modbus_rx struct |
 Posted: Tue Mar 20, 2018 4:56 am |
 |
|
First of all after reading a lot of responses trying to find a problem-mate i must definitely express my awe of the countless answers that the administrators provide. My regards to them.... I wish I had all those answers.
My first post ever... so give me some protocol credit please.
Now as I am struggling trough to get a PIC18F8722 acting as a modbus controllable PLC with virtual coils. So you can use this to start a program without using a hardwired relay coil as in industrial PLC. I started this to get a keep alive monitor command going in the bus. Now my cheap PLC can only uses a relay to pulse and THAT I don't want. So I defined virtual coils as possible detect and reset inputs.... (can`t write to inputs in modbus)
If I can pull this off I'm permitted to release the code to the Code library.(hoping people tweak my ignorance out:grin: ) Also I`m expanding the addressing width.
My setup is a Easypic Pro V7 board with a click RS485 2
Pimping the ex_mobus_RTU_slave example.
Now my EasyPIC Problem is the following:
When I send at 9600,8,E,1 verified with MOXA RS232/485 to Realterm on PC:
D5 02 00 00 10 CRC the modbus_rx struct says addr : 15 len :05 func: 3F
45 02 00 00 10 CRC says : addr : CB len :05 func: 3F
00 02 00 00 10 CRC says : addr : FB len :04 func: FF
1C 02 00 00 10 CRC says : addr : 9C len :05 func: FE
I can`t seem to find a relation. As i`m sure it will be a generic problem for you guys. Thanks in advance.
setup :
| Code: |
#define USE_WITH_PC 1
#define MODBUS_TYPE MODBUS_TYPE_SLAVE
#define MODBUS_SERIAL_TYPE MODBUS_RTU //use MODBUS_ASCII for ASCII mode
#define MODBUS_SERIAL_RX_BUFFER_SIZE 64
#define MODBUS_SERIAL_BAUD 9600
#define MODBUS_PARITY "EVEN"
#define MODBUS_ADDRESS 0x1C
#define MODBUS_GETDATA_TIMEOUT 10
#define MODBUS_SERIAL_INT_SOURCE MODBUS_INT_RDA2
#define MODBUS_SERIAL_ENABLE_PIN PIN_E2 // Controls DE pin for RS485
#define MODBUS_SERIAL_RX_ENABLE PIN_G0 // Controls RE pin for RS485
////
#define LCD_DATA_PORT getenv("SFR:PORTB") ////
#define LCD_EXTENDED_NEWLINE 1
#if defined(__PCD__)
#include <24FJ128GA006.h>
#fuses PR,HS,NOWDT
#use delay()
#elif defined(__PCH__)
#include <18f8722.h>
#use delay(clock=10M)
#fuses HS, NOWDT
#else
#include <16F887.h>
#fuses HS,NOWDT
#use delay(clock=10M)
#endif
#include <modbus_plc_FATI.h>
#include <modbus.c>
#include <lcd.c>
int8 coils[4] = {136,0,0,0}; // coils
int8 inputs[4] = {0,0,0,0};
int16 hold_regs[16] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0} ;
int16 input_regs[16] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
int16 event_count = 0;
int8 test_var = 0 ;
int1 testbool = 0;
int8 swap_bits(int8 c)
{
return ((c&1)?128:0)|((c&2)?64:0)|((c&4)?32:0)|((c&8)?16:0)|((c&16)?8:0)
|((c&32)?4:0)|((c&64)?2:0)|((c&128)?1:0);
}
void main()
{
setup_adc_ports(NO_ANALOGS);
SET_TRIS_H( 0xFF );
SET_TRIS_J( 0x00 );
OUTPUT_J(0x00);
output_low(pin_E2); // for click2 board /DE low
lcd_init();
modbus_init();
while(TRUE)
{
main_protocol();
modbus_plc_FATI();
lcd_putc(0x41); //test
}
} |
_________________
I just can`t get it all in my head.... But wait, there is a new hole opening up.... |
|
 |
Dutch Guy
Joined: 20 Mar 2018
Posts: 21
Location: University of Antwerp
|
|
| Posted: Tue Mar 20, 2018 6:27 am |
|
|
I also must add that datafields in modbus_rx struct hold 0-2 static on:
0xFF 0xFF 0xDF
fields 3-4 change randomly(CRC field?)
_________________
I just can`t get it all in my head.... But wait, there is a new hole opening up.... |
|
|
Dutch Guy
Joined: 20 Mar 2018
Posts: 21
Location: University of Antwerp
|
|
| Posted: Wed Mar 21, 2018 10:44 am |
|
|
I've been backtracing the first event when RX active and it seems to be in the modbus_phy_layer :
| Code: |
c=fgetc(MODBUS_SERIAL);
if (!modbus_serial_new)
{
if(modbus_serial_state == MODBUS_GETADDY)
{
modbus_serial_crc.d = 0xFFFF;
modbus_rx.address = c;
modbus_serial_state++;
modbus_rx.len = 0;
modbus_rx.error=0;
}
|
As I'm thinking it must already be wrong when c gets filled with address. I can't stop thinking the problem must be at *USE RS232 level, Inverted and shifted. I checked for stretched by looking for extra 0's or 1's but still I can't find no relation.
Also I don't know how to put c in my watch window in MPLAB since it's in another c file... And I can't add it to my project files and compile correctly.
Need to learn that in second instance.
A second consideration. When I put the generic PLC's on the line(12pcs) they react... Maybe my RS485 click needs the termination resistors.
Could their absence get the signal out of sync??
I'll keep trying until someone has an idea.
_________________
I just can`t get it all in my head.... But wait, there is a new hole opening up.... |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Mar 21, 2018 11:13 am |
|
|
| Quote: | | I can't stop thinking the problem must be at *USE RS232 level |
Some previous threads on this forum have said they fixed the problem
by specifying 2 stop bits in the #use rs232() statement for the master. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19539
|
|
| Posted: Wed Mar 21, 2018 11:21 am |
|
|
There are two termination functions. The termination itself (signal matching to reduce reflections), and bus biasing. This is what ensures an RS485 bus idles to the inactive state when not driven. If a bus does not have this, devices will persistently receive garbage, unless you have special RS485 transceivers that are designed to treat an idle bus as inactive. These are transceivers like the ISL32495E. Unless you have these, the bus _must_ have biasing. Termination should also exist.
An unbiased unterminated bus is basically useless.... |
|
|
Dutch Guy
Joined: 20 Mar 2018
Posts: 21
Location: University of Antwerp
|
|
| Posted: Thu Mar 22, 2018 8:58 am |
|
|
So i did the following without success:
I added the 3 terminator resistor and see no change in the scope signals which are pretty clean on TTL level. I scoped a 04 02 00 00 00 10 CRC command on RG2 :
https://www.dropbox.com/sh/q1ukq5nu8vg5r76/AAAcJJlT5_mVEb9UEhDPClc9a?dl=0
Exploring the double stopbit road, having read :
http://www.microchip.com/forums/m805962.aspx
and the topic :stopbit 2 problem from Mrinoy Dey
As far as I understood my conclusion is that the PIC can be ready for a new high detect on RG2 before the last bit goes down again. Since the pin detects on HIGH and not on LOW_to_HIGH the second read can be initiated by the last bit of the previous byte. By adding the 2nd stopbit characters are coming in with a bit more bus_idle_time in between delivered by the extra 0(low). Am I correct?
I set up my Weintek industrial HMI to send at 9600,8,E,2 leaving the pic at 8,E,1 and checked modbus.rx
The only things that changes is that len is mostly detected at 5 or 6 and datafields 4-5 are affected.
With one stop bit the adresses yield mostly the same values but len is 4 or 5 and datafields 3-4 change.
The following is strange and almost inverted:
address, function(02),data(2 offset + 2 data bytes), becomes address,function, length (with 2 stop bit).
With 1 stopbit the adress conversion stays the same with an anomaly found at adress 04 where it becomes 1F
01 02 00 00 00 10 CRC becomes 7F 3F 05
02 02 00 00 00 10 CRC becomes 3F 3F 05
03 02 00 00 00 10 CRC becomes FE 3F 05
04 02 00 00 00 10 CRC becomes 9F FF 05
05 02 00 00 00 10 CRC becomes FD 3F 05
Low numbers yield high numbers but not quite inverted
FE 02 00 00 00 10 CRC becomes 00 3F 05
FD 02 00 00 00 10 CRC becomes 01 3F 05
FC 02 00 00 00 10 CRC becomes 20 3F 05
FB 02 00 00 00 10 CRC becomes 02 FF 05
FA 02 00 00 00 10 CRC becomes 41 3F 05
F9 02 00 00 00 10 CRC becomes 83 3F 05
F8 02 00 00 00 10 CRC becomes 80 FC 05
Highest numbers yield low numbers but not quite inverted
Still the represented values are consitently scrambled. I cannot believe that my 20 cm twisted wire bus would interfere by impedance mismatch.
_________________
I just can`t get it all in my head.... But wait, there is a new hole opening up.... |
|
|
Jerson
Joined: 31 Jul 2009
Posts: 125
Location: Bombay, India
|
|
|
Dutch Guy
Joined: 20 Mar 2018
Posts: 21
Location: University of Antwerp
|
|
| Posted: Thu Mar 22, 2018 10:22 am |
|
|
| Just for morbid curiosity i put the baudrate up to 19200 just to see if any fixed timelags or delays would give another outcome and nope.... same numbers for same addresses. So frustrating. |
|
|
Dutch Guy
Joined: 20 Mar 2018
Posts: 21
Location: University of Antwerp
|
|
| Posted: Thu Mar 22, 2018 10:26 am |
|
|
Jerson. The generic example is indeed at 16Mhz and yes i assumed i just could alter it. My crystal is 10 MHz as came with the Easy PIC PRO evaluation board.
The 18fxxLxx type have the 16 MHz. I'm thinking about your reply.
_________________
I just can`t get it all in my head.... But wait, there is a new hole opening up.... |
|
|
Dutch Guy
Joined: 20 Mar 2018
Posts: 21
Location: University of Antwerp
|
|
| Posted: Thu Mar 22, 2018 10:29 am |
|
|
It is the J and K type with LV compatibility that have the 16 Mhz. I`m using the 5V one :18F8722
_________________
I just can`t get it all in my head.... But wait, there is a new hole opening up.... |
|
|
Dutch Guy
Joined: 20 Mar 2018
Posts: 21
Location: University of Antwerp
|
|
| Posted: Thu Mar 22, 2018 10:40 am |
|
|
I found my problem thinking "inversion" and YES...
When I switch AB transmission lines it works correctly.
Strange.. the Moxa converter is labled A RTS- and B RTS+, the click 2 board from Mikroe says A and B. When I connect the dots AA and BB it doesn`t work.
When i connect AB BA it works. Is A B for a slave and B A?
Must been something going wrong in my childhood...
Hooray
I`ll post my expanded example file when working. Hope someone shaves the rough edges of...
_________________
I just can`t get it all in my head.... But wait, there is a new hole opening up.... |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19539
|
|
| Posted: Thu Mar 22, 2018 10:59 am |
|
|
The actual RS485 standard has the B line positive compared to A, when a '1' is being sent. Unfortunately the historical standard for some of the RS485 transceiver labeling is the reverse of this!....
Have a look at:
<http://www.bb-elec.com/Learning-Center/All-White-Papers/Serial/%E2%80%A2-Polarities-for-Differential-Pair-Signals-(RS-422.aspx>
The simple way is to always test, and never assume the labeling is 'standard'... |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
