Modbus RTU communication with OPC server

[temtronic]

hhm, since you say you've used this program before and it's good, then you MUST have a hardware problem.

[ufkyldrm]

I think problem is pic issue. My devices were other type of processors.

[Ttelmah]

Seriously, you are not 'using the same program' then, which you claimed to have done.

[Ttelmah]

Looking at your posted picture again, I can't see any connection to pin 40 on the PIC. There are two visible empty holes to the right of this pin. Now the code you post, has pin B7 (40) selected as the RX enable pin....

[ufkyldrm]

I ve changed it, now it has can be problem compiler version;?

[temtronic]

It's highly unlikey to be a compiler bug. Since the modbus driver is at least 15 years old, and the compiler has worked 100% for the 877 for at least 20+ years if there were ANY 'compiler' problems we would have seen them long before now. As the program 'stalls' at the point of serial traffic, I suspect either a wiring error or no data actually being sent.
If you have an oscilloscope, put it on the serial pin and see what is being sent. If you try my 'test RS-485' suggestion, that would prove the PIC and RS-485 driver chip are functional.If no scope is available, set the baudrate for as low as possible, attach an LED logic probes and watch the LEDs for proper data.
While I don't use MODBUS, enough here do and ANY issues with the driver would be common knowledge and posted. The 877 is a mid80s PIC(obsolete now) and I have some originals still running today. RS485 is a robust design and very well proven. It sure looks like a miswiring issue to me.

Jay

[ufkyldrm]

There are warnings on while loop.

1 Inturrup disabled during call yo prevent re entrancy @GETCH_BUİ_1

2 Inturrup disabled during call yo prevent re entrancy MODBUS_ENABLE_TİMEOUT

3 Inturrup disabled during call yo prevent re entrancy
MODBUS_CALS_CRC

Is that a problem for compling program and for modbus communicatin?

My wiring pics.

https://ibb.co/ghrdnd
https://ibb.co/fACUtJ
https://ibb.co/eJjL0y
https://ibb.co/bE6ptJ

[temtronic]

warnings are NOT 'errors' !
In this case( same warning) the compiler is telling you that the interrupt is disabled so that a 2nd (or more) interrupt trigger will NOT allow the program to execute the ISR. If it was allowed you'd see a 'sunset loop' where the PIC will keep executing the loop, around and around forever until it crashes.( stack overflow)
Jay

[ufkyldrm]

[ufkyldrm]

I just add @define modbus_parity none to ebove to modbus.c and I changed data length on the master device... And my code is working now....... )))))))))))))))))))))))))))))))))))))))))))))))))))))))

Thank u guys... Why it is work?

There is no notification on example codes for parity...

Ttelmah u are my hero.

[Ttelmah]

It's 'information'. In this case not important.

They tell you, since having the interrupt disabled for a lsignificant time, would be an error. Therefore if the routines being named, were ones where the compiler stayed in them for a really long time (things like delays....), it might be worthwhile re-writing to avoid this. However these are all quick routines.

You really do need to go through your hardware.

Do you have the pull-up on the RX line to the PIC?. Needed.
Have you biased the RS485 bus?. Needed.
Double check your actual pinouts and connections.
Have you done the basic 'flash an LED' test and verified the PIC is running at the speed you expect. For everything 'serial' timing is critical, and if the PIC is not clocking at the right rate, nothing will work.

You also talk about a 'Modbus pool program'. Presumably you mean 'Modbus poll'. Have you got a spec for this. Are you sure it wants Modbus RTU, not Modbus ASCII?. Are you sure it is running at 9600bps (19200 is more common).

I see you have got it working.

Modbus-RTU defaults to always using even parity. Your master must be using no parity. No wonder it didn't work....

[ufkyldrm]