The old switcharoo
KenBash
Posts: 68
I have a 5 axis machine I control with the propeller. It's very similar to a CNC mill, but used for applying coatings to a mandrel. The motors are all steppers with step and direction signals for each axis.
I keep it connected to a laptop and simply modify the program when I need to change the program for a different part.
Every once in a while, possibly once in 50 – 100 times, I will download the program and instead of getting a normal “Home” sequence where all 5 axis drive back into their limit switches, my z and my x axis “Switch” somehow and the machine drives that switched axis into the “Wall” I have damaged some expensive tools a couple of times this way, but have learned to watch it and hit the kill switch early if it happens. I can immediately re-program the propeller, and often this “Switch-up” will be there again. However, if I kill the power to the machine, restart and re-program, it almost always works fine again.
Up until today, it hasn't been enough of a problem to rewrite my software for another controller or even replace the Proto Board I'm using.
However, today, for the first time that I am aware of, two axis switched operation IN THE MIDDLE OF A PROGRAM! ( or at least one axis was performing the movements called for by another axis. )
It worked fine for two layers, then I made a small (normal) tooling change, and when the system went to apply the next layer, my rotational axis was performing the movements of my X AXIS! There was no reset, no reprogramming or anything this time. It was as if something inside the chip simply routed both the step and direction signals to two other pins.
There are no other driver chips between the Propeller and the Compumotor drives,
1.The EXACT same program normally works fine. It makes me doubt that it is a software error.
2. I got two coats on first. This means that all 5 axis WERE working fine.
3. both the step AND direction signals were involved because the axis that was switched isn't required to move at all during that part of the program.
4.The port pins involved are not next to each other ( and wires run to different locations ) , so I doubt external signal coupling.
I haven't been terribly concerned with the occasional switched axis immediately after reprogramming, I could easily write that off to a transposed bit or something during program download, however, to have it occur in the middle of a program worries me. This board has easily been programmed 3 – 5 THOUSAND times. The EEPROM gave up the ghost long ago so I just download whenever I want to run it and run from ram.
I know that this continual re-programming isn't the “Normal” way of using a Prop. Is there a possibility that I hit some sort of chip download cycle limits and just need to replace the board?
I'm curious, Has anyone else experienced anything similar to this?
Ken Bash
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
" Anything worth doing... is worth overdoing. "
··············································· ( R.A.H. )
····································
I keep it connected to a laptop and simply modify the program when I need to change the program for a different part.
Every once in a while, possibly once in 50 – 100 times, I will download the program and instead of getting a normal “Home” sequence where all 5 axis drive back into their limit switches, my z and my x axis “Switch” somehow and the machine drives that switched axis into the “Wall” I have damaged some expensive tools a couple of times this way, but have learned to watch it and hit the kill switch early if it happens. I can immediately re-program the propeller, and often this “Switch-up” will be there again. However, if I kill the power to the machine, restart and re-program, it almost always works fine again.
Up until today, it hasn't been enough of a problem to rewrite my software for another controller or even replace the Proto Board I'm using.
However, today, for the first time that I am aware of, two axis switched operation IN THE MIDDLE OF A PROGRAM! ( or at least one axis was performing the movements called for by another axis. )
It worked fine for two layers, then I made a small (normal) tooling change, and when the system went to apply the next layer, my rotational axis was performing the movements of my X AXIS! There was no reset, no reprogramming or anything this time. It was as if something inside the chip simply routed both the step and direction signals to two other pins.
There are no other driver chips between the Propeller and the Compumotor drives,
1.The EXACT same program normally works fine. It makes me doubt that it is a software error.
2. I got two coats on first. This means that all 5 axis WERE working fine.
3. both the step AND direction signals were involved because the axis that was switched isn't required to move at all during that part of the program.
4.The port pins involved are not next to each other ( and wires run to different locations ) , so I doubt external signal coupling.
I haven't been terribly concerned with the occasional switched axis immediately after reprogramming, I could easily write that off to a transposed bit or something during program download, however, to have it occur in the middle of a program worries me. This board has easily been programmed 3 – 5 THOUSAND times. The EEPROM gave up the ghost long ago so I just download whenever I want to run it and run from ram.
I know that this continual re-programming isn't the “Normal” way of using a Prop. Is there a possibility that I hit some sort of chip download cycle limits and just need to replace the board?
I'm curious, Has anyone else experienced anything similar to this?
Ken Bash
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
" Anything worth doing... is worth overdoing. "
··············································· ( R.A.H. )
····································
Comments
It could be as simple as crosstalk between the communication lines to the motors. But I would be more inclined to take a look at the software. If you can, I would suggest posting it here, I am sure a few dozen extra eyeballs may be able to find if it is being caused by software.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!
Some of my objects:
MCP3X0X ADC Driver - Programmable Schmitt inputs, frequency reading, and more!
Simple Propeller-based Database - Making life easier and more readable for all your EEPROM storage needs.
String Manipulation Library - Don't allow strings to be the bane of the Propeller, bend them to your will!
Fast Inter-Propeller Comm - Fast communication between two propellers (1.37MB/s @100MHz)!
Second, whenever I've had crazy things like this happen, it's usually because I did not allocate enough memory for a method to work and things get out of whack.
I'm sure the experienced people on the forum will help you get to the bottom of this.
good luck!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Watching the world pass me by, one photon at a time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
It could be eeprom. It could be hash on the power supply rails.
It is hard to say without looking at the code, but if you have a variable that is not initialised, then mostly it will start at zero but not necessarily. Is the code 'complicated'?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I agree with you Bobb, I've designed the Propeller into medical test equipment and used it for quite a few other apps. as well. This is the ONLY chip/board/ combo that I've ever had the slightest problem with. I was even considering building an implantable version for an artificial heart I developed... ( I'm not looking forward to learning yet ANOTHER architecture, tools etc. ) If it wasn't for a fair amount of down-time to re-do the soldered to the board wiring... I would have replace it long ago.
This is the ONLY thing that has ever made me question the actual Propellers suitability for ANYTHING to do with control. I didn't notice this happening until I moved to a different lab and got a different laptop ( an old Toshiba ) as well. Another interesting thing is that there is often a compiler error message associated with the "Bad behavior" on the download reset thing. ( something to do with duplicate names in modules that have no reason to be duplicated or cause errors ) I'm using spin version 1.2.6 so I guess I should try 1.2.7 and see if that changes anything.
Like I said... the IMMEDIATE change just after download didn't bother me much, but watching it happen in the middle of a program spooks me a bit.
I just ran two more parts using the exact same software and they worked fine. ... so I still doubt it's software. I know... i know... I've thought that a dozen other times but I've done all the "Goose in the boat with the bag of grain.... etc" logical analysis on this and can't think of ANYTHING that would download and work great twice in a row... mess up midway through the third download then work fine again until I hold my tongue just right
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
" Anything worth doing... is worth overdoing. "
··············································· ( R.A.H. )
····································
however... that uninitialized variable stuff.... I'll look into it. It COULD be some power glitches, There's a machine shop next to my lab... but it's SO CONSISTENT... within it's particular randomness. I wouldn't expect it to fail the SAME way when it does fail. The only reason for this letter was it did it in the middle of a run this time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
" Anything worth doing... is worth overdoing. "
··············································· ( R.A.H. )
····································
My guess is glitches on the supply. Try a mains filter and TVSs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 7/22/2010 12:04:21 AM GMT
You said -- You not use EEProm any longer --- BUT have You removed it ??.
Then You said You maybe have problems with power that can cause reset else LapTop that can have problems and reset Yours Propeller board
>
> AND if You not removed EEProm in that cases START any OLD program that YOU have in EEProm.
It is only thing I can see in You description that can give that behavior.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Since you said it could be power, do you have the correct decoupling caps at the prop power pins? There is nothing in the prop itself that has a use issue like the eeprom. I would think there are possibly other things to check. The stack size could be one. As Sapieha said, the eeprom code could be reloading (a reset glitch). Can you get the eeprom to program at all - if so, try and program something simple like flashing a led into it so that if the prop is resetting you can easily tell and your program will stop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
LOL
I did pro cnc design, using fpgas- dsps and also 3 phase 220v custom drives.
You fry stuff eaisly or over time if you don't use many layers of protection.
a Schematic is most definitely needed here if you want some help.
You also stated you have a lot of complexity with "many blind alleys". This also lends credence to the software theory. If you had power issues you would most likely get a chip reset or it would just stop working. The fact that it "switches axis and performs actions for another axis" means the program is most like executing correctly, just not what you are expecting. Computers always do what we tell them so I'm putting my money on the fact that you are somehow telling the prop to switch axis, whether you realize it or not.
I suggest reorganizing your code and streamlining it if possible - remove your "blind alleys". All software benefits from refactoring - especially organically grown software.
Post Edited (soshimo) : 7/22/2010 8:01:59 AM GMT
Why on earth would you want to rewrite your software for another controller?
The Propeller is not a random number generator, it does exactly what it is programmed to do, nothing more, nothing less. It does not have mood swings or bad days. As far as I know nobody has found a bug in the Propeller's behaviour yet and that is unlikely to be the case here. Rewriting this application for another chip may well fix the problem, what with having a whole different system as a result. It may also introduce different problems...
No, start at the beginning. Are you even running the code you think you are running? Sounds like a silly question but as has already been pointed out if you have an EEPROM full of old code it is possible that it gets run sometimes.
That leads to the idea of power supply problems. The old EEPROM code will get run if there is a reset.
This statement of your worries me also: "Another interesting thing is that there is often a compiler error message associated with the "Bad behavior" on the download"
Given that your source code is always the same, I hope, and the compiler is always the same there is no way you should have a compiler error sometimes and not other times. This suggests to me that you are not even downloading the code that you think you are.
As for "divide and conquer", in a case like this I would want to be running the code on a different board with a different, reliable, power supply and away from any of the hardware it is normally attached to. Isolate the thing. I would try and set it up to run in a test harness. Supply the inputs from something other than the real system. Perhaps a software simulation. Observe and record the outputs by some other means than driving the motors. Run it continuously, reset it a thousand times. Try all kinds of inputs, expected and unexpected values. Try different timings of input events.
By the way, there is nothing not "normal" about continual re-programming the RAM. Think about it, that's what every PC and lap top does every time you boot it up. There is no meaningful limit on the number of times you can do this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Your compiler messages are the most weird thing about it. Compilation has nothing to do with the actual propeller. The fact that your computer isn't even staying consistent is a problem. Where does the prop get it's tool path? Is it hard coded in the program, or streamed from the pc, or what?
If you are using Euler, switch to quaternions. There is no gimbal lock problem with quaternions. You may have to add some smoothing though.