CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Weird consistent values in modbus_rx struct

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Dutch Guy



Joined: 20 Mar 2018
Posts: 21
Location: University of Antwerp

View user's profile Send private message Send e-mail

Weird consistent values in modbus_rx struct
PostPosted: Tue Mar 20, 2018 4:56 am     Reply with quote

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

View user's profile Send private message Send e-mail

PostPosted: Tue Mar 20, 2018 6:27 am     Reply with quote

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

View user's profile Send private message Send e-mail

PostPosted: Wed Mar 21, 2018 10:44 am     Reply with quote

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

View user's profile Send private message

PostPosted: Wed Mar 21, 2018 11:13 am     Reply with quote

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: 19195

View user's profile Send private message

PostPosted: Wed Mar 21, 2018 11:21 am     Reply with quote

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

View user's profile Send private message Send e-mail

PostPosted: Thu Mar 22, 2018 8:58 am     Reply with quote

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: 121
Location: Bombay, India

View user's profile Send private message Visit poster's website

PostPosted: Thu Mar 22, 2018 10:20 am     Reply with quote

Have you tried to correct the value for the delay. Your board must have a 16M crystal as per this link https://www.mikroe.com/easypic-pro-v7-pic18f87k22 Could that be the problem?
Dutch Guy



Joined: 20 Mar 2018
Posts: 21
Location: University of Antwerp

View user's profile Send private message Send e-mail

PostPosted: Thu Mar 22, 2018 10:22 am     Reply with quote

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

View user's profile Send private message Send e-mail

PostPosted: Thu Mar 22, 2018 10:26 am     Reply with quote

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

View user's profile Send private message Send e-mail

PostPosted: Thu Mar 22, 2018 10:29 am     Reply with quote

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

View user's profile Send private message Send e-mail

PostPosted: Thu Mar 22, 2018 10:40 am     Reply with quote

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: 19195

View user's profile Send private message

PostPosted: Thu Mar 22, 2018 10:59 am     Reply with quote

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'...
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group