 |
|
01-09-2012, 04:09 PM
|
|
Member
|
|
Join Date: Jun 2009
Posts: 92
|
|
Re: CAN Bus communication
Quote:
Originally Posted by frodus
either way, it's pretty straightforward.
The STN1110 and ELM327 chips are reasonably priced if you want to go that route, or you can just write your own code to just respond the same way torque/etc need.
Maybe we should post some of this in the torque forum?
|
Just what I need, another forum to waste all my time on.  But I'm definitely curious as to what help they'd be in opening it up a little, or advice they may give on making our stuff OBD2.
|
03-06-2012, 05:23 PM
|
|
Junior Member
|
|
Join Date: Mar 2012
Posts: 2
|
|
Re: CAN Bus communication
Hi guys, have you done any more with this?? I have a fair bit of experience with CAN and OBD2 and may be able to help out a bit.
|
03-07-2012, 01:58 AM
|
 |
Senior Member
|
|
Join Date: May 2011
Location: The great American South/West desert.
Posts: 1,329
|
|
Re: CAN Bus communication
OK......
I just re-read this entire thread.
I have come to realize my original question was quite naive.
CanBus is just a name for an idea to monitor/control machine-to-machine communication and or control.
Every manufacturer uses their own version of the idea. CanBus for an HVAC system may/may not communicate with CanBus from a vehicle system. Even if it did communicate, it may/may not be at the same speed, therefore be of use.
Even if it did communicate and was of the same speed parameter, it may/may not "understand each other.
Even if it did communicate. Even if it was of the same speed parameter. Even if it did "understand" each other. It still might/might not be able to issue two-way commands and just be a read only system.
This brings back memories of 4 track/8 track/casette issue. Then VHS/BetaMax. Then monochrome/VGA/whatever they use now. HD/Blue ray.
Everyone invested in their own Tech. and didnt use that energy to cooperate in developing an industry standard. They just tried to kill off everyone else.
While I understand most of the things said previously, My knowledge ends there.
I agree on a few points:
We need to develop our own "standard" system. It needs to be cheap as possible while still being able to expand to cover most new situations.
I get that Android covers 90% of our needs. It will not do for those wanting a full 100%. {Android might work for mobile systems only though.}
I get that most CanBus has no standard Baud rate and we must be tolerant of that.
I get that most CanBus has its own language. We need to have a way to add modules to suit future additional situations.
{Please forgive my clumsy wording, but it is the best I can do with this subject.}
It sounds like a "Swiss Army Knife" approach.
Miz
__________________
ivanbennett dot com/forum
AC Vehicle Propulsion Study Group
|
03-07-2012, 01:50 PM
|
|
Junior Member
|
|
Join Date: Mar 2012
Posts: 2
|
|
Re: CAN Bus communication
My 2 cents,
I would opt for one of the existing sae standards, thus allowing your can bus diagnostics to be read by any standard obd2 scan tool. Obviously these are mostly emission related an irrelevant in this context, but many others apply to any vehicle. The standard obd messages can be extended with manufacturer specific messages (thats you in this case) such as charge rate, motor temp, etc. The protocol used is normally UDS over CAN (high speed 500k) responding to diagnostic PIDS. If its something that your still interested in doing then let me know and i can help you draw up the details and perhaps put together an example controller to look at.
Also, when CAN is used in an automotive enviroment there are standard baud rates defines by the sae standards, and as the 'manufacturer' in this context, we can decide which speeds to impliment. It would be the Scan tool that needs to be tolerant. Again, as for the spoken language on the bus, there are standards that define this too, and includes diagnostics, module to module comms, module reprogramming etc.
Last edited by Gangsta; 03-07-2012 at 02:01 PM.
|
03-07-2012, 02:16 PM
|
|
Senior Member
|
|
Join Date: Dec 2011
Location: boondock around USA
Posts: 739
|
|
Re: CAN Bus communication
Quote:
Originally Posted by mizlplix
OK......
I just re-read this entire thread.
I have come to realize my original question was quite naive.
CanBus is just a name for an idea to monitor/control machine-to-machine communication and or control.
Every manufacturer uses their own version of the idea. CanBus for an HVAC system may/may not communicate with CanBus from a vehicle system. Even if it did communicate, it may/may not be at the same speed, therefore be of use.
Even if it did communicate and was of the same speed parameter, it may/may not "understand each other.
Even if it did communicate. Even if it was of the same speed parameter. Even if it did "understand" each other. It still might/might not be able to issue two-way commands and just be a read only system.
This brings back memories of 4 track/8 track/casette issue. Then VHS/BetaMax. Then monochrome/VGA/whatever they use now. HD/Blue ray.
Everyone invested in their own Tech. and didnt use that energy to cooperate in developing an industry standard. They just tried to kill off everyone else.
While I understand most of the things said previously, My knowledge ends there.
I agree on a few points:
We need to develop our own "standard" system. It needs to be cheap as possible while still being able to expand to cover most new situations.
I get that Android covers 90% of our needs. It will not do for those wanting a full 100%. {Android might work for mobile systems only though.}
I get that most CanBus has no standard Baud rate and we must be tolerant of that.
I get that most CanBus has its own language. We need to have a way to add modules to suit future additional situations.
{Please forgive my clumsy wording, but it is the best I can do with this subject.}
It sounds like a "Swiss Army Knife" approach.
Miz
|
So I don't have to repeat about the hardware level
http://roadwarrior.free-man.com/can/
the messages can be define as an industries Vocabulary.
So just like the RV industry has a CAN vocabulary,
taking all the EV products that use CAN and have a vocabulary that is defined in one place.
Like this thread.
Addressing the User interface this should be a library of code, C, Java, that developers use to build displays. If developers use Java then it will be easily portable, without change on the PC, Linux, web pages and Android(linux based java) there is a place call GitHub that this repository can be put for all to use.
|
04-02-2012, 04:54 PM
|
|
Senior Member
|
|
Join Date: Dec 2011
Location: boondock around USA
Posts: 739
|
|
Re: CAN Bus communication
for clarification
OBD-II PIDs ( On-board diagnostics Parameter IDs) this is the 11 bit format. it is known as J1979
For canbus, DGN( Data group number ), SPIN(Service Point Number) extends the 11bit to 29 bits and is known as J1939
Both of these are define by a chip that takes care of all the signals between nodes then provide the data in a format that a CPU can process. A cpu can also be programmed to what the chip does, but take away from the CPU to do other things.
The simplistic communication between nodes is “Are you there”, and a reply “Yes I am”. So a CAN can modify how many nodes it has and keep updated.
The next level is :what can you do, and the reply is a list of things the node can do.
So a CAN can learn what a new/upgraded node can do.
Now a node may be attached to many identical things, like a bunch of temperature sensors. So the node will also send how many of each thing it has.
take some development from the RV industry and the Can spec
The olimexino is a good development board. it is about $30.
Though you can use an elm327 and 329 still think using an environment that the is in software is better.
there is plenty of free code th at I have used.
|
04-04-2012, 03:52 PM
|
|
Senior Member
|
|
Join Date: Dec 2011
Location: boondock around USA
Posts: 739
|
|
Re: CAN Bus communication
here are some can bus DGN that can be used. note some wont' be for vehicles.
Code:
#define DATE_TIME_STATUS ((uint32) 0x1FFFF)
#define SET_DATE_TIME_COMMAND ((uint32) 0x1FFFE)
#define DC_SOURCE_STATUS_1 ((uint32) 0x1FFFD)
#define DC_SOURCE_STATUS_2 ((uint32) 0x1FFFC)
#define DC_SOURCE_STATUS_3 ((uint32) 0x1FFFB)
#define COMMUNICATION_STATUS_1 ((uint32) 0x1FFFA)
#define COMMUNICATION_STATUS_2 ((uint32) 0x1FFF9)
#define COMMUNICATION_STATUS_3 ((uint32) 0x1FFF8)
#define WATERHEATER_STATUS ((uint32) 0x1FFF7)
#define WATERHEATER_COMMAND ((uint32) 0x1FFF6)
#define GAS_SENSOR_STATUS ((uint32) 0x1FFF5)
#define CHASSIS_MOBILITY_STATUS ((uint32) 0x1FFF4)
#define CHASSIS_MOBILITY_COMMAND ((uint32) 0x1FFF3)
#define AAS_CONFIG_STATUS ((uint32) 0x1FFF2)
#define AAS_CONFIG_COMMAND ((uint32) 0x1FFF1)
#define AAS_STATUS ((uint32) 0x1FFF0)
#define AAS_SENSOR_STATUS ((uint32) 0x1FFEF)
#define LEVELING_CONTROL_COMMAND ((uint32) 0x1FFEE)
#define LEVELING_CONTROL_STATUS ((uint32) 0x1FFED)
#define LEVELING_JACK_STATUS ((uint32) 0x1FFEC)
#define LEVELING_SENSOR_STATUS ((uint32) 0x1FFEB)
#define HYDRAULIC_PUMP_STATUS ((uint32) 0x1FFEA)
#define LEVELING_AIR_STATUS ((uint32) 0x1FFE9)
#define SLIDE_STATUS ((uint32) 0x1FFE8)
#define SLIDE_COMMAND ((uint32) 0x1FFE7)
#define SLIDE_SENSOR_STATUS ((uint32) 0x1FFE6)
#define SLIDE_MOTOR_STATUS ((uint32) 0x1FFE5)
#define FURNACE_STATUS ((uint32) 0x1FFE4)
#define FURNACE_COMMAND ((uint32) 0x1FFE3)
#define THERMOSTAT_STATUS_1 ((uint32) 0x1FFE2)
#define AIR_CONDITIONER_STATUS ((uint32) 0x1FFE1)
#define AIR_CONDITIONER_COMMAND ((uint32) 0x1FFE0)
#define GENERATOR_AC_STATUS_1 ((uint32) 0x1FFDF)
#define GENERATOR_AC_STATUS_2 ((uint32) 0x1FFDE)
#define GENERATOR_AC_STATUS_3 ((uint32) 0x1FFDD)
#define GENERATOR_STATUS_1 ((uint32) 0x1FFDC)
#define GENERATOR_STATUS_2 ((uint32) 0x1FFDB)
#define GENERATOR_COMMAND ((uint32) 0x1FFDA)
#define GENERATOR_START_CONFIG_STATUS ((uint32) 0x1FFD9)
#define GENERATOR_START_CONFIG_COMMAND ((uint32) 0x1FFD8)
#define INVERTER_AC_STATUS_1 ((uint32) 0x1FFD7)
#define INVERTER_AC_STATUS_2 ((uint32) 0x1FFD6)
#define INVERTER_AC_STATUS_3 ((uint32) 0x1FFD5)
#define INVERTER_STATUS ((uint32) 0x1FFD4)
#define INVERTER_COMMAND ((uint32) 0x1FFD3)
#define INVERTER_CONFIGURATION_STATUS_1 ((uint32) 0x1FFD2)
#define INVERTER_CONFIGURATION_STATUS_2 ((uint32) 0x1FFD1)
#define INVERTER_CONFIGURATION_COMMAND_1 ((uint32) 0x1FFD0)
#define INVERTER_CONFIGURATION_COMMAND_2 ((uint32) 0x1FFCF)
#define INVERTER_STATISTICS_STATUS ((uint32) 0x1FFCE)
#define INVERTER_APS_STATUS ((uint32) 0x1FFCD)
#define INVERTER_DCBUS_STATUS ((uint32) 0x1FFCC)
#define INVERTER_OPS_STATUS ((uint32) 0x1FFCB)
#define CHARGER_AC_STATUS_1 ((uint32) 0x1FFCA)
#define CHARGER_AC_STATUS_2 ((uint32) 0x1FFC9)
#define CHARGER_AC_STATUS_3 ((uint32) 0x1FFC8)
#define CHARGER_STATUS ((uint32) 0x1FFC7)
#define CHARGER_CONFIGURATION_STATUS ((uint32) 0x1FFC6)
#define CHARGER_COMMAND ((uint32) 0x1FFC5)
#define CHARGER_CONFIGURATION_COMMAND ((uint32) 0x1FFC4)
#define CHARGER_STATISTICS_STATUS ((uint32) 0x1FFC3)
#define CHARGER_APS_STATUS ((uint32) 0x1FFC2)
#define CHARGER_DCBUS_STATUS ((uint32) 0x1FFC1)
#define CHARGER_OPS_STATUS ((uint32) 0x1FFC0)
#define AC_LOAD_STATUS ((uint32) 0x1FFBF)
#define AC_LOAD_COMMAND ((uint32) 0x1FFBE)
#define DC_LOAD_STATUS ((uint32) 0x1FFBD)
#define DC_LOAD_COMMAND ((uint32) 0x1FFBC)
#define DC_DIMMER_STATUS_1 ((uint32) 0x1FFBB)
#define DC_DIMMER_STATUS_2 ((uint32) 0x1FFBA)
#define DC_DIMMER_COMMAND ((uint32) 0x1FFB9)
#define DIGITAL_INPUT_STATUS ((uint32) 0x1FFB8)
#define TANK_STATUS ((uint32) 0x1FFB7)
#define TANK_CALIBRATION_COMMAND ((uint32) 0x1FFB6)
#define TANK_GEOMETRY_STATUS ((uint32) 0x1FFB5)
#define TANK_GEOMETRY_COMMAND ((uint32) 0x1FFB4)
#define WATER_PUMP_STATUS ((uint32) 0x1FFB3)
#define WATER_PUMP_COMMAND ((uint32) 0x1FFB2)
#define AUTOFILL_STATUS ((uint32) 0x1FFB1)
#define AUTOFILL_COMMAND ((uint32) 0x1FFB0)
#define WASTEDUMP_STATUS ((uint32) 0x1FFAF)
#define WASTEDUMP_COMMAND ((uint32) 0x1FFAE)
#define ATS_AC_STATUS_1 ((uint32) 0x1FFAD)
#define ATS_AC_STATUS_2 ((uint32) 0x1FFAC)
#define ATS_AC_STATUS_3 ((uint32) 0x1FFAB)
#define ATS_STATUS ((uint32) 0x1FFAA)
#define ATS_COMMAND ((uint32) 0x1FFA9)
#define WEATHER_STATUS_1 ((uint32) 0x1FFA5)
#define WEATHER_STATUS_2 ((uint32) 0x1FFA4)
#define ALTIMETER_STATUS ((uint32) 0x1FFA3)
#define ALTIMETER_COMMAND ((uint32) 0x1FFA2)
#define WEATHER_CALIBRATE_COMMAND ((uint32) 0x1FFA1)
#define COMPASS_BEARING_STATUS ((uint32) 0x1FFA0)
#define COMPASS_CALIBRATE_COMMAND ((uint32) 0x1FF9F)
#define BRIDGE_COMMAND ((uint32) 0x1FF9E)
#define BRIDGE_PGN_LIST ((uint32) 0x1FF9D)
#define THERMOSTAT_AMBIENT_STATUS ((uint32) 0x1FF9C)
#define HEAT_PUMP_STATUS ((uint32) 0x1FF9B)
#define HEAT_PUMP_COMMAND ((uint32) 0x1FF9A)
#define CHARGER_EQUALIZATION_STATUS ((uint32) 0x1FF99)
#define CHARGER_EQUALIZATION_CONFIGURATION_STATUS ((uint32) 0x1FF98)
#define CHARGER_EQUALIZATION_CONFIGURATION_COMMAND ((uint32) 0x1FF97)
#define CHARGER_CONFIGURATION_STATUS_2 ((uint32) 0x1FF96)
#define CHARGER_CONFIGURATION_COMMAND_2 ((uint32) 0x1FF95)
#define GENERATOR_AC_STATUS_4 ((uint32) 0x1FF94)
#define GENERATOR_ACFAULT_CONFIGURATION_STATUS_1 ((uint32) 0x1FF93)
#define GENERATOR_ACFAULT_CONFIGURATION_STATUS_2 ((uint32) 0x1FF92)
#define GENERATOR_ACFAULT_CONFIGURATION_COMMAND_1 ((uint32) 0x1FF91)
#define GENERATOR_ACFAULT_CONFIGURATION_COMMAND_2 ((uint32) 0x1FF90)
#define INVERTER_AC_STATUS_4 ((uint32) 0x1FF8F)
#define INVERTER_ACFAULT_CONFIGURATION_STATUS_1 ((uint32) 0x1FF8E)
#define INVERTER_ACFAULT_CONFIGURATION_STATUS_2 ((uint32) 0x1FF8D)
#define INVERTER_ACFAULT_CONFIGURATION_COMMAND_1 ((uint32) 0x1FF8C)
#define INVERTER_ACFAULT_CONFIGURATION_COMMAND_2 ((uint32) 0x1FF8B)
#define CHARGER_AC_STATUS_4 ((uint32) 0x1FF8A)
#define CHARGER_ACFAULT_CONFIGURATION_STATUS_1 ((uint32) 0x1FF89)
#define CHARGER_ACFAULT_CONFIGURATION_STATUS_2 ((uint32) 0x1FF88)
#define CHARGER_ACFAULT_CONFIGURATION_COMMAND_1 ((uint32) 0x1FF87)
#define CHARGER_ACFAULT_CONFIGURATION_COMMAND_2 ((uint32) 0x1FF86)
#define ATS_AC_STATUS_4 ((uint32) 0x1FF85)
#define ATS_ACFAULT_CONFIGURATION_STATUS_1 ((uint32) 0x1FF84)
#define ATS_ACFAULT_CONFIGURATION_STATUS_2 ((uint32) 0x1FF83)
#define ATS_ACFAULT_CONFIGURATION_COMMAND_1 ((uint32) 0x1FF82)
#define ATS_ACFAULT_CONFIGURATION_COMMAND_2 ((uint32) 0x1FF81)
#define GENERATOR_DEMAND_STATUS ((uint32) 0x1FF80)
#define GENERATOR_DEMAND_COMMAND ((uint32) 0x1FEFF)
#define AGS_CRITERION_STATUS ((uint32) 0x1FEFE)
#define AGS_CRITERION_COMMAND ((uint32) 0x1FEFD)
#define FLOOR_HEAT_STATUS ((uint32) 0x1FEFC)
#define FLOOR_HEAT_COMMAND ((uint32) 0x1FEFB)
#define THERMOSTAT_STATUS_2 ((uint32) 0x1FEFA)
#define THERMOSTAT_COMMAND_1 ((uint32) 0x1FEF9)
#define THERMOSTAT_COMMAND_2 ((uint32) 0x1FEF8)
#define THERMOSTAT_SCHEDULE_STATUS_1 ((uint32) 0x1FEF7)
#define THERMOSTAT_SCHEDULE_STATUS_2 ((uint32) 0x1FEF6)
#define THERMOSTAT_SCHEDULE_COMMAND_1 ((uint32) 0x1FEF5)
#define THERMOSTAT_SCHEDULE_COMMAND_2 ((uint32) 0x1FEF4)
#define AWNING_STATUS ((uint32) 0x1FEF3)
#define AWNING_COMMAND ((uint32) 0x1FEF2)
#define TIRE_RAW_STATUS ((uint32) 0x1FEF1)
#define TIRE_STATUS ((uint32) 0x1FEF0)
#define TIRE_SLOW_LEAK_ALARM ((uint32) 0x1FEEF)
#define TIRE_TEMPERATURE_CONFIGURATION_STATUS ((uint32) 0x1FEEE)
#define TIRE_PRESSURE_CONFIGURATION_STATUS ((uint32) 0x1FEED)
#define TIRE_PRESSURE_CONFIGURATION_COMMAND ((uint32) 0x1FEEC)
#define TIRE_TEMPERATURE_CONFIGURATION_COMMAND ((uint32) 0x1FEEB)
#define TIRE_ID_STATUS ((uint32) 0x1FEEA)
#define TIRE_ID_COMMAND ((uint32) 0x1FEE9)
#define INVERTER_DC_STATUS ((uint32) 0x1FEE8)
#define GENERATOR_DEMAND_CONFIGURATION_STATUS ((uint32) 0x1FEE7)
#define GENERATOR_DEMAND_CONFIGURATION_COMMAND ((uint32) 0x1FEE6)
#define LOCK_STATUS ((uint32) 0x1FEE5)
#define LOCK_COMMAND ((uint32) 0x1FEE4)
#define WINDOW_STATUS ((uint32) 0x1FEE3)
#define WINDOW_COMMAND ((uint32) 0x1FEE2)
#define DC_MOTOR_CONTROL_COMMAND ((uint32) 0x1FEE1)
#define DC_MOTOR_CONTROL_STATUS ((uint32) 0x1FEE0)
#define WINDOW_SHADE_CONTROL_COMMAND ((uint32) 0x1FEDF)
#define WINDOW_SHADE_CONTROL_STATUS ((uint32) 0x1FEDE)
#define AC_LOAD_STATUS_2 ((uint32) 0x1FEDD)
#define DC_LOAD_STATUS_2 ((uint32) 0x1FEDC)
#define DC_DIMMER_COMMAND_3 ((uint32) 0x1FEDB)
#define DC_DIMMER_STATUS_3 ((uint32) 0x1FEDA)
#define GENERIC_INDICATOR_COMMAND ((uint32) 0x1FED9)
#define GENERIC_CONFIGURATION_STATUS ((uint32) 0x1FED8)
#define GENERIC_INDICATOR_STATUS ((uint32) 0x1FED7)
#define GENERAL_RESET ((uint32) 0x17F##)
#define DOWNLOAD ((uint32) 0x17E##)
#define TERMINAL ((uint32) 0x17D##)
#define INSTANCE_ASSIGNMENT ((uint32) 0x17C##)
#define INSTANCE_STATUS ((uint32) 0x17B##)
|
04-05-2012, 01:42 PM
|
|
Senior Member
|
|
Join Date: Nov 2010
Location: Annapolis MD
Posts: 228
|
|
Re: CAN Bus communication
Quote:
Originally Posted by bjfreeman
here are some can bus DGN that can be used. note some wont' be for vehicles.
|
Copying and pasting a list is pretty useless...
The OBD-II Parameters (PIDs) and diagnostic trouble codes (DTCs) are vital to using OBD, but the short description are pretty much useless for implementations. You really need a more complete description. An example is "gas pedal" position reporting. You need to know the meaning of absolute, relative and commanded positions, and what point is considered pedal vs. throttle.
|
04-05-2012, 02:48 PM
|
|
Senior Member
|
|
Join Date: Dec 2011
Location: boondock around USA
Posts: 739
|
|
Re: CAN Bus communication
Quote:
Originally Posted by DJBecker
Copying and pasting a list is pretty useless...
The OBD-II Parameters (PIDs) and diagnostic trouble codes (DTCs) are vital to using OBD, but the short description are pretty much useless for implementations. You really need a more complete description. An example is "gas pedal" position reporting. You need to know the meaning of absolute, relative and commanded positions, and what point is considered pedal vs. throttle.
|
true, however the thread is about Can Bus, not just OBD.
Give me time to get it all posted, unless you wish to contribute,
|
| Thread Tools |
|
|
| Display Modes |
 Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
|
|
|
