7.7 Program Strategies
This section outlines some of the issues to consider when programming or editing your own battery routines.
Programming instructions can be used as in as many steps as required. The same programming statement can be assigned any number of times. They are especially generic if they do not specify a GoTo = 0 (ie next step).
Whenever the GoTo Step is 0 it instructs the device to route to the next numbered step. This is very common and allows you to assign the same program instruction in many different steps. With this strategy you will need fewer program statements. Also the program will be easier to read, understand, modify and debug.
Termination Program Statements
A termination statement is a routing statement that describes a condition which will cause the presently running program step to end. The termination statement consists of the condition to test and what action to take when the tested condition is met. Each step is assigned up to 12 possible termination statements. The termination statements are selected from up to 32 different programming statements available for each program. With each step you specify which programming statements to use for step termination. As long as no assigned Conditional Statements are true (see below) then the program routes to the step identified in the assigned Termination statement that caused the step to terminate. The assigned termination statements can also increment one of the 7counters to when this termination statement is executed by the device.
Conditional Program Statements
Users can also specify Conditional statements with each step. This is optional and provides for alternate routing if specific conditions are met. With this feature the routing can branch to different steps depending on various parameters. If no conditional statements are specified then routing will follow to the GoTo step specified in the termination step that caused the termination. If conditional statements are specified then routing will continue based on the conditional statement if it is true. Conditional statements are optional. They are not required but they can be used to provide for more complex program routing that will be based on measured parameters. These are useful for writing programs that stop when some conditions exist or possibly go on to execute more steps or loops when other conditions exist. This can allow you to have the device routine finish sooner by running for only as long as required.
For example if the battery test runs successfully then the program can stop early to save time, however if more cycles or steps are required then the program will only run longer when required. Conditional statements are only checked once a termination has occurred. This is different than the Termination statements which are continually checked during the step. So once any termination has occurred all conditional statements (if any) will be checked. If any conditional statements is true then the Next Step, Counter and Reset parameters of the true conditional statement will override the Next Step, Counter and Clear parameters in the termination statement that generated the termination. The termination will still occur as per the termination statement but routing will be controlled by the true conditional statement rather than the termination statement.
If there are more than 1 conditional statement then only the conditional statement that is true will be executed. If there are other additional conditional statements that also happen to be true then the first (lowest number – irregardless of order) true conditional statement will take priority. Once a termination statement terminates the step, all listed conditional statements are examined. Starting with the lowest number and continuing with the next higher number until all conditional statements are examined. If a conditional statement with a higher number is not true (false) then it will be ignored. If no conditional statements are true then the termination statement that generate the termination will control the routing.
By having the first true conditional statement become the one that controls the routing you can create very powerful selection algorithms to create selective routing. This can be used to implement a look up table. For example if you want to route to different steps depending on the voltage then you can write the conditional statements to look like:
(1) If voltage <11.0 Go To Step 16
(2) If voltage < 11.2 Go To Step 18
(3) If Voltage < 11.4 Go To Step 20
(4) If Voltage < 11.6 Go To Step 22 (Notice that if V=11.55 then the routine routes to step 22)
(5) If voltage < 11.8 Go To Step 24
(6) If voltage < 12.0 Go To Step 26
Note that this is not the same as:
(1) If voltage <12.0 Go To Step 26 (Notice that if V=11.55 then the routine routes to step 26)
(2) If voltage < 11.8 Go To Step 24
(3) If Voltage < 11.6 Go To Step 22
(4) If Voltage < 11.4 Go To Step 20
(5) If voltage < 11.2 Go To Step 18
(6) If voltage < 11.0 Go To Step 16
Because the FIRST true statement is the one that controls the routing.
You must have a termination statements for every step if you want to allow the routine to move to another step. If you do not specify any termination statements then the only way to force the device to route to another step is by doing a power On/Off (routes to step 1) or pressing the vector switch (routes to the vector step if it is > 0 )
You do not have to have a Stop function in your program. Any step with no termination program statements will not continue anywhere and will act like a Stop function. The Stop function is similar to the Pause function with the only exception being that Step Time does not increment during a Stop function and it does during a Pause function. This means that you cannot terminate a Stop function with a program statement like: If Step Time > 0 then GoTo 6
However you could terminate the Stop function with a statement like:
If V<1 then GoTo 3, or If Step Time = 0 then GoTo 8
You can always generate a H/W restart by powering Off/On with the power switch. This is a hardware restart. When the power comes back on the device will restart in Step 1. This method of restarting the device for a new session is really only needed when you cannot, or do not want, to implement an intelligent Software Restart (see below) to begin a new session. Normally you would use a software restart to have the final step check for a large voltage drop (battery is removed) and automatically proceeding to Step 1 to get ready for another battery to be connected. Step 1 would be programmed to check for a voltage rise (new battery is connected) and begin the session. However if you were using the device to test for an open battery situation then you may not want the open battery (no terminal voltage because battery is defective or battery protection circuitry has been activated) to restart the session.
In many applications you can write the program to automatically restart the program intelligently. This means you would implement a restart based on some event occurring. For example you could use a software restart to have the final step check for a large voltage drop (battery is removed) and automatically proceeding to Step 1 to be ready for another battery to be connected. Step 1 would be programmed to check for a voltage rise (new battery is connected) and begin the session. With this type of programming you never have to do a hardware restart. You can just keep reusing the device over and over again running the same routine again and again without ever having to power Off/On.
The 7 counters are useful as a memory device or to flag a particular condition. When a condition exists you can set a counter as a flag and then refer to this flag later.
ex. In Step 6 you may have: If mAH>1000 then go to step 14 and increment counter2.
Now in future steps you can just check counter 2 to determine if there was a Pass or Fail on this earlier step.
Counter 1: This is a special counter. The value of this counter appears in column 1 of the ‘Saved Data’ results in the console. Use this counter to count events and make sense of your ‘Saved Data’. For example increment Counter 1 on completion of each cycle so that the cycles are numbered properly in the Console. Or if you are running a series of tests, increment Counter1 on completion of each test so the tests will all be conveniently numbered in the console ‘Saved Data’ area. This counter is also displayed as real time data in the console so that you can see which cycle number or test the device is currently processing..
Counter 2: This is a normal counter available for general use. It gets cleared on the Reset step and is visible as real time data in the console.
Counter 3: This is a special counter. This counter does not get cleared on the Reset step. This counter will only get cleared when the device powers Off/On. So you can use this counter to measure productivity on a daily basis. Whenever you want to reset this counter simply power the device Off/On. This is useful for counting the total number of tests performed since the last time it was cleared. This counter is displayed as real time data in the console.
Counter 4: This is a special counter. This counter never gets cleared. Even a power Off/On will not clear this counter. This is a permanent counter used to measure productivity over a longer period of time. Think of this as the lifetime odometer. Of course, if you want to use it, you will need to program the routine’s programming statements to increment this counter. This counter is displayed as real time data in the console.
Counter 5, 6, 7: These 3 counters are normal counters available for general use. They get cleared on the Reset step but are not visible as real time data in the console. Use these as required to control routing of the routine.
In the programming information you specify which program step causes a session reset. Once the program encounters the step designated as a reset step then all data and information from the previous session will be cleared. This data will no longer be available. This could be set up as step 1 so that every time you turn on the device you will clear the previous session’s data. Alternatively, if you want to preserve the data for later viewing set the reset step to a higher number so that the new session won’t begin until the battery is connected.
A session reset will clear the Total Time timer as well as Counters and clear all saved data from the previous session.
In the programming information you can specify a vector step. This is the step that the device will route to when the hardware push-button is pressed. With this feature you could actually have 2 programs loaded in the device and the vector button can be used to force the program to the 2nd program routine. The vector push switch can be set up to have many different uses. e.g. Restart, reset, continue, stop etc. etc. You just need to specify a step to route to when the vector push button is pressed. You can also route the the vector step by pressing the Vector button on the software console.
If you have configured this device to be part of a group of devices (Host channel plus all devices that share the same host channel) then routing to the vector step will route all devices in the group to their respective vector steps as well. In this fashion the vector step can be used to control all devices in the group. This would normally be used to be able to shut down or reset all devices in the group simultaneously.
Program Debugging & Testing Tips
When trying to test your new programs you can generate a termination using Step Time. This would be used just for testing and is useful for testing conditional statements. By adjusting the termination statement time interval you can simulate a variety of conditions to ensure that your program is routing as you expect. When you no long need this test termination, just remove the statement number from the step.
Routine statements are assigned as either termination, conditional or message statements by listing the corresponding program statement number. Remember, if you do not have any termination statements listed, then the step will never end. Also remember that conditional statements are only checked once a termination occurs. When at termination occurs as a result of any termination statement then the conditional statements are checked.
When a conditional statement is checked and found to be true, the program will act on this statement and route accordingly. True conditional statements will be ignored and not be acted upon until a termination occurs due to a true termination statement. The conditional statement, found to be true, will override the GoTo, Counter and Clear items of the termination statement that caused the step to terminate.
It is possible to have logical errors in your program that cause the device to act in unexpected ways. For example if you have a term statement such as: If Step Time < 65 then go to Step 0 (next step).
This statement will immediately be true at the beginning of a step causing it to terminate immediately. The same can be true for all statement types. You need to carefully consider the effect of each step and then test your program carefully.
You need to test your program routine thoroughly so you know exactly how it will perform in all situations. Failure to test your program can result in the device acting incorrectly. This can cause a dangerous situation resulting in battery damage, fire, explosion personal injury and death.
In your program a single programming statement cannot be used as termination statement AND a conditional statement. If you ever need an identical termination and conditional statement then you will need to specify two separate identical programming statements and use one as a term statement and the other as a conditional statement. With 32 possible programming statements you will probably never need to use this many in one program. You do not need to assign all the programming statements. You can keep them in your program so that your program list can act as a library of available programming statements. This can make programming faster and easier to adjust.
If you have specified charge pulses during a discharge then you will need to enter a maximum Vreg value. If no charge pulses are specified then a Vreg entry is not required for a discharge function.
Counters only increment after the step has terminated and just before the next step begins. This means that if you increment a counter, it cannot be tested for the new value until the following step.
Inserting some extra steps can facilitate program building, testing and debugging. If you have some spare steps scattered throughout your program then it becomes easier to build steps without having to readjust the termination and conditional statement numbers of existing steps. You can just use the spare steps.
Be careful with the use of the equals ( = ) function
Avoid the use of the = function for terminating values that can change, such as Voltage, current, time, mAH etc because the value could be lower then greater and never be equal. For example if the voltage is dropping during a discharge do not attempt to terminate the discharge with a statement like: If Voltage = 10 because the voltage could drop from 10.01 to 9.99 in the time between the device checks for a possible termination. Resulting in the discharge continuing right down to 0. This is an example of a logical program error and an example of how all programs must be tested carefully before they can be relied upon.
The correct terminating statement to use would be: If Voltage < 10 then ……
Keep this in mind when terminating on other values as well.
The = function should really only be used when programming statements with counters.
Using dT/dt termination
Allow time for the battery to cool if you need dT/dt termination on two successive steps. You can insert a pause statement to allow the battery to cool and then terminate the step when T< Value . This way you can have a pause that lasts just long enough for the temperature to drop to normal. dT/dt will only detect a positive increase in the rate of temperature rise. If the temperature is dropping then the dT/dt value will be zero.
Consider what will happen when the battery is disconnected
If the battery is disconnected then the voltage that the device sees at the terminals may not be zero. If you have a step programmed to charge with Vreg=12V and Ireg=100mA. Then the device will generate either 12V or 100mA whichever is reached first. When the battery is disconnected, no current will flow and the device will regulate the terminals to 12V. So the device will be measuring 12V.
If you are trying to use a step that will detect when the battery is connected then you should use a Vreg value that is below the expected battery terminal voltage (you could use Vreg=0) and then terminate this step on a voltage>1V . The voltage can then only be >1 when the battery is detected.
This is also important to consider when trying to detect a disconnected battery at the end or during a session. When the battery is removed the current will stop, so the device will regulate on the Vreg value if it is a Charge step. If you have been charging at constant current then the Vreg value must have been greater than the battery voltage. The device terminal voltage will then rise up to the Vreg value once the battery is removed. So to detect the disconnected battery you should terminate on the voltage being greater than some value. For example to charge a 6 Cell 7.2 V NiCd battery you could set the Ireg to 200mA (desired charge current) and set the Vreg value to 20V. Once the battery is removed the device terminal voltage will rise to 20V. The device can be program to terminate if the Voltage>18V
Similarly if you are charging a SLA battery at constant voltage of 14.7V with a Ireg = 250mA (Maximum current limit) then when the battery is disconnected the device terminal voltage will continue to be 14.7V. In this case you can program the step to terminate (and route to step 1 to start over) when the Current is < 15 mA or some low value that will only occur when a battery is removed. You can also use an extra step to restart the device if you think there could be a possibility that the current would drop to less than 15mA normally. In this case you could have the device go into an extra step when the current drops below 15mA. This extra step could be programmed with Ireg=0 and Vreg=5V. Now this extra step would not provide any charge current because the Vreg value is below the actual battery voltage. Once the battery is removed the device will regulate to 5V and you could terminate this step (detect a removed battery) if the voltage < 7. 5V is a better choice than using Vreg=0 because the voltage may never actual=0 due to normal offsets. For example if you set Vreg=0 then the device may measure 0.05 V or some small value so the statement “If V=0 then“ will never be true.
So remember that during a Charge step the terminal voltage will rise to the Vreg value when the battery is removed.
To detect a battery removed situation during a charge you will need a statement such as:
IF Voltage > 10 then Go To next step ( This has now detected that the battery has been removed )
You may want to consider the effects of vibration and user actions on the operation of your program. For example: suppose you are performing a LiIon charge and want to terminate the charge when the current drops below a certain value. In the event the user touches, jiggles, shakes, vibrates or momentarily disconnects battery then the step may terminate. If you feel this could occur and you want to protect against this possibility you can do a double test of the current.
To do this, route to the next step when the current drops below a certain value. The next step will perform the same function and terminate on step time in 0.1 minutes and route back to the previous step (normal charge step). Include a conditional statement in this second step that will check the current when the step terminates. If the current is less than your minimum then you can assume that the battery has been removed on purpose, however if the current at the end of the 0.1 min is not less than the minimum then is was just a momentary drop in current and the program can then route back to the original normal charge step.
If you want to skip the clear then you cannot use step time to create delay with your double testing. In this case you could implement a counter situation. For example set use a termination statement such as: If V < 6 Go To next step. On the next step terminate If V < 6 as well but go back to a previous step & increment counter X. On 2nd step also have a conditional statement that if Counter X>10 then continue on to the 3rd step. This will create a 10 step loop to provide for the desired amount of delay for double testing.
Often it is very helpful to route to steps that are just used for parameter checking and routing and are not required for any length of time. On some of these types of steps you may choose to terminate on Step time (ex IF Step Time > 0.1 M). When writing and testing programs with these types of steps you might want to use longer step times while you are building and testing your program. This will allow time to see the step displayed on the PC Monitor to confirm that the step is actually occurring and operating as expected. Once you program is working as required you can then shorten the step times to your desired values.
A nice way to develop programs is to periodically review the complete program listing using Program Preview. This provides a comprehensive listing of the entire program and gives a bigger picture of the overall operation. You can view this online or send a copy to your printer for review. A printed copy will provide a hard copy of everything you have so far and give you a place to mark revisions and plan how to proceed further. A printed hard copy is a nice working document to help visualize the operation of the entire program and spot items that need further consideration.
Developing and testing your program will take a bit of time so proceed carefully with thought and planning. Expect to make changes and add new functionality to your program as you proceed. As you program and test you will discover new things that you need to consider and incorporate into your program. Developing a new program file is an iterative process of: Edit – Load – Test, Edit – Load – Test, …….. Edit – Load – Test …. until you are completely happy with the performance in all possible situations.
There are several tricks you can do to perform some complex checking within your program. For example if you want to determine if the battery voltage is between 0.5V and 7.2 V you could have one step to test if V>=0.5. If yes route to next step. The next step is identical in function but has term statement if V<=7.2. This will only occur now if V is in the range of 0.5 – 7.2 because the previous step determined that is was not <0.5 V.
If you want to route to one step if a parameter is > than a certain value and route to an alternate step if the same parameter is < than a certain value you can do this all in one step. To accomplish this, set the term statement to some value that will definitely occur. ex if step time>0 min. Then have two conditional statements one for Parameter A>= number X and the other for Parameter A< number Y. These two conditional statements can then route to different steps. Note is this case the GOTO part of the termination statement will never be used because one of the two conditional statements will always be used.
Alternatively you could use the fact that only the first (lowest number) routing statement that takes effect to create a powerful look-up table. Described earlier.
Remember the Battery’s effect
The battery of course is connected to the device during use. The battery has a voltage and there will be current flow at various times during the operation of your routine. You need to think about what the voltage will be, at various times, and how this may or may not affect the operation of your program. Also the battery voltage takes a finite amount of time to rise and fall once charge current begins and ends. An example is when charging a SLA battery at a constant voltage. You may want to move to a new step once the current drops below a certain point. If the following step is also going to regulate the voltage at some lower level, the current will probably be 0 for some small period of time until the battery voltage naturally drifts downward to the point that current will again start to flow. So if this second step is also going to terminate on some minimum current then it will probably terminate immediately because initially the current will be 0. You will want to plan for this when you prepare your routine.
Also when using the temperature probe remember that the battery will take a finite about of time to cool. An easy way to avoid situations such as this is to insert a pause step as required that will give the battery time to stabilize before proceeding to the next step.
Step Time vs Total Time
Remember that Total Time is the time elapsed for all steps since the last session reset. Don’t confuse this with Step Time which is the time elapsed for each step.
Consider the User
Remember that the person using the device will not be thinking about how the program is structured. They may remove or reconnect the battery at any time. You need to consider this when writing your program. If you want the device to revert back to the start of the program when the battery is removed you need to think about how this will work for all steps. This can be easily accomplished with a bit of planning. Often the program will just proceed through several steps and reach back at the start again. It is possible however that the program could get stalled on a step if you don’t consider all possibilities. If the device does get stalled on a step during program execution you can always power it on/off (hardware restart) to restart the device.
The device programming functionality is very powerful. With a bit of thought, planning and testing you will be able to write a routine to accomplish your objectives that is robust, easy to use and reliable. Don’t be afraid to experiment, test, debug and revise until you are happy with the operation. Of course you must watch your device very carefully during program development to avoid dangerous situations of battery over charge, or over discharge. The battery can be damaged, catch fire or even explode if not charged properly. The best way to avoid this is to use a voltmeter and current meter to carefully monitor the voltage and current during program development. Montor the Real Time and Save Data fields to monitor how the device is operating.
Only when you have fully tested your Program routine should you use it, or make it available for other people to use. Also each time you reload the Program you should monitor the process to ensure that it has been loaded correctly and is working as expected. Also be sure that you have indeed loaded the Program into the target device and have not inadvertently loaded it into another channel.
Companies, personnel and individuals who use this Battery Console software to load progrrams into the Battery Metric device should label the device correctly and accurately with sufficient detail so that people using the device will be sufficiently notified as to the specific application and use for the device. Just like every battery charger is labeled for the battery type, voltage , rating etc. you should label this device with similar information. This should include battery type, battery voltage and any specific instructions or warnings that the user should be made aware.
Furthermore, companies, personnel and individuals who run this Battery Console software must agree to sufficiently test the device after it has been programmed to ensure that the programmed device operates correctly for the intended application. This includes running each and every device with the Program prior to delivery to a user. This run test should include monitoring of voltage, current and all termination parameters for all steps of the program. The voltage and current should be monitored and measured using suitable current and voltage meters. Every possible situation that a user could encounter should be planned, accommodated and tested before putting the device into service.
Note that the routine routes automatically to step 1 when the device is powered up. However the previous session’s data does not get cleared until the routine routes to the reset step declared in the Program Information. This give you the opportunity to use the device to test a battery. Then remove the battery, turn off the device and preserve the session details and data to be viewed at a different time or location. For example you could test a battery at one location, then return to your office or shop to view & print the console information. This allows you to use the device as a battery tester in a remote location without requiring a computer. To take advantage of this feature you should write the routine to not reset until a battery is connected. This way you can turn on the device, view the on screen console details of the previous session on your computer. When you are ready to start a new session simply connect the battery. Ensure the routine is programmed to detect the battery voltage and route to the Reset Step thereby clearing all the data from the previous session and then the program can proceed with the new session.
Consider possible power failures
If the power fails during a session the device will automatically shut down all charge and discharge current. This is a fail safe mechanism designed to protect the battery from any damage due to over charge or over discharge. When the power is restored the device will automatically start at step 1 again. If power failures are a concern to you, then you can write the routine to perform as required during this situation. For example you could just have the session restart from the beginning. You could also have the device halt further action until you intervene. For example have the routine require the battery be disconnected at power up before proceeding to the next step. You can also preserve the console details until you get a chance to view the session up until the time of the power outage.
The following tips can help you set this up to meet your needs:
- Have step 1 only proceed if the battery is removed (i.e. V<1Volt). You can view the console during this step.
- Use step 2 the detect if a battery is connected. So now you will have to remove the battery (step1) and reconnect (step 2) to begin a new session.
- Use step 3 to reset the previous session’s data so the new session can now begin.