Stumpped!
RS_Jim
Posts: 1,768
I have been working on this concept for a servo using a stepper motor for about a week now. Must admit this is my first major undertaking in Spin. I normally work in PASM. when I enter a step count value of 1 to 99 all goes well. When I enter a value of 100 or above it crashes! What I mean by crash is the stepper momentarily hums loudly, steps 2-3 steps and stops. From there on, the data entry screens work fine but the stepper will step just 1 time and stop. When I use a fixed value for Value without keyboard entry the repeat loop works fine and the motor steps the required 100+ times.
Do I need to put the obj serv.step in a new cog? Why does it crash with a keyboard entered value and not with an entered constant?
Do I need to put the obj serv.step in a new cog? Why does it crash with a keyboard entered value and not with an entered constant?
CON
_clkmode = xtal1 + pll16x ' System clock → 80 MHz
_xinfreq = 5_000_000
con
RX1 = 31
TX1 = 30
SDA = 29
SCL = 28
XOUT = 7
YOUT = 6
con
#1, HOME, GOTOXY, #8, BKSP, TAB, LF, CLREOL, CLRDN, CR ' PST formmatting control
#14, GOTOX, GOTOY, CLS
_stack [ 65]
VAR
Byte Valstr
Long Value
Byte instr[49]
' Long tGrowth
OBJ
term : "FullDuplexSerialPlus_Plus" ' Variable & I/O display tool
rc : "RC_Time_ASM" ' RC Time is also an option
stepserv : "Jimsstepper"
nums : "Numbers"
' schematics : "Schematics" ' Circuit Schematics
' terms : "Terms of Use" ' Terms of use
PUB Main | idx ,tGrowth , adjust, x , y
' Set up Parallax Serial Termial display
term.start(RX1, TX1, %0000, 115_200) ' start serial
stepserv.start
nums.init
rc.start(1, 0, clkfreq/1_0000, clkfreq/2000, clkfreq/1000,@tGrowth)
waitcnt((clkfreq / 1_000)*2_000 + cnt)
term.tx(CLS)
term.str(string("Step Servo Test V1"))
term.str(String("Time Measurements units = 12.5 ns"))
term.tx(CR)
term.tx(LF)
term.str(string("----------------------------------------"))
prntStr(tGrowth)
waitcnt(clkfreq/10+ cnt)
repeat
'term.tx(CLS)
prntStr(tGrowth)
term.tx(CLREOL)
x :=0
bytefill (@instr,0,45)
repeat until x== "+" or x== "-"
term.tx(GOTOXY)
term.tx(20)
term.tx(4)
term.str(string(" Enter + or - "))
x := term.rx
term.str(string("Enter number of steps "))
term.tx(CLREOL)
term.getstr(@instr[0])
Value := nums.FromStr(@instr[0],%1010)
term.tx(CLRDN)
dec3(Value)
term.str(string(" "))
repeat idx from 0 to value
IF x == "+"
stepserv.HalfstepFwd
Else
stepserv.HalfstepRev
waitcnt(clkfreq/100+ cnt)
idx++
dec3(idx)
term.str(string(" "))
term.str(string(" done "))
waitcnt(clkfreq/10+ cnt)
Pub prntStr(n)
term.tx(GOTOXY)
term.tx(0)
term.tx(4)
term.str(String(" Servo Position "))
dec3(n)
pub dec2(n)
if (n < 10)
term.tx("0")
term.dec(n)
pub dec3(n)
if (n < 10)
term.tx("0")
if (n < 100)
term.tx("0")
term.dec(n)
PUB pause(ms) | c
c := cnt ' sync with system counter
repeat until (ms-- == 0) ' repeat while time left
waitcnt(c += clkfreq / 1000) ' wait 1 ms
Comments
Have you debugged Value to verify what it is after keyboard entry? I would recommend debugging what Value is after entering 100 manually.
Thanks for quick reply.
The line "dec3 (Value) is the debug line and it prints the exact same number that I input Value from the terminal or when I equate Value to a constant. I also use code later down to display the value of idx on each iteration of the loop. Though it only displays every other value of idx (1..3..5..7 etc.) it is reaching the correct end Value. I am going to start setting up jimstepper as a seperate cog and try to do it in PASM. I am going to try to synchronize full and half steps so that I can switch between them on the fly to speed up or slow down the step rate with out crashing the motor. I will probably pass to it info to give it step direction and type ie "a" half step forward "b" full step forward, "c" halfstep reverse. FYI the motor is the Parallax stepper driven by a ULN2003 and using an 88 theeth 48 pitch gear on the pot. By the way, on the spec sheet for that motor it says theholes are 4-40 I think they are metric 3-50'
Jim
So anyway with a value like 9 or 99 steps it ends on that idx value, however entering 100 causes it to go to 101. I would recommend taking out the Idx++ statement. For me that seems to fix the counting issue as you're not adding an extra count every pass through the loop, skipping values. Let me know what happens.
You might want to look through the object "Numbers". It has methods you recreate in your program (zero padding).
I ought to take my own advice. I saw several methods that I frequently add to my programs (only my methods don't look as nice as the ones in "Numbers").
Duane
Ok I removed the idx++ and that solved the skip step issue. However, when Value goes over 100 from keyboard entry the program goes off in a strange direction. I don't have the program with me at the moment but when I do, I will archive it and attach.
Duane, I will be blowing the dec away once I have the bugs worked out, but I will look more closely at numbers.
Thanks for looking into things.
Jim
52
57
13
0
As you can see the 13 (Carriage Return) is now part of the value. I'm not sure why the count still comes out right, but this is not what is expected. I contacted the author regarding FullDuplexSerialPlus and he says that this object is obsolete and was known to be buggy and that customers should be using the replacement object included in the Propeller Library called, "Parallax Serial Terminal.spin". Please note there are a few differences, for example getstr() is now StrIn().
Let me know if this solves your problems Jim, and sorry for the delays, but this one was a tough one for sure.
Try changing:
term.getstr(@instr[0]) Value := nums.FromStr(@instr[0],%1010)to:
The method "FromStr" in numbers is to complicated for me to follow.
I could understand the "getdec" method in FullDuplexSerialPlus. It should ignore the carriage return character.
I haven't tried this but my gut is telling me it should work. (Either that or I'm hungry.)
Duane
Duane,
I think you're just hungry since GetDec doesn't require parameters.
Edit: I forgot to mention that was one of the first things I tried, but alas the code still goes wonky for timing when using this.
I blame this (my mistake, not the lack of parameters in GetDec) on low blood sugar.
Duane
The repeat loop that you have starting with "0" and ending at the number that you give it will always increment an additional Half step. i.e. 0 to 100 is actually 101 positions
PUB getstr(stringptr) | index '' Gets zero terminated string and stores it, starting at the stringptr memory address index~ repeat until ((byte[stringptr][index++] := rx) == 13) [COLOR="red"]byte[--index]~[/COLOR]That should read (taken from FullDuplexSerialPlus):PUB getstr(stringptr) | index '' Gets zero terminated string and stores it, starting at the stringptr memory address index~ repeat until ((byte[stringptr][index++] := rx) == 13) byte[COLOR="orange"][stringptr][/COLOR][--index]~Thanks for all your hard work in tracking down the source of the problem. I changed from FullDuplexSerailPlus_Plus to Parallax Serial Terminal, and after a bunch of edits to correct the interface to the new terminal all works well! I now have to carry this information into my PASM stepper driver. I wonder if I was passing trash to it as well. I did find out along the way that my prop tool was out of date and I had to up grade it along the way.
Kuroneko,
Thanks for pointing out the bug in FullDuplexSerialPlus_Plus, I will go on a search and destroy mission to remove all copies of it from my systems.
In some quick testing of the system, it appears for this to work accurately, I may have to revert to using an ADC to handle the post values quickly enough.
I can now change the status of this post to solved.