SN65HVD72: Receive same data as sent

Hi Max,

yes you understand issue properly. I have USB-> RS485 dongle and with those I get correct data (which I mentioned in first post).

Ok I have /RE always low but int this case you said I juts got echo? I tried to handle /RE DE pins simultaneously but in this case looks like communication stuck (I see data on A/B but didn't get any response from slave). I think it can be related to /RE, DE handling so do we have some appnot or something like those 2 should be driven? Thanks a lot.

Marek

Marek,

How to handle DE/RE depends on what is wanted in the application:

 - If an "echo" function is needed (i.e., each transmitted message is also received by the sender) then /RE can always be low.  However, the CPU should be configured accordingly so that it expects these echoed messages and processes them appropriately.

 - If an "echo" is not wanted, then /RE should be high while the transmission occurs so that the receiver output does not toggle.  (Most transceivers will disable the R output in this state, so it is useful to use a pull-up resistance to make sure the CPU sees a constant-high level and doesn't mistakenly interpret data on the line.)

This second method is often accomplished by controlling DE and /RE using a single control line.  It sounds like you tried this and saw some issues, but I think if we look into it a little more we could debug those issues.  (If the correct data is showing up on the A/B lines then the slave should be responding.  You could check that the slave R line is toggling accordingly and see whether the response shows up on A/B but just doesn't translate to the CPU somehow.)

Regards,
Max

Hi Max,

thanks. Let me investigate it bit more and get back to you if have questions. Thanks.

BR,

marek

Hi Max,

unfortunately still cannot make it working.

I hacked a bit libmodbus  in this way:

static ssize_t _modbus_rtu_send(modbus_t *ctx, const uint8_t *req, int req_length)
{
#if defined(_WIN32)
modbus_rtu_t *ctx_rtu = ctx->backend_data;
DWORD n_bytes = 0; 
return (WriteFile(ctx_rtu->w_ser.fd, req, req_length, &n_bytes, NULL)) ? (ssize_t)n_bytes : -1;
#else
modbus_rtu_t *ctx_rtu = ctx->backend_data;
ssize_t size;
/*#if HAVE_DECL_TIOCM_RTS
if (ctx_rtu->rts != MODBUS_RTU_RTS_NONE) {

if (ctx->debug) {
fprintf(stderr, "Sending request using RTS signal\n");
}

ctx_rtu->set_rts(ctx, ctx_rtu->rts == MODBUS_RTU_RTS_UP);
usleep(ctx_rtu->rts_delay);
*/
system("echo 1 > /sys/class/gpio/gpio78/value;echo 1 > /sys/class/gpio/gpio79/value");
size = write(ctx->s, req, req_length);

printf("Sleep for:%d microsecs\n", ctx_rtu->onebyte_time * req_length + ctx_rtu->rts_delay);

usleep(ctx_rtu->onebyte_time * req_length + ctx_rtu->rts_delay);

system("echo 0 > /sys/class/gpio/gpio78/value;echo 0 > /sys/class/gpio/gpio79/value");
/*
ctx_rtu->set_rts(ctx, ctx_rtu->rts != MODBUS_RTU_RTS_UP);
*/
return size;
// } else {
//#endif
// return write(ctx->s, req, req_length);
//#if HAVE_DECL_TIOCM_RTS
// }
//#endif
#endif
}

So before write I set both pins to 1 (78 is DE and 79 is /RE). I can see data on A/B lines sent properly juts cannot see any received data. Does above make any sense? Form my understanding when we sent data we need to swap /RE,DE then we should be able to receive data. Is this some kind of time critical? Thanks.

marek

Hi Marek,

It sounds like your understanding is correct.  You need to have DE high to send data, and you need to have both DE and /RE low to receive a response.  Is it possible that the response comes back before you are able to switch the /RE state low and you end up missing it?  (Note also that the SN65HVD72 receiver could take up to 50 ns to become enabled after /RE goes low, although this time is usually small compared to the time it takes the software to toggle the pin.)

Max

Hi Max,

in source code is after write delay in uSec to I think keep data to be sent over bus (baudrate and length of payload is taken into a consideration). This delay for my payload is ~9ms. I'm not expert in RS485 but immediately after data are received I see stop bit and then slave send data back. Is that right or it depends on master to somehow tell slave wait a bit until I switch to receiving mode? Thanks.

BR,

marek

Marek,

The slave should wait until the master is in receive mode before responding.  You may want to try adding a delay to the slave code that is longer than the ~9 ms that is configured in the master.  You could also double-check that the master timing is reasonable by probing the D and DE/RE lines on its transceiver.  DE/RE could go from high to low any time after the "stop" bit on the D line, but the longer it takes for them to make this transition the longer the slave would need to wait before responding.

Max

Hi Max,

I cannot change code on slave it's for me black box ;). In above reply you mention signal D (it is OK or typo?). I'll try to probe /DE, RE and A/B and verify it after stop pins are switched properly. Thanks.

Marek

Hi Marek,

What I meant was you could look at D and DE simultaneously.  If DE is high for a long time after the last bit on D is sent, then maybe the transmitter is remaining enabled for too long and is interfering with the slave response.

Max

Hi Max,

I was able to have /RE, DE working simultaneously but when interfacing with device I still see an issue that response is delivered but it's not right.

Basically I'm trying to read input status from device :

with this bytes: [01][02][00][00][00][04][79][C9] which I see on A line

then response should be something like [01] [02][04][00][CRC] but I'm getting randomly:

<00><00><01><02><01><00> or <00><01><02><01><00><A1><88> which seems to be kind of OK but first byte is invalid.

I contacted device manufacturer and they use some AnalogDevices RS485 transceiver and wrote me that maybe transceiver are incompatible which is unlikely.

On scope I see following when TX is done and we start RX:

Can this small glitch cause an issue? It's when DE/RE goes down. Also data on RS485 looks OK but what I receive on RX pin is what was posted above. Any idea what to check or adjust? How does signal should look like when TX is finished and we start RX? Thanks