Modbus comm problem with a PIC24FJ1024GB610

JMH · Joined: 09 Mar 2018 Posts: 8

Hey guys I am new to this forum. I am kind of old school compared to you guys. Back in the day I developed many projects using the PIC16C series. All in assembly. I am semi retired now and trying to get back to what I like to do best.

I have been browsing around here over the past few months trying to figure out how to fix what I think is a timing problem but I'm still getting stumped. I am using the modbus slave example. The example program works great when I connect through the onboard USB to UART interface on the Microchip Explorer 16/32 board. However, when I bypass the USB to UART and tie directly to the RX and TX lines on the processor with a MAX232 I get no response. Looking at the signals on the scope there seems to be a slight timing difference.

My goal is to eventually try and connect to a PLC. The PLC just has RS232 ports so i can't use a USB to UART converter because there is no power on the RS232 line for the converter. I have a modbus test program I wrote years ago and it works fine so long as I go through the USB port but when I bypass the USB I get nothing? I have images of the scope screen shots I can post but I don't know if this forum allows it or if anyone is even interested.

As mentioned the program works great so long as I go through the USB port but stops responding when I switch to RS232. The rx data on the rx pin looks the same using the USB or RS232 except for timing and frame width. I checked both programs with a digital analyzer set to modbus and they both show the same data stream except the frame width for the RS232 is a little shorter.

The code I am using is just the modbus slave example code.

Any help or direction would be greatly appreciated...
Thanks....

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

Your basic complaint is:
If you use a MAX232 plus a serial cable instead of your USB-to-RS232
converter cable, then it fails.

I would look at your Max232. Is it really a "232" or is it a 232A, or
one of the many other variants ? Do you have the correct capacitors ?
They vary, depending on which "MAX" chip you have.

Did you build the Max232 circuit or is it on the Microchip Explorer board ?

What about the serial cable ? Did you buy it or make it yourself ?
If you bought it, give the manufacturer, part number, and website.
Are the connections between the Max232 and the DB-9 connector on
the PC correct ?

To show images on this forum, you have to upload them to a free image
hosting website (ex. Tinypic.com) and then post either a link or a hotlink
to your post in this thread. Then we can see your images. If you post
a hotlink, don't make the images too big. Maybe 1024x768 max.
Do a web search for: free forum image hosting

Ttelmah · Joined: 11 Mar 2010 Posts: 19539

What you do is upload the pictures to a third party hosting site, and just post a link here.
It sounds as if you are testing with a PC?.
Are you using the same PC code to generate the comms in both cases?.
I'd be looking at the implementation of the MAX232.
The chip you list, is not compatible with a MAX232. It would require a MAX232CPE (3.3v version).

I see PCM_Programmer posted while I was typing.

JMH · Joined: 09 Mar 2018 Posts: 8

Thanks PCM programmer.. I know what the problem is I am just stumped on how to adjust it. Using the data analyzer with the USB the gap between received bytes in a frame is 0.2083ms which works great. Using the MAX232 the gap between bytes in a frame is 0.1107ms which does not work. Exact same program on both. Individual bytes received on both are the same according to the analyzer. I just switched the leads over. Do you know of any way I can adjust the tolerance between the received bytes in a frame that the PIC is receiving? I can run the same program between two computers with no problem. I can connect to my PLC to my computer with the same program with no problem.

The MAX232 is one I have been using for years. I built it myself. I have several of them laying around.

JMH · Joined: 09 Mar 2018 Posts: 8

Thanks Ttelmah.. My bad.. I changed over to a MAX3232EEUE+ a few months back which is a 3.3 to 5 volt chip. I am running it at 3.3 volts. I can simulate the exact same procedure with the exact same setup except using an actual PLC in place of the PIC and that works fine so I don't think it is a hardware problem, but I could be wrong. I will certainly double check all my hardware again.

I am using the MCP2221 Breakout Module USB-to-UART/I2C/SMBus protocol converter. It works great!!

I do appreciate everyone's help!

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

So the problem is the gap between bytes coming into the PIC.

Are you using a hardware UART on the PIC to receive the bytes ?
Does it use an interrupt-driven software fifo buffer ? Like in Ex_sisr.c ?

What program is sending the bytes ? What is it called ?

What baud rate are you usng ?

JMH · Joined: 09 Mar 2018 Posts: 8

The gap between the bytes is the only thing I see different.
This is a new PIC I started working with on the Microchip Explorer 1632 board so I believe it is a hardware UART. I am using the serial interface port on that board.
As per the modbus slave example I do not see any reference to any fifo buffer or any instance to Ex_sisr.c.
The program I use to send and receive modbus data I wrote myself and have been using it for over 15 years. I owned an automation company for about 14 years before I sold most of it two years ago. That is why I am semi retired..

These are my basic modifications that I made using the sample modbus slave program.

main.c

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

JMH · Joined: 09 Mar 2018 Posts: 8

Well..What I am trying to do is have a PLC communicate with my interface board. I have no control over how data is sent from the PLC other than setting up the port settings. I have been using this particular PLC for many years and have never had any problems with it so I know its communications is solid. I just wanted to design a few peripherals that would be compatible with this PLC. There has to be a way to adjust the sampling that the PIC looks at when it receives data. In other words when a byte is received some where there has to be a time period before it starts looking for another byte and if so is it adjustable. I get the same affect when I send data to my interface using a PLC or my computer. The gap is still present on both.

I'll keep digging!!

Any other ideas throw them my way.

Thanks for the help....

JMH · Joined: 09 Mar 2018 Posts: 8

note...The normal protocol for the serial port on the PLC is 9600,8,N,1. Using this I get no return however if I change the PLC to 9600,8,E,1 it then starts communicating except all I get is an exception errors 'bad address' on the PLC. Is there any way to adjust the frame width window in the PIC when a complete message arrives and is there a way, in code, to look at how the bits are shifting into the UART on the rx line?

Sorry for the long drawn out posts. It's just been a while since I last did some heavy programming!!

Thanks....

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

JMH · Joined: 09 Mar 2018 Posts: 8

Believe it or not it's working correctly now. Even using RS485. It looks like the issue is there has to be two stop bits in the #use statement even though it signifies the parity as 'None'.

Ttelmah · Joined: 11 Mar 2010 Posts: 19539

OK.
At least you are running. Smile

It sounds as if you do have a scope or logic analyser?. I'd be grabbing some bytes from the PLC, and verify what parity it is actually generating. It sounds suspiciously as if the PLC is not generating parity correctly, and is ignoring it on the incoming data. Hence it doesn't complain when it receives data without parity from the PIC, but does need ten bits plus the start sent. Conversely the PIC complains because the parity it is receiving is wrong.

JMH · Joined: 09 Mar 2018 Posts: 8

Thanks Ttelmah, I do have a scope and logic analyzer. That's how I found out what it was doing. I have modified my program a few times since Friday. So far my test program is still running 24 hours a day and so far it has kept the pace with no errors. On the PLC side I constantly monitor and log any communication errors that might occur. I agree with you that something is off. I plan on digging into this week.

Thanks for your comment....