in

Solución de problemas de comunicaciones RS485 UART en BeagleBone black o AI

Escribí el siguiente código para tener problemas para gritar el aspecto de comunicación RS485 de mi firmware.

Utilizo un Beaglebone black o AI equipado con Cape COMMS 2 (que es una interfaz A/B RS485 integrada) como host para este código de prueba de nodejs.

[UPDATE A] La descripción de Cape COMMS está justo ahí: https://github.com/beagleboard/capes/tree/master/beaglebone/Comms

[UPDATE B]

Al igual que con cualquier problema intermitente, ¿ha podido discernir algo que pueda hacer para que las comunicaciones con la batería inteligente tengan más o menos probabilidades de éxito?

No. Lo que puedo decir es que si simultáneamente conecto otro software (diferente) en el bus que también solicita los marcos, mi código también obtiene respuestas adecuadas.

[UPDATE C]

¿Alguna vez las comunicaciones con la batería han sido confiables (código diferente, hardware diferente, etc.)?

Si. Tengo otro firmware que se ejecuta en una PCB personalizada que diseñé (contra el mismo hardware de batería) y siempre tengo la comunicación en funcionamiento, sin problemas.

Desafortunadamente, no recibí comunicación del dispositivo esclavo (una batería LIFP inteligente).

Los registros son:

$ npm run testRs485

> pepsr@2.2.271 testRs485 /home/debian/Desktop/devel/iot
> node testRs485.js

Opening serial port…
Terminating test
Successfully open
In port.open(): true
About to send message #1: <Buffer a5 40 90 08 00 00 00 00 00 00 00 00 7d>
Send returned true
Sent message successfuly
About to send message #2: <Buffer a5 40 90 08 00 00 00 00 00 00 00 00 7d>
Send returned true

==>etc.

Pero en algún momento, este mismo código funcionó. Pero no puedo precisar qué activa o desactiva la comunicación.

Me gustaría tener un consejo o una pista sobre cómo resolver el problema.



setInterval(function() {
    console.log("timer that keeps nodejs processing running");
}, 1000 * 60);


var SerialPort = require('serialport')


var port = new SerialPort('/dev/ttyS4', {
    autoOpen: false,
    baudRate: 9600,
    dataBits: 8,
    stopBits: 1,
    parity: 'none'
}, false)

function open () {
    if (port.isOpen) return;
    console.log('Opening serial port…')
    port.open(err => {
        if (!err) return

        console.log('Port is not open:', err)
        
        // next attempt to open after 10s
        setTimeout(open, 10000)
    });
}

// == On open…
port.on('open', () => {
    console.log('Successfully open')
    console.log("In port.open():", port.isOpen);

    const messagetoSend = new Buffer.from([0xa5,0x40,0x90,0x08,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x7d])//pack('001', '00', '740', '=?')
    let counter = 1;
    setInterval(function() {
        console.log(`About to send message #${counter++}:`, messagetoSend)
        const sent = port.write(messagetoSend, err => {
            if (err) {
                return console.error('Send error:',err)
            }
            console.log('Sent message successfuly')

            if (false) {
                console.log('Draining serial')
                port.drain(() => console.log('Drain done'))
            }
        })
        console.log('Send returned', sent)
        
    }, 15000)
})

port.on('data', data => {
    console.log('Received data: ' + data);
})

port.on('close', () => {
    console.log('Serial port closed')
    console.log('Reopening')
    open()
})

port.on('error', err => {
    console.error('Error:', err);
})

open()



console.log("Terminating test")
```

1 respuesta
1

Resumen: Esto puede ser solo un trampolín para encontrar la solución completa, pero la actualización reciente brinda algunas oportunidades claras de depuración.

Tiene configuraciones que funcionan, así como su configuración actual que no funciona de manera confiable, por lo que tiene oportunidades para comparar y contrastar, encontrar diferencias, considerar cómo esas diferencias podrían afectar las comunicaciones RS-485 y sintetizar pruebas para verificar esas hipótesis. .

Le recomiendo que también investigue más a fondo el comportamiento del transceptor Maxim RS-485 específico que se usa en la placa de interfaz de Cape (consulte a continuación).


En tu actualización, dijiste:

Lo que puedo decir es que si conecto simultáneamente otro software (diferente) en el bus que también solicita los marcos, mi código también obtiene respuestas adecuadas.

y

Tengo otro firmware que se ejecuta en una PCB personalizada que diseñé (contra el mismo hardware de batería) y siempre tengo la comunicación en funcionamiento, sin problemas.

Bien, entonces tiene configuraciones que funcionan, para que pueda comparar señales RS-485 entre configuraciones que funcionan y que no funcionan.

  • Del esquema de la capa BBB que vinculaste, parece que la resistencia de terminación RS-485 de 120 Ω (R7) está deshabilitada de forma predeterminada (habilitada mediante soldadura a través del puente de soldadura SJ7). Si bien no siempre es necesario con tramos de cable cortos, debe habilitarse en los dos dispositivos en los extremos del bus.

  • Muy importante: La capa utiliza un transceptor Maxim MAX13487 RS-485 con el «control de dirección automática» de Maxim, lo que explica por qué no tiene una señal de habilitación Tx de tipo RTS controlada por su software. La hoja de datos vinculada explica que, para que el control de dirección automático funcione correctamente, es necesario que haya resistencias de polarización en el bus RS-485 (una que eleva la señal A y la otra que baja la señal B) PERO ¡esas resistencias no se muestran en el diagrama esquemático de esa capa!

Esto sugiere que, para que el transceptor RS-485 funcione de manera confiable, ¡se basa en resistencias de polarización adecuadas en otras partes del bus RS-485! Si no ha verificado esto a sabiendas, entonces una hipótesis a considerar es que el bus solo funciona cuando se conectan otros dispositivos específicos, que tienen resistencias de polarización incorporadas, o tienen otro comportamiento (sobre cómo y cuándo conducen el bus vs. está sin conducir / inactivo), lo que permite que el MAX13487 en la capa BBB funcione correctamente.

En mi humilde opinión, su solución de problemas probablemente implicará:

  • Usando un osciloscopio en las señales de datos RS-485 A/B en las diversas configuraciones de trabajo y no trabajo, para capturar y comprender las diferencias.

  • Una lectura detallada de la hoja de datos para ese transceptor Maxim RS-485, e investigación y comparación de las señales RS-485 con los requisitos de ese transceptor, en cada configuración.

  • Una «solución rápida» para investigar podría ser agregar resistencias de polarización adecuadas en el bus RS-485, para satisfacer los requisitos de ese transceptor Maxim RS-485.

¿Te ayudó la respuesta?

Subscribirse
Notificar por
guest
0 Comentarios
Inline Feedbacks
Ver todas las Respuestas

¿Fue consciente The Blob en la versión de Steve McQueen o en el remake de los 80?

Encontrar un caso pakistaní de 1955