Comments (14)
It seems you are using RS485, are you using 120ohm termination resistors and
680ohm pull up and pull down resistors? What converter are you using for the pc
interface. Does it also contain pull up and pull down resistor or the
termination resistor. If so you must not use pull up and pull downs on master
side only termination resistor. Also try to increase timeout to 1000ms. PC
simulated slaves are tricky things because exact character timing can not be
achieved. Are you using arduino V1.04?
Send me your sketch...
Original comment by [email protected]
on 16 May 2013 at 8:50
from simple-modbus.
On the PC there is a PCI RS232 card. I'm converting the RS232 to RS485 using
the 485SD9RJ. I have used this converter before on a PLC (as a master) with ten
arduino slaves, successfully (using the SimpleModbusSlave library). In my
configuration, a custom shield is attached to an Arduino MEGA2560. There is an
LTC485 chip for the MODBUS communication.
I'm using 390ohm termination resistor on the master side. I do not have pull
up/down resistors but I managed to stick two 680ohm resistors on the LTC485
chip. There was no difference. I increased the timeout to 1000ms. Some times
adding a delay at the end of the program and increasing the scan rate seems to
work. But it is random and not permanent.
I have to mention also that the slave devices have EVEN parity, and this
setting is not configurable. So I'm forced to use EVEN parity. I manage to
communicate with the device using the following settings:
First I use Serial3 on Arduino MEGA2560, so I changed the Serial port to
Serial3.
Then at the end of the Setup() on my program I added the following:
//clear parity, stop bits, word length
UCSR3C = UCSR3C & B11000001;
UCSR3B = UCSR3B & B11111011;
UCSR3C = UCSR3C | B00100000; // Parity EVEN
UCSR3C = UCSR3C | B00000110; // Word length 8
UCSR3C = UCSR3C | B00000100; // Stop Bit 1
With these settings, I'm able to communicate with the devices which have EVEN
parity without errors. (Well, if this is right then you can add it as a feature
at your library)
I'm using using arduino V1.04 and the library version is 6, not 7 as mentioned
in my first post.
I'm attaching the sketch and the modified libraries (Serial. to Serial3.)
Original comment by [email protected]
on 16 May 2013 at 9:46
Attachments:
from simple-modbus.
The 485SD9RJ does have 4.7K pull up and pull down resistors. It does not
have a termination resistor. The master must have a 120ohm termination
resistor not 390ohm. This will cause reflection on the communication lines.
Use the PC (485SD9RJ converter) as the end of line unit with a 120ohm
resistor on its terminals. As the converter does have pull up and pull down
resistors it should not be necessary for the 680ohm (you might have to use
it though). All other slaves must not have any resistors on the A and B
lines.
In your sketch you commented that you are not using the TxRxEnable pin, how
are you toggling the RE and DE pins on the LTC485 then?
Using V7 clears up code cause you don't have to explicitly use pointers to
setup packets.
Original comment by [email protected]
on 16 May 2013 at 10:58
from simple-modbus.
I replaced the 390 Ohm resistor on the master with 120 Ohm and placed
another one at the PC terminals.
The situation is the same. The first 2 packet are successful and then fails
occur, only at packets 1&2 (PC). I got some random successfully transmitted
packets to/from the PC from time to time...
The TX3 is handling both the RE and DE pins on the LTC485 (
https://docs.google.com/file/d/0B57pZiPtc2kQM21hU0RDaW1VZXc/edit?usp=sharing
).
Original comment by [email protected]
on 16 May 2013 at 2:50
from simple-modbus.
This is very strange. My guess is some where there is character(s) being
lost. This might be due to how you toggle the RE and DE enable pins. There
must be some delay after the last character is transmitted to allow the
data to reach its destination. Using your circuit does not allow for any
delay, as soon as the master stops transmitting the driver is disabled. The
library was tested using an extra pin to toggle the RE & DE pins.
Before version 5 I used a delay of 3ms before I switched off the MAX485
driver. This worked when no pull up and pull down was used, but I found
that some slaves did not like this so I removed the delay but then I had to
use pull up and pull down resistors otherwise the communication lines were
floating and random errors would occur. You can insert the delay again and
see if this will help but you will have to use another pin to toggle RE &
DE. Insert the delay(1) after Serial.flush() in the sendPacket() function.
It is still strange why the PC worked at point to point communication and
not now. I know PC serial ports does not have tight control over the
character timeout especially if you are using usb to rs232 converters. I
have struggled allot with this when I created the ModbusMaster library for
Processing. It is still temperamental because I cant get rid of the inter
character timeout between character transmissions.
Original comment by [email protected]
on 16 May 2013 at 3:24
from simple-modbus.
One more thing. You mentioned you use SimpleModbusSlave with the converter and
PLC as master. The arduino serial library does not allow accurate inter
character timing. This is a limitation in the hardware serial library. This
means true character timing cannot be implemented with SimpleModbusSlave
(actually this is true for most modbus libraries which does not use a timer
interrupt to check this). As a result of this SimpleModbusSlave is much more
relax on this standard. This is only true when receiving. Transmitting of
characters is sequential without any delay from the hardware both for
SimpleModbusSlave and SimpleModbusMaster.
Original comment by [email protected]
on 16 May 2013 at 3:34
from simple-modbus.
One more thing ;)
Try a baud rate of 9600.
Original comment by [email protected]
on 16 May 2013 at 3:36
from simple-modbus.
Any success?
Original comment by [email protected]
on 21 May 2013 at 8:20
from simple-modbus.
I was just about to reply! :)
I cut the trace to DE/RE pins and tied them to pin 25. Now it is software
driven.
I tried adding the delay you mentioned above at the sendPacket() function, but
I didn't see any change.
But baud rate of 9600 seems to stand better than 19200.
While at 19200 the communicate with the PC AND the other 2 devices is very rare
(the PC is not responding to requests), at 9600 there is significant
improvement. The communication is not seamlessly though, I get timeouts from
the PC slave from time to time.
@ 9600
======
Right now I'm probing the circuit with an oscilloscope.
There was something strange. While the communication is working fine, I found
out that when I tried to scope the RX3 pin, I started to get timeout errors at
the PC side. I tied a 10K from RX3 @ 5V. This solved the problem.
LAST UPDATE (while writing this post)
-------------------------------------
As I mentioned above, I use Labview to create a modbus slave at the PC.
I'm setting the Serial port timeout in Labview at 100 ms, same as the
turnaround delay of the other two salve devices.
The timeout at the master side is set at 125ms.
The scan rate is set at 100 ms.
The communication seems to be perfect. I can see that at the oscilloscope
screen, too.
Right now I have removed all the termination resistors and the bias.
I'll consider the situation SOLVED! (for the time being...!)
Summarizing:
The arduino master has been set at 9600 bps, 125 ms timeout, 100 ms polling.
The PC serial port timeout has been set to 100 ms through Labview, the same
timeout as the other 2 slave devices. Arduino master has been set up for even
parity.
A 10k resistor between RX3 and 5V(??).
Thank you very much for the support! Keep up!
P.S I'm leaving a wish list below :)
I would really like to see at future versions of your libraries the following
features:
1) the ability to choose any UART you want
2) support for 8EN setup
Original comment by [email protected]
on 21 May 2013 at 11:08
from simple-modbus.
It seems this strange behavior is linked to the RX3 pin. How did the pulse look
on the the RX3 pin? The lower baud rate and pull up resistor might be pointing
to the same thing?
Do you have a schematic of your custom RS485 shield?
Original comment by [email protected]
on 21 May 2013 at 11:38
from simple-modbus.
I'm posting some photos from the oscilloscope.
The yellow line is the TXenable/disable pin (driven by the library).
The blue line is the TX3 pin, the master request.
The pink line is the RX3 pin, the slave answer.
In the attached images you can see the transmitted and received packets.
In the "with resistor 500ms.jpg" you can identify the 6 packets. The first
yellow rising edge indicates the start of transmission of the first packet.
As you can see in the "with resistor 200ms.jpg" and "with resistor 500ms.jpg"
images, the sequence is as expected: While the master TX/~RX is enabled (yellow
line), the master transmits the data (blue line) and there is no activity at
the RX3 pin (pink line).
In the "without resistor 200ms.jpg" you can see that there is activity at the
RX3 pin while the master is transmitting.
Notice that this is happening only when I try to monitor the RX pin and the 1k
pullup resistor is absent. I've noticed it because I started to get failed
requests when I touched the RX3 pin with oscilloscope probe.
About the RS485 schematics, check comment #4.
Original comment by [email protected]
on 26 May 2013 at 11:10
Attachments:
- [with resistor 200ms.jpg](https://storage.googleapis.com/google-code-attachments/simple-modbus/issue-10/comment-11/with resistor 200ms.jpg)
- [with resistor 500ms.jpg](https://storage.googleapis.com/google-code-attachments/simple-modbus/issue-10/comment-11/with resistor 500ms.jpg)
- [without resistor 200ms.jpg](https://storage.googleapis.com/google-code-attachments/simple-modbus/issue-10/comment-11/without resistor 200ms.jpg)
from simple-modbus.
I have a suspicion that the RO pin from the driver goes into high impedance
state when RE is high, this was confirmed from the LTC485 and the MAX485
datasheet. This would mean that theoretically the RX3 pin (which is interrupt
base) could pickup a stray signal (noise) since the pin is not referenced to a
specific logic level. I must say I did not expect this and have never
experienced this with the MAX485/487 family. By tying the interrupt pin high
with a 4.7k or 10k will solve this since the pin is referenced at a known logic
level. Why it only affects the first two packets of the PC is still a mystery
to me..
Original comment by [email protected]
on 27 May 2013 at 6:27
from simple-modbus.
By the way, I have tested the auto switching circuit(in comment #4)of the RS485
and it works flawlessly at any baud rate.
Original comment by [email protected]
on 3 Jun 2013 at 7:19
from simple-modbus.
I'm glad to hear that. :)
On Jun 3, 2013 10:20 PM, <[email protected]> wrote:
Original comment by [email protected]
on 3 Jun 2013 at 7:24
from simple-modbus.
Related Issues (20)
- Arduino Ver1.5.4 there is an error in the simpleModbus libraries. HOT 4
- Error compiling SimpleModbusSlaveArduino on EDi 1.0.5 HOT 3
- SimpleModbusSlaveV8 example code
- modbus_configure HOT 6
- Arduino Micro usb serial not working HOT 1
- Illegal data address <01><83> HOT 4
- ModBUS Response failure HOT 1
- cannot convert 'Serial_*' to 'HardwareSerial*' for modbus_configure HOT 1
- SIMPLE MODBUS MASTER compile problem with Arduino DUE. HOT 1
- Slave device reported an exception - 1 - Illegal Function HOT 2
- ERROR OUTPUTS FUNCTION TO ENABLE 16 SIMPLEMODB USSLAVEV8 HOT 1
- Variable Address HOT 1
- No Slave Response HOT 2
- Support for function 5 and 6. HOT 11
- Wifly HOT 1
- Modbus Slave Coil and Input Registers HOT 2
- modbus Slave freeze HOT 1
- Assign Modbus slave ID by hardware HOT 2
- Maximum baud rate HOT 1
- Modbus Server HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from simple-modbus.