Mis experiencias con el BUS CAN

[MGLSOFT]

El Sniffer Can que hice yo, con varias modificaciones, esta basado en uno de Microchip, el software que utiliza es de ellos y se puede bajar de su pagina.
En posts anteriores puse el link donde se encuentra esta informacion.

Si, el match programa los 2505x, y las plantillas vienen incluidas en mplab, como cambie de maquina y aqui no lo tengo instalado te debo la explicacion de donde encontrarlas y como usarlas, da para un hilo eso solo, ya que los 2505x son OTP, se programan una sola vez y si pifiaste de una despues es un problema, hay registros que se pueden reprogramar por el bus CAN, pero al perder la tension vuelven a su valor programado original.
Yo pifie en ID de uno y despues no lo podia localizar en la red (no contestaba) y ese registro y los de velocidad de comunicacion no son reprogramables.

Respecto al orden del hilo, es muy buena tu acotacion y voy a implementarla la semana que viene, que ya voy a estar liberado y voy a poder entrar mas al foro.

[Kid_Bengala]

hola

hace tiempo que seguia el hilo y otra vez me lo lei entero, pero no recuerdo si se habia hablado de j1939 y en el buscador no sale nada y como que leermelo entero de una tirada ufff. me toca en el trabajo desarrollar un circuitillo para conectarme al bus can de unos camiones con el protocolo j1939 y habia pensado en un pic para hacerlo (aun tengo pendiente terminar mi desarrollo con pic para crear una red can) y me preguntaba si alguien sabe si con ccs se puede implemenntar este protocolo o es mucho lio. la verdad que tampoco quiero reinventar la rueda basicamente porque a parte de no tener idea, agota que te manden cosas raras ultimamente en el curro, pero habra que apechugar que por la crisis nos toca ahcer de todo jejeje (bueno, casi de todo  ). gracias

p.d: cuando recupere tiempo para ponerme con el diseño de la red can con pic, amenazo con mas preguntas jeje

saludos de antonio

[MGLSOFT]

Si tienes el protocolo escrito y lo compartes, podremos ayudarte.
Seguramente que un PIC puede correrlo sin problemas.

Buscando en la WEB encontre esto:
http://books.sae.org/book-hs-1939/2009

Tal vez ayude, pero es pago...

[MGLSOFT]

Rezandole a San Google, encontre esta pagina que me llevo a este documento....
Y este otro documento..

[Kid_Bengala]

hola

si, el appnote de microchip lo encontre hace unos dias pero era para c18 y desconozco si cambia mucho para ccs, pero supongo que tendre que probarlo e ir arreglado hasta que funcione. ¿es mucha la migracion de c18 a ccs? en teoria al ser c deberia ser portable, pero ya me se lo de en teoria... gracias

saludos de antonio

[MGLSOFT]

Cual es la aplicacion que debes hacer??

[Kid_Bengala]

hola

leer los valores de unos camiones... (no se para que leches quieren esto la verdad, tampoco me han dicho mucho, simplemente que lo haga y me calle...) para temas de velocidad y demas cosas,yo creo que se creen que pueden leer los valores del tacometro o algo.Lo que no se,es si soy capaz de hacer algo,cuando me dejaran un camion para probar si lee la velocidad a la que va y demas...

saludos de antonio

[MGLSOFT]

Entonces lo que vas a tener que acceder es a uno o dos registros, por lo tanto no creo que tengas problemas...

[arqui_lester]

hey hola como estan una pregunta necesito mandar una trama de 64 bytes en CAN alguien tiene una idea de como mandar la trama de modo que el  controlador que la recive sepa cual es el primero o segundo hasta el ultimo, si alguien tiene una idea o una seccion de codigo util me ayudan porfa
cuidense

[MGLSOFT]

Si leíste como funciona CAN, encontraras que cada mensaje puede llevar un máximo de 8 Bytes a transmitir.
Esta pensado para optimizar el uso del Bus.

Sin embargo, los protocolos de mayor nivel, montados sobre CAN, permiten transmitir esa cantidad de bytes con un solo comando.

Si tu aplicación es comercial, te recomiendo estudiar y aplicar CanOpen o DeviceNet, de modo que puedas hacerlo por la vía mas recomendada que dan esos protocolos.

Si lo que quieres hacer es muy customizado, creo que una buena forma es enviarlo en ráfagas de 9 mensajes consecutivos (por el formato del Bus, en algún momento puede entrar un mensaje de otro nodo entre medio), enviando en el primer Byte de cada mensaje el numero de mensaje, para saber donde descargar los datos y cual es su orden y en caso de no recepcionar el orden consecutivo descartar la recepción.
El resto de los bytes sabrás como los ordenas al enviarlos, así que no veo problemas al recepcionarlo.

Si quieres un ejemplo, debería escribirlo y probarlo, ya que no transmito mas de 8 bytes por vez, hasta ahora.
Saludos.

PD: Se puede saber porque debes transmitir tantos bytes??

[arqui_lester]

necesito enviar esa cantidad de bytes por que estoy implentando modbus/CAN y la funcion 16 del modbus soporta el envio de 64 bytes por peticion modbus, estoy con ese problema. envio tramas de 8 bytes las que permite el CAN  ago una secuencia de envio de 8 mensajes de de bytes pero el receptor resive los primeros 2 mensajes  y luego sobre escribe los demas, es decir no los revise, ya tengo funcionando el CAN  y tengo el codigo de las funciones modbus implentado pero me falta afinar ese detalle de la transmision secuencial y recepcion secuencial

[MGLSOFT]

MODBUS sobre CAN ??
Hermosa salsa estas preparando!!!

Sin lugar a dudas Modbus es el protocolo mas usado en el mundo, viejo y persistente, y muy seguro, por eso su supervivencia.
Ha mutado sobre casi todas las redes y medios fisicos conocidos, incluso en Ethernet, como Modbus TCP.
Lo unico que no ha podido hacer es traspasar su condicion de uso como Maestro-Esclavo, ya que aun sobre TCP debe funcionar de esa forma...

El bus CAN es multimaestro y permite mensajeria de cada nodo aun sin solicitud de ningun maestro u otro nodo funcionando como tal...
Porque quieres perder esa particularidad del bus y degradarlo montando Modbus sobre este BUS ???

Alguien te lo ha pedido??
Una exigencia laboral??

Creo que deberias defender un poco mas tu proyecto y ofrecer soluciones mas coherentes y futuristas, como son implementar DeviceNet o CanOpen sobre el Bus Can, ganando en velocidad y potenciando (en vez de perderlas) las particularidades de este bus.
Inclusive en velocidad es difícil ganarle, y como medio físico, probado en el ambiente mas ruidoso del mundo, como es el ambiente interno de los automóviles, para lo cual fue exitosamente desarrollado.

Es mi opinion personal, el Bus sera tuyo y puedes hacer lo que quieras con el.

[arqui_lester]

HOLA QUE TAL
la cosa es que es un proyecto de tesis de la universidad, en el momento que se concibio no se tomo en cuenta ese punto, y en estamos en un punto de no retorno y hay que hacer que funcione por eso estamos ocupando el bus CAN, por el momento en mi pais es el primer proyecto desarrollado. por eso no se ocupo devicenet de allen brandy o canopen que son protocolos de mas alto nivel y te dan mas rendimiento.
el sistema es controlado desde una aplicacion web modbus/tcp a diferentes controladores. estos controladores son configurados con la funcion 16 de modbus por lo que necesito enviar hasta 64 bytes de la peticion. esto es lo que me esta dando problemas el envio de esos 64 bytes.

[MGLSOFT]

Lo veo difícil, al dividirlo en 9 mensajes, usando el primer byte de cada uno como  numerador del mensaje, también estas dividiendo el mensaje original Modbus en 9 partes.
Modbus pide confirmación de la recepción del mensaje OK, donde debes enviar la dirección del esclavo que responde y la cantidad de bytes recibidos, junto con la instrucción realizada.

Vas a tener que implementar una rutina en el esclavo que se encargue de rearmar los mensajes, controlar el cheksum (lo estarías haciendo dos veces, ya que CAN tiene su cheksum), y por ultimo respondiendo.
Casi que tu esclavo y tu maestro estarán dedicados a la comunicación, es posible que no te quede tiempo para realizar otras tareas...

No quiero ser aguafiestas, pero lo veo mal.

[teleko]

Ya terminé mi proyecto, al final he conseguido comunicarme con el bus CAN del coche. El PIC lee los datos de OBD y muestra los PIDS seleccionados por la pantalla LCD.

Tiene 2 modos de funcionamiento, uno conectado al ordenador por puerto serie, y se le envían comandos para transmitir al vehículo y configurar las opciones. El otro modo, es automático cuando no se le envia nada por el puerto serie, comienza a hacer peticiones de los datos del OBD, según el protocolo ISO 15765 (OBD sobre CAN).

En este video se muestra como funciona la placa del montaje.