Configuración en estrella mediante CAN Bus, I2C o RS485

Necesito crear una red de sensores, con un nodo central recibiendo datos de +10 nodos diferentes, cada uno a +20 metros del nodo central. Básicamente, necesito crear una configuración en estrella, con un nodo central en el medio (una placa de circuito impreso con una frambuesa pi) y un trozo grande (alrededor de +20 m) para cada nodo sensor. Realmente no sé qué uso de protocolo: CAN, I2C o RS485.

¿Puedo usar CAN? ¿Puedo usar I2C (con transceptor de voltaje de refuerzo P82B96 o transceptor de búfer diferencial PCA9615 ) o tal vez un RS85 con MAX485 IC?

Mi mayor problema es cómo implementar este tipo de solución, causa de grandes stubs, hay una gran falta de coincidencia en el bus, por lo que la señal es mala.

Este artículo es increíble, muestra muchas configuraciones diferentes y la importancia de las resistencias de terminación para la coincidencia de impedancia. Pero realmente necesito implementar una solución como la Figura 12 o la Figura 13, con stubs con +20 metros.

Este artículo explora las soluciones I2C con transceptores P82B96 y PCA9615, sin embargo, todavía tengo el problema de la configuración en estrella y los grandes stubs.

Saludos y lo siento por mi inglés.

Un poco poco elegante, pero podría hacer funcionar el autobús desde y hacia el dispositivo de regreso al concentrador para que parezca una estrella, pero en realidad sigue siendo una cadena de margaritas. O coloque repetidores bidireccionales alrededor del concentrador justo antes de cada stub.
Pero desafortunadamente las instalaciones del autobús ya están hechas. Así que ahora solo tengo todos los cables (+20 m) fusionados en el mismo lugar donde estará el nodo central
¿Tienes que usar una red en estrella o simplemente pensaste que sería una buena idea?
Y bueno, no instales cables antes de saber qué datos deben pasar por ellos...
No era yo... Por jefe hizo la instalación y ahora quiere automatizar todo. Y necesito trabajar con la instalación actual de cables...

Respuestas (2)

Las redes en forma de estrella generalmente no se recomiendan, pero los stubs de 20 m en un RS485 en forma de estrella deberían estar bien, suponiendo que se mantenga por debajo de ~ 38400 baudios y no supere los 10 sensores.

Pero en este artículo* sobre RS585 con MAX485 IC, como explican las figuras 12 y 13, no se recomienda la configuración en estrella ni los stubs grandes :( Artículo*: maximintegrated.com/en/design/technical-documents/tutorials/7/…
Sí, una red en forma de estrella de 500 metros a 115200 baudios no funcionará. Por lo tanto, no se recomienda como en "No puede alcanzar el máximo potencial de una red RS485 si tiene forma de estrella". Mi punto es que 20 m no es un trozo grande. Probablemente ni siquiera necesite la terminación en ningún otro lugar que no sea el transmisor, y funcionará bien.
¿Estás seguro de que 20 metros no es un trozo grande?
La importancia de la longitud del stub depende de la velocidad en baudios que esté ejecutando. Como ha dicho Arcatus, si solo se ejecuta a una velocidad de transmisión lenta como 38400, entonces un trozo de 20 m no es tan malo.

Suponiendo que la topología en estrella disfuncional ya está en su lugar y no tiene requisitos de tiempo real muy estrictos, tal vez podría unir lo que tiene con esta solución:

  • En el nodo central, coloque un transceptor CAN y un terminador 120R.
  • En cada nodo, otro transceptor CAN y un terminador 120R.
  • Mux las líneas CANH CANL a un nodo a la vez, utilizando un interruptor analógico IC.
  • Ahora multiplexe en el tiempo el acceso a cada nodo y léalos uno a la vez en secuencia en el bus CAN.
  • Toda comunicación debe ser: nodo maestro solicitando algo, nodo esclavo respondiendo. Los esclavos no pueden hablar a menos que se les indique (o pasarán rápidamente a estado pasivo de error de CAN en caso de que el maestro esté desconectado).

Con esta solución, básicamente tiene 10 CAN-bus bien terminados de 20 m cada uno y sin stubs. Entonces no habrá problemas para ejecutar CAN a 1Mbps, solo asegúrese de que el maestro seleccione un nodo antes de transmitir datos CAN.

wow gran idea. Pero algunos nodos necesitan enviar datos al nodo central sin esperar una solicitud. Imagine que se abre una puerta, ese nodo necesita enviar inmediatamente esa información al nodo central... En un CAN BUS típico, cualquier nodo puede enviar un mensaje al bus (y esperar a que el nodo central lo reciba). En tu idea, eso no es posible...
@ user273780 - Hola, con respecto a " ese nodo debe enviar inmediatamente [...] " Verifique la especificación del sistema (o, si no tiene una, créela y apruebe) para indicar exactamente qué "inmediatamente" significa, porque siempre hay un retraso (por ejemplo, incluso solo el tiempo de ejecución de MCU), por lo que realmente es imposible "enviar inmediatamente". Ahora la única pregunta es: ¿Cuánto tiempo puede ser el retraso, entre el evento y la recepción maestra? Entonces, como puede ver, el enfoque de esta respuesta aún podría ser posible, si el dispositivo maestro sondea los sensores lo suficientemente rápido como para cumplir con la especificación general del sistema.
Imagina que tienes un botón en tu microcontrolador. Cuando presiona el botón, el borde descendente/ascendente puede generar una interrupción externa en el microcontrolador. En el momento (y solo en ese momento) me gustaría enviar esa "información" al maestro. Así que no quiero que el maestro le pida constantemente nuevos datos al esclavo...
@ user273780 - Hola, sí, entiendo las interrupciones. Sin embargo, incluso una interrupción activa el código para que se ejecute, por lo que cualquier resultado no es inmediato . La única pregunta es cuánto retraso se puede aceptar (y por qué) en su sistema específico. " Así que no quiero que el maestro le pida constantemente al esclavo nuevos datos... " Todavía no me queda claro exactamente por qué no quieres eso. Por supuesto, cuantas más restricciones tenga, menos soluciones habrá. Edite la pregunta y agregue todas las restricciones conocidas en la pregunta , para evitar que perdamos el tiempo dando soluciones que rechazará. ¡Gracias!
@user273780 Es hora de ser ingenieros y hacer los cálculos reales en tiempo real. Una trama CAN de 11 bits con datos de 8 bits viene con un espacio entre tramas de conteo de sobrecarga de 47 bits. Si el maestro realiza una solicitud a través de un marco RTR, no hay datos. Por lo tanto, el tiempo total para sondear cada nodo en busca de 8 bits de datos sería una solicitud RTR maestra de 47 bits + una respuesta de esclavo de datos de 47+8 bits = 102 bits. 102 bits a 1 Mbps = 102 us de tiempo de respuesta. Con un diseño de este tipo, puede sondear 10 nodos en 1,02 ms, o si lo desea, alrededor de mil veces por segundo.
Esto, por supuesto, ignora el tiempo de cambio analógico, la propagación de la señal y detalles como ese. Pero es probable que sean insignificantes.
Configuración en estrella mediante CAN Bus, I2C o RS485
RespuestasAquíPolítica de privacidad1y, 0v