9 replies to this topic

[gakkus]

Hi,

I would like to control the RTS-level (high/low) on the Pin 7?

Because there is no

port.RtsEnable

, I tried the following code:

SerialPort port = new SerialPort("COM1", 19200);
port.Handshake = Handshake.RequestToSend;
port.Open();
while (true)
 {
Thread.Sleep(1000);
}

Thanks and Greets
Gakkus

[Mario Vernari]

Hello Gakkus, and welcome in the forum. If I remember well, there's no handshake management in the .Net MF version 4.1. Still haven't check in the more recent 4.2 release, though. May I ask you what's your purpose? I had to control the RTS for a RS485 interface, but I turned to an hardware solution, instead of a software way. Cheers

[caEstrada]

Hello Gakkus, and welcome in the forum.
If I remember well, there's no handshake management in the .Net MF version 4.1. Still haven't check in the more recent 4.2 release, though.

May I ask you what's your purpose?
I had to control the RTS for a RS485 interface, but I turned to an hardware solution, instead of a software way.
Cheers

Gakkus,

I use D9 to do something similar. You can implement your own RTS. I used this on MAX483...

//Apaga para dejarlo en modo receive
TXEnable.Write(false);
RXEnable.Write(false);
//Espera milisegundos para el turnaround
Thread.Sleep(1);

//Para limpiar el buffer de respuesta
ceMemset(ref iresponse, 0, iresponse.Length);

// ---------------------------------- NOTA: No usar breakpoints aquí dentro!!!!
while (com1.BytesToRead >6)

[fesp]

Hello Gakkus, and welcome in the forum. If I remember well, there's no handshake management in the .Net MF version 4.1. Still haven't check in the more recent 4.2 release, though. May I ask you what's your purpose? I had to control the RTS for a RS485 interface, but I turned to an hardware solution, instead of a software way. Cheers

 

@Mario: Can you be more specific about what hardware solution you used? I'm using the MAX483 for RS485 and am controlling the RX/TX flow manually from software. But I don't like the Thread.Sleep at the end of the sending part as this timing is very unreliable.

[caEstrada]

Fesp,

 

You can turn pin7 on and off like any other digital signal.  To avoid the thread sleep, you can implement interrupts. 

 

I tested this code -actually, is working for more than 4 months now- with Badger Meter M2000 Modbus RTU.  I moved

from MAX484 to the venerable SN75176 DIP with excellent results. 

 

One point I faced: what are the values of the Pull-Ups Resistors?  Remember you have to keep both transmitter and receiver

in know states above 250mV....and no manufacturer suggest values...

 

Regards,

[caEstrada]

Fesp,

 

Another solution if you do not want to deal with pull ups, is to use failsafe transceivers that take cares of the known issues.  They are quite more expensive.

 

One thing to remind in ModbusRTU is the silent time of 3.5characters, which change from baudrate.  In this kind of applications, you have three points of failure: netduino, software and the remote RS-485 station.  All three should be aligned.

 

Hope it helps.

[fesp]

CaEstrada, thanks for your reply.

 

I'd like to get an interrupt as soon as the transmitting is done. But my question is, what circuit do I need to generate that interrupt?

 

Also, you mention you have tested 'this code'. What code are you referring to?

 

Thanks!

[Mario Vernari]

fesp, I solved without interrupt because there's no way to generate a so reliable timing, unless you deal with native code.

Instead, I used a very common way (although not the ideal one) to pull the line active while the transmission is flushing out the data.

http://highfieldtale...t-open-toolbox/

 

I know it's a solution that I would *never* use in a professional project, but I shocked by seeing how often is used, even in worldwide sold adapters. At this point, it's far from being something ridiculous!

 

Hope it helps.

Cheers

[fesp]

Thanks Mario for this great reply. I really enjoyed reading your blog post!

I've stumbled upon other similar solutions (one for example using a 555 timer, another using a 72LS123) but the solution you are presenting is the most simple one I have seen. The problem with such an approach is of course, as you mention, that the timing is independent of the transmission speed. It very much depends on the response speed of the targeted device(s) wether this will work.

 

But I'm definitively going to try your solution, it is easy enough to build! Thanks again.

[NooM]

nothing todo with the original stuff, but:

mario, thanks for that link/blogpost, crc looks promising for serial error detection.