Download errors

matchbox

Senior Member
#1
Hi people,
I have been having trouble of late with a program that I have upgraded. And have refined it quite a bit; plus also changed the hardware as well.

I have been left chasing my tail for the last week with this.
One of the new features I added, was a motor driver with a current shunt sensor. So it can detect a motor stall or overload condition.
I originally thought that these errors were surrounding the FVR and ADCconfig commands, used to read the shunt. Being set at 2.048v.

But as I have gone along. I have notice the total randomness of the errors, from download to download.
e.g. one time it would ignore a status LED output command, so the LED wouldn't light up(but it would read the command right before it). The next time it would ignore a digital switch input. Then ignore the TIME variable etc etc.

I am using an old Windows XP unit. Because I'm outside doing these changes.
I rolled back PE6 to 6.0.8 on the machine, from 6.1.0. And did another download last night....It seems fine at the moment. But I haven't tested every function yet, for errors.

The compiler shows no errors, nor does the download show any.

What I'm wondering....Are download errors a possibility?

The program is in the file. If that might help, in case I'm missing something.
 

Attachments

Last edited:

hippy

Technical Support
Staff member
#2
What I'm wondering....Are download errors a possibility?
Highly unlikely. If you are seeing odd things happening that would usually be due to the program flow, its logic, or unexpected resets caused by the external hardware.
 
Last edited:

matchbox

Senior Member
#3
Thanks for the reply Hippy.
After the download of the program with 6.0.8 editor last night. I have run it through tests today. And Its run perfectly.
By the way. I always used this editor version on that PC from the time PE6 was released. It was only a week or so ago that I upgraded it.
That was what made me think it might be related to the old XP machine and the new editor.

I really thought that it might be external hardware too. But I put this though A LOT of testing to get to the bottom of this issue.
I'm certain its not all three pieces of hardware, that just happen to fail to work after different downloads, with no change to the code. Then the next time I do a download into the Picaxe. That piece of hardware magically works:confused:
e.g. when it drives, the LED didn't light to say the motor was driving. This line to tell the LED to turn ON, is right after the line that tells the motor to start!

Code:
if diff >= offset and E_once = 0 and west_limit = 1 then              
                   let OL_value = 71                                              
                   let west_limit = 0                                                
                   let time_ref = time + 20
                   let delay = time + 1                                            
                   let E_once = 1
                   high SLP                                                        
                   pause 400
                   high direction                                                    
                   high drive
                   high LED
                   let W_once = 0
But as soon as I did another download. The LED worked.

There is one other thing that might be the cause. The programming leads from the PC to the picaxe. Run inside the box that all the hardware is mounted in. And run right by an RF receiver antenna. I can't see any reason that this unit would emit any RF noise. Its only a key FOB unit.
I wonder if that could be corrupting the data stream. Because I only recently placed a download plug into the box, after the upgrade. So I could debug the current sensor real time.

These pictures are of the control board, H-bridge driver and RF remote unit in the lid of the box. This RF unit has been in this box working with the picaxe for over 7 years, before this. The program lead can be seen with the JST ZH plug.
 

Attachments

Last edited:

hippy

Technical Support
Staff member
#4
e.g. when it drives, the LED didn't light to say the motor was driving. This line to tell the LED to turn ON, is right after the line that tells the motor to start!
It could be that the motor is on but not because of that code so the LED is never set, or the LED is set but turned off so quickly elsewhere that you cannot see that it's on.

One thought is that because you seem to be using the 'time' variable, changes to that which are happening in the background while things are running is causing execution to go through unintended routines. It is a little hard to determine what the program code flow is anyway and where it should be at any point in time.

It may be worth putting some SERTXD commands in the code so you can trace execution, figure out where it's going, where it's going wrong, and why.
 

matchbox

Senior Member
#5
Thanks again for the reply.

It could be that the motor is on but not because of that code so the LED is never set, or the LED is set but turned off so quickly elsewhere that you cannot see that it's on.
That isn't likely.
The code I pasted above, is the only location in the program that tells the tracker to turn the motor and H-bridge driver ON, to drive East, once the Phototransitors see a light difference in that direction. And it also stopped after the light level equalized; but no LED operation.
The same thing happened to the west drive once as well.

One thought is that because you seem to be using the 'time' variable, changes to that which are happening in the background while things are running is causing execution to go through unintended routines. It is a little hard to determine what the program code flow is anyway and where it should be at any point in time.
The TIME variable is only used (in the main routine) as a reference for a Drive TIMEOUT. And a current sensor read delay.

The flow is -
- LIGHT_LEVEL -until sun intensity rises to tracking level
- SUN_TRACKING - is the main routine
- DRIVE_EAST -subroutine that controls east drive
- WEST_DRIVE - subroutine that controls west drive
- CURRENT_LOAD_CHECK -subroutine that branches off east or west subs, when drive is occuring
- OVER_LOAD -a goto if an current overload condition occurs
- NIGHT_PARKING -goto branch from LIGHT_LEVEL once the light is almost gone for the day


It may be worth putting some SERTXD commands in the code so you can trace execution, figure out where it's going, where it's going wrong, and why.
That sounds like the idea. Although I have always found it difficult to accomplish on a PC with low processing power. Without breaking the code down. Because it slows the terminal down badly.

Question. Is there a limit to the speed that FVR and ADConfig can be turned ON and OFF.
Code:
Current_load_check:

        let average = 0
    for cycle = 1 to 5                                  
        fvrsetup FVR2048                               
        adcconfig %011                                    
        readadc10 b.3, current_load                      
        let average = average + current_load
        pause 400
     next cycle
         let current_load = average / 5                  
       
         fvrsetup off                                            
         adcconfig %000                                   
       
          return
My theory is; that if "adcconfig %000" was not returning the ADC to supply voltage level, before the next ADC sensor read.....Then that might be causing a problem?

Here's a copy of the program in (.bas) with comments next to each line to explain operation. I'm certainly not ruling out that I stuffed up somewhere.

Thanks again. No rush...I'm grateful for your advice.
 

Attachments

#6
Whenever working with one or more motors (or any inductive load), you need some method of indicating that the PICAXE (or any microcontroller) has booted. Your problem could be that any inductive load switching is causing the PICAXE to reboot.
 

matchbox

Senior Member
#7
Whenever working with one or more motors (or any inductive load), you need some method of indicating that the PICAXE (or any microcontroller) has booted. Your problem could be that any inductive load switching is causing the PICAXE to reboot.
Thanks for the reply Pete
When you say booted. You mean a random re-boot due to interference ?
I'm not dismissing anything here. Any idea is a possibility.

The odd bit. Is that when I have had the program ignore outputs or inputs radomly. I could do a power down reboot. But the problem would still remain.
It was only after I would do a reload of the same program, that the fault would correct itself.

One of the things I changed in this upgrade, was the H_bridge driver, with its built-in current shunt.
But I have used this same driver in a project, that has been working fine for the last 12months.
And both do have substantial motor filtering applied.

I know it seems like I have an answer to everything. And don't mean to come across as a know all. But I really have tried everything I can think of.
It is SO odd.
Asking here was a last resort.

Some question -
Does the compiler read back every byte that gets transferred to the Picaxe? Is it possible that a byte or two could slip passed?
Is it possible for the boot strap to get corrupted in any way at all?

Thanks again
 
Last edited:
#8
Some question -
Does the compiler read back every byte that gets transferred to the Picaxe? Is it possible that a byte or two could slip passed?
Is it possible for the boot strap to get corrupted in any way at all?
While I don't know the answer to your question, I can say that there is a pretty comprehensive error checking/feedback routine built into the download process. I would say with almost 100% certainty that "download errors" are not the root cause of your problem.
When you say booted. You mean a random re-boot due to interference ?
I'm not dismissing anything here. Any idea is a possibility.
Yes, voltage and current spikes are notorious for resetting microcontrollers. Notice that I use the word "microcontrollers" - it affects all microcontrollers and microprocessors, not just PICAXEs. Two things to watch are 1) having sufficient and suitable capacitance close to the microcontroller's power pins and 2) Having separate +ve and -ve paths from the power source to the microcontroller and from the power source to the driven load. What sort of snubber circuitry is provided on the motor controller and relay boards?
 

hippy

Technical Support
Staff member
#9
Does the compiler read back every byte that gets transferred to the Picaxe? Is it possible that a byte or two could slip passed?
As I understand it, every byte is checked. I have never known a program to get corrupted when being transferred without the compiler reporting a verification error.
Is it possible for the boot strap to get corrupted in any way at all?
Extremely unlikely. It is probably not impossible though if a PICAXE were exposed to lightning strikes or other extremely adverse situations.

In terms of either download or firmware corruption causing the problems you are experiencing those are almost certainly not the cause.
 
#10
Thanks again for the reply guys

So far it hasn't missed a beat from the last program download, that I did with the PE6 6.0.8 roll back.
The program hadn't changed from before that either.

At this point...I'm just happy that its going. After being frustrated with it for over a week, with no joy.

What sort of snubber circuitry is provided on the motor controller and relay boards?
It is using the blue PCB in the above picture. Which is a 17A H-bridge driver. It has a 100uF electrolytic cap as its primary filter. And the Actuator motor has 2 x 220nF poly caps.

Hippy. Do you know the answer to my other question in post #5. Is there a limit to the speed that FVR can be turned ON and OFF, and ADCconfig can alter state?
 
Last edited:

hippy

Technical Support
Staff member
#11
Hippy. Do you know the answer to my other question in post #5. Is there a limit to the speed that FVR can be turned ON and OFF, and ADCconfig can alter state?
Not sure. There is likely no limit to how quickly it can be switched but there will probably be some time taken as the reference voltage stabilises and changes from one voltage to another and that could impact things but I don't believe anyone has quantified that.

Put a PAUSE 1 or higher before the READADC and reduce the PAUSE 400 after and it will likely allow things to have settled without changing the timing if it hasn't anyway.
 
Top