Orion Li-Ion Battery Management System http://www.orionbms.com Affordable & Reliable EV Li-Ion BMS Tue, 02 Aug 2016 16:56:19 +0000 en-US hourly 1 Diagnosing CANBUS Communication Problems http://www.orionbms.com/general/diagnosing-canbus-communication-problems/ http://www.orionbms.com/general/diagnosing-canbus-communication-problems/#respond Mon, 07 Mar 2016 17:28:13 +0000 http://www.orionbms.com/?p=2657 Continue reading ]]> CANBUS is a high speed network which requires high quality wiring in order to operate properly. As such, it is sensitive to improper wiring. The majority of CANBUS communication problems are caused by poor wiring, incorrect termination, or the use of multiple frequencies on the same bus. Below are some tips for diagnosing CANBUS communication problems:

  • There must be exactly two (2) termination resistors of 120 ohms each at the physical ends of the CANBUS. These resistors may be external to the device, but some devices such as the Orion BMS (CAN1 only) or Orion Jr. BMS have termination resistors installed inside the device (may be ordered without). Correct termination resistance can be verified by measuring the resistance between CAN-High and CAN-Low with a multimeter. In order to do this, it is essential that all devices on the network are completely unpowered (this will not work if any device on the network has power). It should read approximately 60 Ohms. There must be exactly 2 termination resistors (120 Ohms each) on the network. Always use termination resistors. Even if the network appears to operate without termination resistors in quiet environments, it may not operate correctly when noise is introduced!
  • Both termination resistors must be on the physical ends of the CANBUS (ends of the main trunk). If they are not at the physical ends of the network, then the effectiveness of the termination filtering resistors will be negated.
  • The network must be shaped like a tree. The main length of the CANBUS is like the trunk of the tree and there can be small branches that come off the main trunk. The maximum length of the trunk and branches depends on the baud-rate running, but is typically limited to no more than 2 feet (0.6 meters)

diagram 1 with check
diagram 2 with x

  • All CANBUS wire must be twisted pair cable, even short lengths (longer than 1 inch / 2 cm). The twisted pair wire is an essential part of how the differential mode filtering works on CANBUS, and without it the signal can be easily distorted.
  • CAN-High and CAN-Low wires must be the same length. Differences in length between CAN-High and CAN-Low wires can cause distortion due to common mode filtering.
  • Ensure that CAN-High and CAN-Low are connected in the correct order. If CAN-High and CAN-Low are backwards on any device on the network, it will obliterate or severely distort traffic and make communication impossible.
  • Ensure CAN-High and CAN-Low are not shorted together or shorted to ground or V+. Test to make sure there is no electrical conductivity between CAN-High and ground or CAN-Low and ground (this can happen if one of the wires gets shorted to the shield or gets pinched or sliced by a metal enclosure).
  • All devices on the CANBUS network must be running the same baud-rate. If there are devices running multiple different baud-rates then this may obliterate all CANBUS traffic. If the baud rate on an Orion BMS product must be changed, disconnect the device from the network, and update the baud rate with just the BMS product and the CANdapter connected. If the baud rate is changed on an Orion BMS product, the Orion BMS product must be power cycled for the new baud rate to take effect.
  • All devices on the network must share the same ground. Different ground potentials between devices will lead to common mode voltages forming on the CANBUS. These will distort communication signals and can lead to damaged equipment and may also pose a safety hazard. If the same grounds cannot be used, an external CANBUS isolator may be required to provide galvanic isolation to disrupt ground loops.
  • If the CANBUS wire being used is a shielded cable, the shield should be grounded on one end only. If both ends of the CANBUS wire shield is grounded ground loops may be formed which may cause interference.
  • Ensure that all CANBUS wiring is solidly connected. CANBUS wire junctions must be soldered together or securely spliced. Junctions may NOT simply be twisted together or held together with wire nuts or friction. Do not use terminal blocks, phone cable junction blocks, or other signal processing blocks. These can distort CANBUS communication signals.
  • When stripping the CANBUS wires back, it can be easy to accidentally pierce the insulation of the CAN-High or CAN-Low wires. Inspect any joint or section of wire where the outer CANBUS sleeve has been stripped back to ensure that the CAN wires were not inadvertently damaged as well.
  • Whenever possible, route CANBUS wires away from noisy circuits. Do not twist CANBUS wires with other wires.

 

]]>
http://www.orionbms.com/general/diagnosing-canbus-communication-problems/feed/ 0
No cell voltages appear (Orion Jr. BMS) http://www.orionbms.com/troubleshooting/no-cell-voltages-appear-orion-jr-bms/ http://www.orionbms.com/troubleshooting/no-cell-voltages-appear-orion-jr-bms/#respond Thu, 03 Mar 2016 18:05:21 +0000 http://www.orionbms.com/?p=2654 Continue reading ]]> Common Causes:
  • Incorrect Cell Population Settings
  • BMS is configured with default settings (default settings will show no cell voltages).
  • Cell wiring harnesses not connected to the BMS
  • Cell tap wiring error
  • Internal damage to the BMS

Note: If the BMS has been damaged by previous wiring errors, do not continue to use the BMS. Contact Ewert Energy for evaluation and repair options.

Note: If the “Live Cell Voltages” tab in the BMS utility is grayed out (unable to be clicked), the utility needs to connect to the BMS (press the “Connect to BMS” button or select “Connect to BMS” from the File menu). For help troubleshooting connection problems, see the the troubleshooting guide here.

 

Resolving the issue:

Step 1. Ensure that the LED on the BMS is not flashing red rapidly.

If the LED is rapidly flashing red, immediately disconnect the cell tap connector from the BMS, as this indicates that the unit may be getting damaged from incorrect wiring.

Step 2. Verify that the cell tap wiring harnesses are connected to the BMS.

The cell voltage tap connector must be connected to the BMS to be able to measure cell voltages.

Step 3. Ensure that a settings profile has been uploaded to the BMS.

Until the Orion Jr. BMS has been programmed using the PC software, the BMS will assume no cells are connected. If no profile has been uploaded to the BMS, please create a settings profile and upload the settings to the BMS. Follow the steps in the “Profile Setup Wizard” to generate and upload a basic profile. Reset the power on the BMS and check cell voltages again. After settings have been transmitted to the BMS, we recommend downloading the settings profile from the BMS unit by pressing the “Receive Current Profile From BMS” button in the Orion Jr BMS utility. This will ensure that the exact settings on the BMS are the ones being viewed (as in Step 4 below).

Step 4. Verify that cells have been properly populated.

Download the settings profile from the BMS unit by pressing the “Receive Current Profile From BMS” button in the Orion Jr BMS utility. This will ensure that the exact settings on the BMS are the ones being viewed. Next, under the “Cell Settings” tab, click the “Configure Which Cells Are Connected (Populated)” button. Ensure that cells which are connected have a check in the “Populated” box. If changes need to be made, the profile will need to be sent to the BMS by clicking the “Send Profile Changes to BMS” button.

Step 5. On the same Cell Populations Settings dialog, look at the “Current Voltage” column.

If cell voltages appear correctly here, but not on the live cell data tab, the problem will be a configuration issue. If the voltages also appear as 0 volts here, the issue is likely in hardware.

Step 6. Measure the actual voltage of the cells and the battery pack.

Using a multimeter, measure individual cell voltages and the total pack voltage of the actual pack to ensure proper voltages. If cells are reading 0 volts because they actually have become fully discharged, consult with the cell manufacturer about whether it is safe to charge them back up. Many lithium cells cannot be charged safely once they have been over-discharged.

Step 7. Test the cell tap wiring using either a multimeter or the cell tap validation tool.

If using the tap validation tool, connect the tool to the wiring harness and ensure that the tool finds the correct number of cells and that no “X” marks are present. If using a multi meter, carefully place the multimeter black probe onto the negative terminal of the most negative cell in the pack. Then, being very careful not to arc pins, measure the voltages of the individual pins on the cell tap connector. Start with cell 1 – (black wire). This wire should read 0 volts. Then measure the voltage of cell 1+ – this should read the voltage of the first cell. Then proceed to cell 2 which should read the voltage of cell 1 + cell 2 and so forth.

Hint: While there are other possibilities, the most likely wiring issue to result in all cells reading 0 volts is if the harness has been wired backwards starting with the most positive cell rather than the most negative cell first.

The cell tap validation tool can be rented by the week (US only) or purchased. Rentals can be made here.

Step 8. Check the BMS’s total pack voltage measurement.

The total pack voltage is sensed differently than the individual cell voltages. Checking the total pack voltage value and comparing it to the voltage measured with a multi-meter may yield clues if there is a wiring issue. Please include this information if contacting Ewert Energy.

Step 9. Try using a different BMS unit (if available).

If possible, attempt to swap out the BMS with another working unit. If the problem remains even after switching the BMS unit, the problem is very likely with the cell tap wiring. If the problem is resolved by changing the BMS unit, it is likely that there is an internal fuse that has blown inside the BMS unit or that there is another issue with the unit. Blown fuses most commonly result from previous incorrect wiring or if the battery pack was altered while the BMS was still connected to it. Information on why internal fuses on the BMS may blow can be found here. If this is the case, proceed to contact Ewert Energy to evaluate / repair the unit.

Step 9. Contact Ewert Energy for an evaluation of the BMS unit as there may be internal damage or another fault.

]]>
http://www.orionbms.com/troubleshooting/no-cell-voltages-appear-orion-jr-bms/feed/ 0
Problems connecting to the Orion Jr. BMS unit via PC software http://www.orionbms.com/troubleshooting/problems-connecting-to-the-orion-jr-bms-unit-via-pc-software/ http://www.orionbms.com/troubleshooting/problems-connecting-to-the-orion-jr-bms-unit-via-pc-software/#respond Thu, 03 Mar 2016 16:48:56 +0000 http://www.orionbms.com/?p=2648 Continue reading ]]> This guide is for the Orion Jr. BMS (plastic unit for 16 cells), pictured below. IIf you have a metal standard Orion BMS unit, click here for troubleshooting steps.

orionjr-scaled
Diagnosing communication problems can be frustrating since there are many possible causes, and communication either works or doesn’t work. The following steps resolve most communications problems. Please attempt the following steps before contacting Ewert Energy for support.

 

Resolving the issue:

Step 1. Ensure that the BMS has power.

This can be determined by simply looking at the LED on the BMS unit. If the LED is solid red or solid green, the BMS has power and is ready for communication (if the LED is rapidly flashing red, disconnect the cell taps from the BMS immediately). If the LED is not lit, check the CHARGE power (Main I/O pin 4) or READY power pin (Main I/O pin 2) to ensure power is present. Ground must be provided on pin 6. Use a multimeter to check the voltage between the power pin and the ground pin and ensure the voltage is between 9v and 60v. If power is present, and the LED is not lit, the unit may need to be sent to Ewert Energy for evaluation / repair.

Step 2. Ensure that you are using the correct BMS utility.

The Orion Jr. BMS utility must be used to connect to the Orion Jr. BMS unit. Please ensure that you are not inadvertently using the standard Orion BMS utility. The picture of the BMS unit in the utility should match the unit being connected to. If the wrong utility is being used, download the correct utility from <here>.

From this point, there are 2 methods to connect to the Orion Jr. BMS – via CANBUS (CAN-enabled units only) or via the RS-232 serial port. Please select your method below:

 

Via RS-232

Step 1. Ensure that the serial device shows up in the BMS utility. If the utility says “None Found” for the Selected Adapter, the drivers may not be installed correctly.

Step 2. Select the “List all available serial ports” checkbox, and try each individual serial interface in case the utility was not able to identify which serial port was being used.

Step 3. If using a serial cable to connect to the Orion Jr. BMS, ensure that the cable is actually a straight through cable.

The minimum required pin out can be found in the Orion Jr. BMS wiring manual found here.

Note: A null modem cable will not work, and some cables sold and labeled as “straight through” may not meet the pin out requirements. We recommend using a continuity tester to determine if the cable meets the necessary pin requirements for use with the Orion Jr. BMS. For best results, connect a USB to serial adapter directly to the Orion Jr. BMS unit.

Note: The CANdapter does not function as an RS-232 adapter and cannot be connected to the DB9 on the Orion Jr. BMS.

Note: The Orion Jr. BMS requires the use of the RTS pin in order to provide operating voltage to the serial port. It is possible that some adapters may not provide sufficient power.

Step 4. Try using another USB to serial adapter.

Step 5. Try using another computer.

 

Via CANBUS

Step 1. Check the unit for compatibility.

Only CAN-enabled Orion Jr. BMS units support a connection via CANBUS (part numbers ORION16C)

Only BMS units with firmware 1.5.0 or newer can connect with the Orion Jr. BMS utility. All CAN-enabled revision C units are capable of CANBUS connections. Revision A and B units shipped with an older version of firmware that does not support connecting to the BMS utility via CANBUS and cannot communicate via CANBUS unless the firmware has been updated.

Please note: Firmware updates, should they be necessary, can only be performed via the RS-232 serial port on the Orion Jr. BMS, regardless of the firmware version or the hardware revision.

Step 2. Ensure the BMS is connected to the PC using the CANdapter by Ewert Energy Systems (only for connecting via CANBUS)

The BMS can only be connected to the computer using the Ewert Energy Systems CANdapter. Other CAN to USB adapters are not compatible. The CANdapter can be purchased here.

Step 3. Ensure that CANdapter and hardware driver are operating correctly.

If the “Connect to BMS” dialog says “None Found,” check the following (otherwise skip to step 5).

1) The CANdapter might not be connected to the computer via USB. To make sure that the CANdapter is connected, disconnect it and then plug it back in and look for three rapid flashes of both the red and green CANdapter lights. If the lights do not flash, try using a different USB port or cable. If the problem cannot be resolved, try using a different computer. If the LEDs still do not flash when the CANdapter USB port is connected, even after using a different cable and computer, there may be a problem with the CANdapter.

2) The CANdapter driver may not be installed or may not be working correctly. Most computers will come with the driver pre-loaded, but some need the driver manually installed. The driver can be downloaded from http://www.ewertenergy.com/products/candapter/downloads/candapter_driver.exe.

Step 4. Ensure that you are connecting the correct pins to the CANdapter and to the Orion Jr. BMS. The CANdapter uses pins 3 and 5, which differs from some other CAN to USB adapters. CAN High (pin 3 on the CANdapter) must be wired into pin 20 on the Orion Jr. BMS. CAN Low (CANdapter pin 5) must be wired into pin 19 on the Orion Jr. BMS. Ensure that the CANdapter is not connected into the DB-9 connector on the BMS, as this port is for use only with the RS-232 serial interface.

Step 5. Verify the correct baud rates.

The Orion Jr. BMS and CANdapter can operate at 125kBps, 250kBps, 500kBps or 1000kBps. The BMS units are shipped operating at 500Kbps by default. However, the baud rate setting on the BMS can be changed. The baud rate of the CANdapter and the BMS must match for successful communication. Important: All devices on a CANBUS MUST communicate at the same baud rate. If any device(s) on the CANBUS communicate at different speeds, the bus will become garbled and completely unusable for all devices on the bus. It may be useful to attempt to connect to the Orion Jr. BMS unit at all the different baud rate settings in the event that the baud rate is set differently than expected. If it is necessary to change the baud rate of the Orion Jr. BMS unit, it will need to be disconnected from other CANBUS nodes and programmed directly. Note: After baud rates are changed in the settings, the Orion Jr. BMS must be power cycled for the new baud rate to take effect (the same can be accomplished by connecting to the BMS and selecting File → Restart BMS in the Orion Jr. BMS utility).

Step 6. When trying to connect to the Orion BMS, check the status of the LEDs on the CANdapter.

If the CANdapter’s red LED comes on and stays on when trying to connect, there are errors present on the CANBUS which can indicate CAN high and CAN low are backwards, the bus is shorted, there are devices operating at different CAN frequencies, there is improper termination, a node on the CANBUS has malfunctioned, or that there are other wiring problems. If the CANdapter LEDs don’t come on, verify that the CANdapter is properly connected. The green and red LEDs should flash a few times when the CANdapter is first connected.

Step 7. Ensure proper wiring of the CANBUS, including proper termination of the bus.

Many problems with CAN communication turn out to be wiring issues on the CANBUS, many of which visually appear to be correct.

First, check for proper termination. The CANBUS will not operate correctly unless exactly two (2) 120 ohm resistors are installed at the 2 physical ends of the CANBUS (one of which is located physically inside the Orion Jr. BMS, unless the Orion Jr. BMS was special ordered without this termination resistor installed). To test for proper termination, completely remove all power from all devices on the CANBUS and measure the resistance between CAN High and CAN Low. It should read 60 ohms (Two 120 ohm resistors in parallel will result in 60 ohms of total resistance). If the resistance readings are not 60 ohms, something is wrong with the termination. A value lower than 60 may indicate that there are too many termination resistors. A value of 120 ohms indicates only one termination resistor is present.

Note: The Orion Jr. BMS ships standard with a termination resistor on the CAN interface. The unit can be special ordered with different configurations.

Important: Exactly one CAN 120 ohm termination resistor MUST be at each physical end of the bus to work properly (total of two resistors)! We receive many inquiries from customers who assume it will work properly without resistors, work with only one or work with the resistors in a different physical location and find that they are unable to communicate with the BMS or find that it only works intermittently. If you have the incorrect number of termination resistors, please add proper termination before inquiring for help, as this solves a large number of communication issues.

The physical layout of a CANBUS matters significantly as this is a high speed communication bus. Wire must be twisted pair cable, with no sections larger than about 1 inch (2cm) of untwisted cable (shielded twisted pair is preferred). Wires must be firmly connected (do not press wires together or use breadboards or phone blocks). Ensure that taps off the main trunk of the bus are kept to 2 feet or less (see the wiring manual for more information about CANBUS wiring). Do not connect CANBUS nodes in a star configuration. Note that simply because there is continuity between the pins does not guarantee that the cable is of sufficient quality for high speed communication.

More tips for locating and resolving CANBUS wiring problems can be found <here>. It may be helpful to create a wiring harness with only CANBUS and power for the BMS to help in diagnosing communication issues.

Step 7. Remove all other devices from the CANBUS and attempt to communicate only with the Orion Jr. BMS.

Some other devices which poll data from the BMS over OBD-II, such as smartphone apps like Torque or other scan tools, can interfere with the BMS’s communication with the utility. Deactivate or remove any device on the CANBUS that might poll data via OBD-II while connecting to the BMS. If removing any devices, ensure that the CAN termination resistors are still in the proper locations as removing a device can alter the termination locations (see step 7).

Step 8. Restart the BMS utility program, power cycle the BMS, and try again in case something had locked up.

Step 9. Attempt to use the RS-232 serial interface.

It is possible that the CANBUS interface may have an issue or may have been damaged. If this is the case, it is sometimes useful to attempt to connect to the RS-232 interface to program the unit.

 

If all steps above have failed, there may be an issue with the BMS unit. Ewert Energy can test the unit or make repairs if necessary.

]]>
http://www.orionbms.com/troubleshooting/problems-connecting-to-the-orion-jr-bms-unit-via-pc-software/feed/ 0
P0A0D – Cell Voltage Over 5 Volts (Orion Jr. Revision C only) http://www.orionbms.com/troubleshooting/p0a0d-cell-voltage-over-5-volts-orion-jr-revision-c-only/ http://www.orionbms.com/troubleshooting/p0a0d-cell-voltage-over-5-volts-orion-jr-revision-c-only/#respond Thu, 20 Aug 2015 16:31:25 +0000 http://www.orionbms.com/?p=2620 Continue reading ]]> The cell tap harness should be immediately disconnected from the BMS if this fault code is set. Leaving the harness connected to the BMS is likely to cause damage to the BMS and may indicate that a cell is severely overcharged.  Incorrect wiring may pose a fire and/or personal safety hazard or may lead to cell damage.  Never continue to use a damaged BMS unit!

This fault code is triggered if the voltage of an individual cell (as measured by the BMS) exceeds 5.0 volts.  This fault code will only trigger after a number of samplings over the period of 1 minute to prevent false positives.  If this fault triggers, it will cause the BMS to enter into a voltage failsafe condition disabling all charge and discharge.

This fault can be caused by incorrect cell tap wiring, a loose or disconnected cell tap, a blown fuse inside the BMS, a high resistance or loose busbar, a cell which is actually over 5 volts, or from internal damage to the BMS unit due to previous wiring faults.  This fault code should always be immediately investigated as the BMS can be damaged by cell voltage readings above 5.0v and as there may be other dangerous conditions such as over-charged cells.

The Status LED on the BMS will rapidly flash red when this fault code is present to alert the operator to disconnect the BMS immediately.

Note:  Cells which have been over-charged or over-discharged may not be safe to use even after bringing the voltage into a correct range.  A cell which has previously been over-charged or over-discharged at any time may develop internal damage, compromising the safety of the cell.  Always consult the cell manufacturer for advice on whether a cell can be safely used after an over-charge or over-discharge event.

]]>
http://www.orionbms.com/troubleshooting/p0a0d-cell-voltage-over-5-volts-orion-jr-revision-c-only/feed/ 0
Interfacing with Thunderstruck TSM2500 Chargers http://www.orionbms.com/charger-integration/interfacing-tsm2500-chargers/ http://www.orionbms.com/charger-integration/interfacing-tsm2500-chargers/#respond Thu, 09 Jul 2015 21:49:13 +0000 http://www.orionbms.com/?p=2578 Continue reading ]]> Disclaimer: The following information is provided as a guide for integrating the Orion BMS with the Thunderstruck TSM2500 chargers. While the information here is believed to be correct, it is the user’s responsibility to verify all aspects of the end application and the suitability of the following. Ewert Energy has no affiliation with Thunderstruck and provides this information for informational purposes only and is not responsible for changes in specifications made by the manufacturer. Consult the full user manuals for both products for more information.

The TSM2500 chargers must be controlled via the CANBUS interface to operate.

Ordering the charger

When ordering the TSM2500charger, ensure that the correct voltage range is ordered. The TSM2500 chargers only obey the current limits from the BMS if they are used in the correct voltage range! TSM2500 Chargers must be properly cooled.

Interfacing with the charger

Interfacing the TSM2500 charger to the Orion BMS is primarily done through the CANBUS. An optional analog safety shutoff can be added if desired. The following diagram shows the standard configuration.

CAN_Charger_w_fuses

In this diagram, the CAN connection on the TSM2500 charger is connected to either the CAN1 or CAN2 interface on the Orion BMS. A CANBUS requires exactly two 120 ohm termination resistors at the physical ends of the BUS. Unless the Orion BMS was special ordered with a different configuration, the Orion BMS has an internal termination resistor on the CAN1 interface and no termination resistor on the CAN2 interface. At the time of this writing, the TSM2500 charger does not have an internal termination resistor. Please see the wiring manual for more information about proper termination of the CAN bus and for wire length limits for CAN nodes. The TSM2500 charger may be connected to either of the CAN interfaces on the Orion BMS (CAN1 or CAN2.) The TSM2500 charger comes configured by default to operate at the 250Kbps baud rate. Either CAN interface on the Orion BMS can be changed to operate at different baud rates baud rate. All devices on a CAN bus must operate at the same frequency, so if the BMS is integrating with other devices requiring a different frequency it may be necessary to put the TSM2500 charger on one a different interface from the other devices on the other interface to accommodate both frequencies.

The pinout for the CAN interface connector is as follows:

  • Green/White – CAN High
  • Blue/White – CAN Low
  • Pink – Ignore
  • Green/Yellow – Ignore

Please see the TSM2500 installation manual for details on the specific connectors and pinouts provided by the charger.

It is recommended that an analog (secondary) shutoff for the charger be provided by adding an AC relay. While CAN is itself a robust protocol, it is still a digital protocol which can be susceptible to errors and bus lockups. An analog backup can turn off the charger even if communication errors are present on the CAN bus such that the batteries are kept in a safe state. The only method of analog backup for this version of the charger is interrupting the AC power to the charger.

The charger is primarily controlled using the CAN interface. An optional relay (RELAY2) on the AC power source to the charger serves as a backup to ensure the charger can be shutoff in all situations. Because the TSM2500 chargers can be used on split phase connections (standard residential 240V AC), both AC “hots” must be interrupted using a double pole relay. The relay coil must be less than 100mA for BMS revisions B & C or less than 175mA for revisions D & E. We recommend over-sizing the relay to ensure it can properly handle the AC current. It is up to the user to verify that the relay used is a suitable relay for the application and that the relay meets any necessary specifications.

The Orion BMS utility has built in support for the TSM2500 charger CAN protocol, though it needs to be enabled in the profile settings for it to be activated.

Steps for configuring the Orion BMS to communicate with the TSM2500 Charger:

1.) Open the Orion BMS software utility and load the appropriate profile into the editor by either downloading the existing settings from the Orion BMS (“Receive Current Profile From BMS”) or by opening a profile previously saved to disk.

2.) On the “Battery Profile” tab, select the “CANBUS Settings” tab and select the checkbox next to “Thunderstruck TSM2500 Charger” in the dialog at the bottom (NOTE: If TSM2500 Charger is not an option, update the BMS utility to the latest version by going to ‘Help -> Check For Utility Updates Now’). Enabling this checkbox will popup a dialog that explains changes made to the profile and ask for confirmation. Click OK after reading.

3.) Manually ensure the proper baud rate for the CAN interface connected to the TSM2500 charger. This can be verified on the “CANBUS Settings” tab and select the proper baud-rate for the CANBUS interface that the TSM2500 Charger is connected to (usually 250Kbps). Note: If changing the baud rate, ensure that all devices on the selected CANBUS interface operate at the same speed. CANBUS baud rate changes only take effect when the BMS is reset or power cycled. If the baud rate is changed for the interface connected to the CANdapter, the baud rate will need to be changed when attempting to connect to the Orion BMS after it is reset.

4.) After verifying all profile settings, upload the new changed settings to the BMS.

The TSM2500 charger setup should be thoroughly tested before being left alone to ensure that the CANBUS control is working properly.

TSM2500 Specific Troubleshooting:

If the charger does not charge when connected to the Orion BMS:

  1. Ensure that the BMS is calling for charge. Connect to the Orion BMS using the BMS utility and monitor the charge current limit (CCL) to ensure that the BMS is allowing charge. Certain error codes on the BMS will prohibit charging! If error codes are present, look up the codes in the troubleshooting guide to troubleshoot these first. The troubleshooting guide is available on the Downloads Page.
  2. Ensure that the BMS is able to communicate with the charger via CANBUS. With the CANdapter connected to the same CAN interface as the TSM2500 charger, open the Orion BMS utility, select the “3rd Party Data” tab at the top. Select the “Thunderstruck TSM2500 Charger” from the drop down menu and click “Connect to device”. If the CANBUS is operating correctly, data will show up from the charger such as AC voltage. If this data is not present, the charger is either off or there may be a CAN wiring issue preventing the charger from communicating.

Please see the troubleshooting guide for more information which is available on the Downloads Page.

Important: After making any changes to the charger configuration it is very important to test the setup while closely monitoring the battery pack to ensure that the charger turns off properly at the correct time.

]]>
http://www.orionbms.com/charger-integration/interfacing-tsm2500-chargers/feed/ 0
Retrieving Data With 3rd Party Devices http://www.orionbms.com/general/retrieving-data-obd2-canbus/ http://www.orionbms.com/general/retrieving-data-obd2-canbus/#respond Thu, 09 Jul 2015 17:03:13 +0000 http://www.orionbms.com/?p=2586 Continue reading ]]> There are two distinct methods for retrieving data digitally from the Orion BMS / Orion Jr.: Regularly transmitted CANBUS messages and active data polling (sometimes referred to as on demand polling).

 

Regularly Transmitted CANBUS Messages

Using regularly transmitted CANBUS messages is the broadest and most useful method for getting data out of the BMS in a reliable and consistent manner. Both the Orion BMS and Orion Jr. provide a number of programmable CANBUS messages that can be configured to transmit specific data values at set intervals. Because many CANBUS protocols are inherently complex, the Orion BMS and Orion Jr. utilities provide a significant level of customization to the user including the following items: Interface baud-rate (125Kbps, 250Kbps, 500Kbps, 1000Kbps), Message ID (both Extended and Standard ID), Message length, Message contents (including complete individual byte contents, byte order, bit order, custom arithmetic scaling, offset, max / min values), and Message frequency.

This method is also the simplest to implement because it doesn’t require messages to be sent to the BMS to initiate the data transmission (data transmission of messages occurs automatically after a programmable amount of time has transpired). These messages can be passively received by external nodes and devices and processed accordingly.

In addition to these customizable messages, both the Orion BMS and Orion Jr. provide a battery cell broadcast message (which can be enabled on the “CANBUS Settings” section of the BMS profile), which allows the BMS to automatically push the active cell related data to the CANBUS. This can be useful for diagnostics and debugging where automatic cell voltage publishing is desired.

For details on the regularly transmitted CANBUS message functionality, please see the “Edit CANBUS Messages” dialog under the “CANBUS Settings” section of the BMS Utility (both for the Orion BMS and the Orion Jr.).

Active Data Polling (OBD2)

Some applications only require on demand data access under certain conditions or in certain circumstances, or they require certain data to be transferred that would not be normally transmitted using regularly transmitted messages. To address this need, the Orion BMS implements the On Board Diagnostic Protocol (OBD2) found on modern vehicles. The OBD2 protocol provides a framework for actively requesting data from the BMS, viewing and clearing diagnostic trouble codes (DTCs) and other diagnostic functions.

For a complete description of how the OBD2 diagnostic protocol operates, please see the following regulatory documents:

SAE J1979 (this defines the core OBD2 protocol)

SAE J2190 (this defines several extended modes used by the OrionBMS, specifically mode $22)

ISO 15765 (this defines how large messages are handled by multiple CANBUS messages)

This application note is NOT intended to summarize the entire contents of the above documents. It is merely to provide a starting point for interface development or to provide examples of common tasks. More complex operations may require purchasing and reviewing the above documents.

 

OBD2 Basics

Physical Network Concept

An OBD2 network is comprised of multiple “nodes” which have a unique ID (referred to hereafter as the OBD2 ECU ID, or ECU ID for short).

Because each node has a unique ECU ID they can be individually addressed. This allows a diagnostic utility or device to be able to request specific information from one ECU at a time. Each node MUST have a unique ID, otherwise two nodes may fight each other to reply to requests. When selecting an OBD2 ECU ID for the Orion BMS, there must not be another node on the network with the same ECU ID.

 

Uses For The OBD2 Protocol

The Orion BMS uses the OBD2 protocol for the following functions:

  • Actively requesting live data from the BMS (real-time state of charge, pack voltage, cell voltages, etc).
  • Viewing and clearing diagnostic trouble codes (DTCs).
  • Retrieving stored diagnostic freeze frame data.

The OBD2 diagnostic protocol is great to use for on-the-fly data acquisition where the type of data needed may not be known ahead of time or may change significantly based on the application (e.g. displaying large amounts of data or different types of data depending on which display screen is being selected). It does have some drawbacks though:

  • Only 1 device may be polling data from any ECU node at once via the OBD2 protocol. If multiple devices are polling OBD2 data from a single node the traffic from the two may get mixed up and a data collision may occur. The Orion BMS utility uses the OBD2 protocol to view data from the BMS and configure it. Third party OBD2 devices may need to be disconnected or powered down for the BMS utility to connect properly.
  • There are no sanity checks or checksums on the OBD2 responses. This means that it’s not possible to guarantee that the received data is uncorrupted or valid. Noise and EMI can alter received data which can make this an unreliable link. For this reason, we do not recommend using the OBD2 polling protocol for application control or high reliability messages. For high reliability messaging or control messaging please see the “Custom CANBUS Message” section for how to configure the BMS to automatically transmit customized data at regular intervals.
  • Data requested via OBD2 is inherently slower than data collected by the regularly transmitted CANBUS messages from the BMS. Since the originating device must issue a “request”, wait for the BMS to acknowledge the request, and then wait for the response to be sent back, there is a fairly significant latency introduced. If high speed data transfer is required, the “Custom CANBUS Message” feature should be used to transfer data instead.

 

Anatomy of an OBD2 Message

A simple OBD2 message has the following format:

(Target ECU ID) (Message Length) (Message Mode) (Message PID) (Message Payload)

 

Target ECU ID: This is the OBD2 ECU ID of the target device. The default value for this on the Orion BMS is 0x7E3, but this can be changed in the profile settings.

Message Length: This is the total length (in bytes) of the message to be transmitted. This length includes the mode, the PID and the entire payload. It does NOT include the ECU ID.

Message Mode: This is the OBD2 mode that the message is being sent on. Different modes have different functions (e.g. Mode $22 is used to request live data from the BMS, mode $3 is used to request current fault codes from the BMS, mode $4 is used to clear fault codes, etc). These modes are defined in the SAE 1972 and SAE 2190 documents.

Message PID: This is specific data that the message is trying to retrieve. It is essentially a qualifier for the purpose of the message. For example, when requesting data via mode $22 the PID is used to specify which data parameter is being asked for (e.g. whether we are requesting battery state of charge or battery voltage). The PID may be 1 or 2 bytes depending on the mode (e.g. in mode $22 the PID is always 2 bytes, but in other modes it may be 1 byte).

Message Payload: This is the remainder of the data being sent. Typically this is blank when data is being requested (such as through mode $22), but if data is being sent to the BMS then this may contain data.

Here is an example of an OBD2 message that requests the battery state of charge from the BMS. All the numbers in this example are expressed in HEXADECIMAL format for simplicity.

7E3 04 22 F00F
ID LEN MODE PID FOR SOC

NOTE: All the spaces between the fields above should be removed. The spaces are inserted for illustrative purposes only.

OBD2 Message Reception

 

When a message is transmitted to an OBD2 node, that node needs a way to indicate to the requesting device that it successfully received the request and is sending the requested data back to it. For this reason a response is sent from the receiving ECU back to the originating device.

The target node makes the following changes to the message request before sending it back:

  • It will add 0x8 to the ECU ID to indicate it is responding BACK to the requesting device.
  • It will add 0x40 to the requested MODE to indicate which request it is responding to. This allows for the originating device to differentiate between multiple responses.

NOTE: The device initiating the OBD2 requests should wait for a response back before issuing another request. If multiple requests are received at once (or if the requesting device does not wait for a response before issuing another request) then one or more of the requests may be rejected.

 

Here is an example of an OBD2 transaction using the SOC example above. All numbers are expressed in HEXADECIMAL format.

Transmit Request To BMS:

7E3 04 22 F00F
ID LEN MODE PID FOR SOC

 

Response From BMS:

7EB 05 62 F00F 0064
ID+8 LEN MODE+0x40 SOC PID SOC VALUE

 

NOTE: In this particular instance, the SOC value received is actually SOC * 2 since it’s in 0.5% increments. Divide by 2 to get the actual value (this does not apply to all values, please see the OBD2 PID list for the default unit scalings).

NOTE: For a list of supported PIDs, please see the official OBD2 PID list:

http://www.orionbms.com/downloads/misc/orionbms_obd2_pids.pdf

 

Interfacing With The Standard Orion BMS (CANBUS)

Device Basics

The standard Orion BMS implements OBD2 via CANBUS. This means that the BMS uses the CANBUS protocol as the low level transport mechanism (meaning CANBUS messages are used to transfer the data to and from the BMS).

CANBUS has a couple extra steps that must be taken when using it with OBD2. First, every CANBUS message has an additional length field (this is different from the OBD2 length field and represents the length of the actual CANBUS message being sent). Fortunately this is very simple in OBD2 as the CANBUS length value will always be 8.

An example OBD2 exchange over CANBUS might look something like this:

CANBUS message request from an external device:

0x7E3 8 04 22 F00F 00 00 00 00
CAN ID CAN LEN OBD2 LEN MOD SOC PID UNUSED PADDING

 

CANBUS message response from the BMS:

0x7EB 8 05 62 F00F 00 62 00 00 00
CAN ID+4 CAN LEN OBD2 LEN MODE+0x40 SOC PID SOC VALUE UNUSED

 

Extended Frame Messaging Via CANBUS

The above example works for OBD2 CANBUS messaging that only need to transmit small amounts of data (eg: a single data value). Since a CANBUS message can have up to 8 bytes this can all be handled with a single message. In order to request larger data (such as cell voltages which respond back with considerably more than 8 bytes) the process is a bit more involved.

In order to support Extended Frame Messaging via CANBUS (messages with responses longer than fit in a single CAN message), the OrionBMS implements ISO 15765 (ISO-TP). Essentially this allows for longer messages to be broken up and divided into multiple CANBUS messages that are pieced together at the receiving node and the requesting node.

Covering the details of this protocol are beyond the scope of this document but here are some basics:

If the first byte in the response message is “0x10” then that means that there are additional frames waiting to be sent and only the first 3 bytes of the actual OBD2 payload was sent (bytes 5 6 and 7). The requesting device then needs to then send an “acknowledged, send the rest of the messages” response back. This response is called a flow control response.

 

This is best demonstrated with an example:

Transmit To BMS:

7E3 8 01 03 00 00 00 00 00 00

 

Receive First Message From BMS:

7EB 8 10 12 43 08 0A FA 0A C0

NOTE: The 0x10 as the first byte tells us that there is more data available. So the requesting device must request the additional data as follows.

 

Transmit “GO AHEAD” Flow Control Message To BMS:

7E3 8 30 00 00 00 00 00 00 00

 

Receive All Remaining Messages From BMS:

7EB 8 21 0A 01 0A 02 0A 03 0A

7EB 8 22 04 0A 05 0A 06 00 00

This tells us there are 8 fault codes set (P0AFA, P0AC0, P0A01, P0A02, P0A03, P0A04, P0A05, P0A06) and 3 messages are used to send this data.

 

NOTES:

  • The OBD2 length ONLY shows up in the first message (0x12 in the above example in hexadecimal, or 18 in decimal). Followup messages that are sent later ONLY include the message counter (the first byte, starting with 0x20 and incrementing by 1 until all messages are received) and the remainder of the payload. The message counter byte does NOT count towards the total message OBD2 length.
  • If the first byte of the first message is 0x10 then everything gets shifted down by 1 byte (e.g. the OBD2 length is now the second byte, the mode is now the third byte, etc).
  • The “GO AHEAD” flow control message MUST be sent within 500ms of receiving the “I have more data” message from the BMS. If the flow control message is not sent within 500ms the “GO AHEAD” request is discarded and no further messages are transmitted.
  • Once the “GO AHEAD” is successfully received, the BMS will transmit in rapid succession all the remaining data messages (it does not wait for individual acknowledgements between each message).
  • All OBD2 CAN related messages MUST be 8 bytes long (even if the actual OBD2 message length is less). Unused bytes at the end of a message should be filled with 0s.

The Extended Frame Messaging does NOT apply to the Orion Jr. if using the onboard serial RS232 interface (the RS232 interface does not have the same message length limitations that CAN does so this is not needed). The Jr. does also support OBD2 over CANBUS (if used with a CAN enabled Jr.) in which case the above Extended Frame Messaging would apply.

For a more detailed explanation of this protocol, please see the official ISO-15765 document.

 

Discovering Available BMS Units

Since the OBD2 ECU ID is programmable, it may not be possible to know ahead of time which BMS units are available on the network. For this purpose, OBD2 has what is called a general broadcast ID that all ECUs on the network will respond to.

The general broadcast ID is 0x7DF.

Any device that receives a request on the ID 0x7DF will automatically generate a response to it on its’ own ID. The requesting OBD2 device simply needs to scan for which IDs it gets responses on to determine what ECUs are available.

Example:

General Broadcast To Network:

0x7DF 8 01 3E 00 00 00 00 00 00
Bcast ID CAN LEN LEN MODE UNUSED BYTES (PADDING)

(Mode $3E is a “Keep Alive / Are You There” mode)

 

Possible Responses:

0x7EB  8 02 7E 00  00 00 00 00 00   – “I Am Here” from node 0x7E3

0x7EC  8 02 7E 00  00 00 00 00 00   – “I Am Here” from node 0x7E4

This example shows a response from 2 ECUs on the network. This doesn’t necessarily mean they are BMS units though (Mode $3E is supported by many ECUs).

In order to determine if the responding ECUs are BMS units, the user should send a Mode $9, PID 0x0B request. The BMS will respond back with a payload starting with the ASCII characters “ORIONBMS”. This will be a multi-frame response message and must be handled accordingly by the user software.

Interfacing With Orion Jr. (48v Version)

Device Basics

The Orion Jr. BMS primarily implements OBD2 via Serial RS232. This means the BMS uses the onboard serial RS232 interface as the low level transport mechanism (meaning serial messages are used to transfer the data to and from the BMS.

Some versions of the Orion Jr. also support CANBUS. CAN enabled versions do support OBD2 via CANBUS as well. For details on interfacing via CANBUS please see the “Interfacing With the Standard Orion BMS (CANBUS)” section above.

NOTE: When connecting via serial RS232 there is only one BMS available, which means it is not necessary to transmit the ECU ID (this is an important difference from the CAN connection method).

NOTE: The Jr. RS232 operates at 9600 Baud, Even Parity,  8 Data Bits, 1 Stop Bit

All RS232 OBD2 message requests and responses start with a colon (“:“)

A serial OBD2 request is nearly identical to the examples shown earlier. An example OBD2 exchange over Serial RS232 might look something like this:

RS232 message request from an external device:

:03 22 F00F
LEN MOD SOC PID

 

RS232 message response from the BMS:

:05 62 F00F 00 64
LEN MODE+0x40 SOC PID SOC VALUE

 

NOTE: All the spaces between the fields above should be removed. The spaces are inserted for illustrative purposes only.

NOTE: All RS232 messages MUST be terminated with a newline character (‘\n’) to signify end of line.

Real World Examples

Requesting Active Fault Codes (Mode $3)

Example with mode $3 (requesting faults set on BMS)

CANBUS Transmit Request To BMS:

7E3 8 01 03
ID CAN LEN OBD2 LEN MODE

CANBUS Response From BMS:

7EB 8 06 43 02 0A01 0A02
ID+8 CAN LEN OBD2 LEN MODE=0x40 # of codes CODE 1 CODE2

In this case, 2 fault codes are set. P0A01 and P0A02.

NOTE: Since no PID was provided (no PID is needed for mode $3 transactions) no response PID is included in the reply.

 

Clearing Active Fault Codes (Mode $4)

Example with mode $4 (clearing faults set on BMS)

CANBUS Transmit Request To BMS:

7E3 8 01 04
ID CAN LEN OBD2 LEN MODE

 

CANBUS Response From BMS:

7EB 8 01 44
ID+8 CAN LEN OBD2 LEN MODE+0x40

 

The BMS responds with an acknowledgement that the fault codes have been cleared.

NOTE: Since no PID was provided (no PID is needed for mode $4 transactions) no response PID is included in the reply.

 

Requesting Data (Mode $22)

Example with mode $22 (requesting data from BMS)

CANBUS Transmit Request To BMS:

7E3 8 04 22 F00F
ID CAN LEN OBD2 LEN MODE PID FOR SOC

 

CANBUS Response From BMS:

7EB 8 05 62 F00F 0064
ID+8 CAN LEN OBD2 LEN MODE+0x40 SOC PID SOC VALUE

 

NOTE:  In this particular instance, the SOC value received is actually SOC * 2 since it’s in 0.5% increments. Divide by 2 to get the actual value (this does not apply to all values, please see the OBD2 PID list for the default unit scalings).

NOTE: For a list of supported PIDs, please see the official OBD2 PID list:

http://www.orionbms.com/downloads/misc/orionbms_obd2_pids.pdf

 

]]>
http://www.orionbms.com/general/retrieving-data-obd2-canbus/feed/ 0
Orion Jr. BMS does not power up (LED stays off) http://www.orionbms.com/troubleshooting/orion-jr-bms-power-led-stays-off/ http://www.orionbms.com/troubleshooting/orion-jr-bms-power-led-stays-off/#respond Tue, 10 Feb 2015 20:15:45 +0000 http://www.orionbms.com/?p=2553 Continue reading ]]> The Orion Jr. BMS has an optional low power shutdown that can limit the amount of power drawn from a dead battery. If the Orion Jr. BMS is not powering up, this low power shutdown is likely the cause, particularly if the battery pack was discharged just before the problem occurred. This power saving feature is provided on the Orion Jr. BMS to prevent over-discharge of a battery pack as the BMS is often powered directly by the battery pack it is protecting. The BMS can only be restored after a lower power shutdown by either removing all power to the BMS for a full 60 seconds or by applying power to the charge pin (Main I/O pin 4).

Step 1) Unplug the Orion Jr BMS Main I/O connector.

Step 2) Wait a full 60 seconds with the connector disconnected; then reconnect. This will cause the BMS to exit the low power shutdown mode. Waiting a minimum of 60 seconds is essential as the latch can take this long to release after power has been removed.

If the above fails to awake the unit, ensure that the BMS unit has power on either pin 2 or 4 (READY or CHARGE) and that the ground is good on pin 6. If power is good to these terminals, contact Ewert Energy to evaluate the unit.

Note: The maximum voltage for the power supply on the Main I/O connector is 60V DC. Voltages higher than this may damage the unit and cause the unit not to function. If this happens, the unit should be removed from service immediately and sent in for service.

]]>
http://www.orionbms.com/troubleshooting/orion-jr-bms-power-led-stays-off/feed/ 0
CANBUS Elcon Charger isn’t charging, but should be (for standard Orion BMS) http://www.orionbms.com/troubleshooting/canbus-elcon-charger-charging-for-standard-orion-bms/ http://www.orionbms.com/troubleshooting/canbus-elcon-charger-charging-for-standard-orion-bms/#respond Mon, 05 Jan 2015 20:20:11 +0000 http://www.orionbms.com/?p=2548 Continue reading ]]> Start with everything setup such that the charger should be charging the batteries.

Step 1. Open the BMS utility and select File -> Connect to the BMS. If you are unable to connect ot the BMS, see the Troubleshooting Guide on http://orionbms.com/troubleshooting/ for help connecting to the BMS. If unable to communicate with the BMS only when the charger is connected or only when the charger is powered, it is possible that the baud rates of the BMS and charger are different or that the CAN wiring to the charger is causing communication problems. If this happens, ensure that CAN High and CAN Low are not backwards and that the BMS and the charger are operating at the same baud rate (usually 250kBps for Elcon / TC chargers).

Step 2. Select the “Live Text Data” tab at the top of the screen.

Step 3. Near the bottom of the screen where it says “Selected Parameter Group”, select “Advanced Paramaters.”

Step 4. Look for the parameter called “Is-Charging” power status. This should read ON. If this reads OFF, then charge power is not applied to the BMS. Apply charge power to the BMS to correct this issue.

Step 5. Look for the parameter called “Charger-Safety Output Active”. This should read ON indicating that the BMS is calling for charge. If this reads OFF, then the BMS is not allowing charge for some reason. If that is the case, proceed to step 5a and continue diagnosing until “Charger-Safety Output Active” reads YES, otherwise proceed to step 6.

Step 5a. At the bottom of the screen where it says “Selected Parameter Group”, select “Current”.

Step 5b. Look for the parameter called “CCL Zero Because Charge Complete”. If this says “YES”, it means that the BMS tried to charge the pack and stopped because a battery exceeded the maximum voltage. You can select “Restart the BMS” from the File menu and the BMS will attempt to charge again to closely watch what is happening. If the charger turns off very rapidly, it may be necessary to use the graphing screen to graph the highest cell voltage look for rapid spikes in voltage. Rapid spikes in voltage may indicate a problem with a cell or loose busbar / connection and may require diagnostics on the cell causing the issue. This also may be perfectly normal if a cell is fully charged (the voltage of the Iron Phosphate cells in particular will shoot up in voltage near the termination of charge).

Step 5c. Look for the parameters called “Reduced Due to Voltage Failsafe”and “Multi-Unit Comm Failsafe.” If either of these parameters read YES, the BMS is prohibiting charge due to a critical failure. Look at the “Diagnostic Trouble Codes” page for fault codes and diagnose these codes. Note that only certain codes are critical and prevent charging or discharging. Charging will be prohibited if the charge current limit (CCL) is zero amps for any reason.

Step 5d. Ensure that the profile on the BMS has been setup and that the charger safety relay has been enabled. If the profile has never been setup, run through the profile setup wizard in the utility if using a battery type in the database, otherwise, ensure that the profile has been setup manually. The BMS will not allow charging or discharging if the profile has not been setup or if the charger safety relay is not enabled.

Step 6. Download the current profile from the BMS to ensure proper CANBUS configuration for the Elcon / TC charger. Switch to the “Battery Profile” tab at the top. Select “Receive Current Profile From BMS.”

Step 7. In versions of the utility newer than 1.8, select the “CANBUS settings” tab (under 3rd party devices in older versions.) Ensure that there is a checkbox next to the “Elcon / TC Charger” line. If this is not checked, place a check next to it, follow the instructions and upload the updated profile to the BMS. This box can be un-checked and re-checked in order to ensure that the proper Elcon charger has been selected (this is important as selecting the wrong charger will transmit the wrong information and will likely result in the charger not operating).

Step 8. Click on the CANBUS settings tab (if you are not already there) and check to ensure that the CANBUS which the Elcon charger is connected to is operating at 250kBps. Please note that the BMS must be fully power cycled with all power removed after a CANBUS baud rate change has occured.

Step 9. Ensure that the maximum amperage while charging is set to something within the charger’s capabilities. If the charger receives a request to charge faster than it is able to charge, it may enter into an undefined state. This parameter can be found on the “Charge Limits” tab on utility versions 1.8 and newer.

Step 10. Ensure that the charger is powered. If there are any relays or contactors that shutoff AC power to the charger, ensure that power is actually reaching the charger using a multimeter as a relay may have failed or may not be activating.

Step 11. Ensure proper CANBUS wiring. CAN wires MUST be twisted pair wire and MUST be properly terminated to operate correctly. Exactly two (2) 120 ohm termination resistors must be present on the CANBUS. Ensure that CAN High and CAN Low wires are not reversed (see the wiring manual and Elcon application note for more information).

Additional troubleshooting tips:

If the Elcon charger is configured with the standard CANBUS message ID, it is possible to use the “3rd Party Data” section of the utility to communicate with the Elcon charger itself to ensure that the BMS can communicate with the charger. Please note that this only works with chargers using the 0x1806E5F5 CANBUS ID. To do this, the CANdapter should be connected to the same CAN interface that the Elcon charger is on, though limited data may be available even if located on the other CAN interface (the BMS is configured by default to pass this information through, but only for the standard CANBUS ID). On the “3rd Party Data tab”, select the “Elcon Charger” under “Selected Third Party Device” and press connect. Under “Device Parameters”, there should be some information from the Elcon charger. If all of the lines starting with “Elcon” read “Not Available”, the BMS utility is unable to establish communication with the Eltek chrager. This may be a sign tha the charger is not powered, that there is a CANBUS wiring problem, or a defective charger. This can also happen if the CANdapter is not connected to the same CAN interface that the Elcon charger is on. Troubleshoot this by ensuring that the charger is powered and that the CANBUS connection to the BMS is good.

The Live CANBUS Traffic tab can also be used to diagnose if the BMS is correctly transmitting CANBUS messages. By default the BMS will transmit data to the Elcon charger on both the 0x1806E5F5 and 0x1806E9F4 messages. This is because most Elcon chargers come configured with one of these CANBUS IDs. The Elcon charger should be responding on another message such as 0x18FF50E5. If only the transmitted messages are showing up, it may indicate that the charger is not responding.

Note: Elcon chargers can be special ordered with different a CANBUS ID. If this happens, the CANBUS ID will need to be manually changed in the BMS utility to work correctly.

Note: Elcon chargers may enter an undefined state if they are told to charge at a higher amperage than their maximum possible amperage. This will prevent them from charging. When setup using the profile setup wizard, the BMS will not transmit a charge current limit higher than the maximum allowable for that charger. However, if setting up manually, ensure that the “Maximum Amperage While Charging” variable is set at or below the theoretical maximum possible DC amperage for the specific model of charger being used.

]]>
http://www.orionbms.com/troubleshooting/canbus-elcon-charger-charging-for-standard-orion-bms/feed/ 0
EVIC Display By Andromeda Interfaces http://www.orionbms.com/display-integration/evic-display-andromeda-interfaces/ http://www.orionbms.com/display-integration/evic-display-andromeda-interfaces/#respond Fri, 14 Nov 2014 19:23:48 +0000 http://www.orionbms.com/?p=2532 Continue reading ]]> EVIC OrionBMS

Ewert Energy Systems is pleased to announce the availability of the EVIC advanced display system by Andromeda Interfaces, Inc. Official manufacturer support for the EVIC display is available out of the box with the OrionBMS.

The EVIC display touts a number of significant features such as a ruggedized automotive grade construction, customizable user interface design and lightweight form factor. The display’s ability to interface with multiple input sources allows it to become a complete driver feedback solution.

For more details or pricing on the product, please visit the manufacturer’s website:  http://www.ai-displays.com

 

EVIC Spec Sheet

]]>
http://www.orionbms.com/display-integration/evic-display-andromeda-interfaces/feed/ 0
Cells are not balancing, but should be http://www.orionbms.com/troubleshooting/cells-balancing/ http://www.orionbms.com/troubleshooting/cells-balancing/#respond Tue, 28 Oct 2014 20:59:59 +0000 http://www.orionbms.com/?p=2522 Continue reading ]]> For a detailed description of how balancing on the Orion BMS works, please see “How Balancing Works” in the operational manual.

Balancing only occurs when power is applied to the CHARGE power pin, causing the BMS to enter into CHARGE mode. For balancing to occur, the following conditions must be met:

  • At least one cell must have reached the “The Start Balancing voltage”
  • There must be a difference in voltage between the highest and lowest cell of at least the value in the “Stop balancing when all cells are within” voltage (usually 10mV)
  • The voltage of any cell being balanced must be above the “Never balance individual cells below” setting
  • The heatsink temperature must be below 50 degrees C.

Certain critical faults that result in a voltage fail safe condition (such as an open wire fault) will prevent balancing from occurring.

Note: It is normal for the cells on the live data screen to turn white for a while before turning red again. The BMS is allowing cell voltages to settle to re-evaluate the difference in state of charge between cells while all cells are white. The length of time that all cells are white (not balancing) is dependent on the temperature of the heatsink on the BMS and the number of cells requiring balancing.

Resolving the issue:

Step 1. Open the BMS utility and select File -> Connect to the BMS. If you are unable to connect to the BMS, see the Troubleshooting Guide on http://orionbms.com/troubleshooting/ for help connecting to the BMS.

Step 2. Ensure that the BMS is powered in CHARGE mode. In the BMS utility, click on the “Live Text Data” tab at the top. Near the bottom of the screen where it says “Selected Parameter Group”, select “Advanced Parameters.” Look for the parameter called “Is-Charging” power status. This should read ON. If this reads OFF, then charge power is not applied to the BMS. Apply charge power to the BMS to correct this issue.

Step 3. Ensure that at least one cell reached the “Start Balancing Voltage. Download the settings profile from the BMS and ensure that at least one cell in the pack has exceeded this voltage (ensure that in all cases the voltage is below the maximum cell voltage specified by the cell manufacture.) This only needs to occur for a very brief amount of time and only one cell must cross this threshold to start balancing.

Step 4. Ensure that any cell that should be balancing has a voltage above the “Never Balance an individual cell below this voltage” setting. The BMS will never remove charge from a cell below this voltage.

Step 5. Check to ensure that balancing has not stopped due to all cells being balanced. The BMS will determine that all cells are balanced if the difference in voltage from the highest to lowest cell voltage is less than the “Stop balancing when all cells are within” voltage.

Step 6. Ensure that the heatsink temperature is below 50 degrees C. The BMS will temporarily pause balancing if the heatsink temperature rises too high to prevent overheating of the BMS. The temperature can be checked through the BMS utility on the Live Text Data tab by selecting “Thermal Management” at the bottom and looking for the “Internal Heatsink Temperature” parameter. If the heatsink is too hot, allow the unit to cool and balancing should resume.

Step 7. Ensure that no critical error codes are present on the BMS. On the live text data tab, select “Current” at the bottom. Then look for the parameter reading “Reduced due to voltage failsafe.” Balancing is disabled if this reads “YES.” If this reads “YES,” click on the diagnostic trouble codes screen and resolve the error codes using the documentation available in the troubleshooting guide. In particular an open wire fault (P0A04) or Pack Voltage Mismatch (P0A03) fault may lead to this condition. If an open wire fault is present (P0A04), be sure to address that problem first as it likely is the root cause of other faults.

]]>
http://www.orionbms.com/troubleshooting/cells-balancing/feed/ 0