Stops GOSUBing
Newzed
Posts: 2,503
I have a program for my MF70 mill that etches to top side of a board.· I have attached the program for the slot where I have the problem.
The program comments indicate that at j the·debug screen·indicates travel and gives the new X-Y position, but the spindle does not move in the Y direction.· At this point I switch to manual operation and the Y travel is OK.· Up to this instruction I have called a GOSUB maybe 120 times for the entire 7 slot program.· The Help file says on the BS2E, ·I can call a GOSUB 256 times.
Could I have a bad BS2E?· Where are the GOSUB addresses stored in the Stamp?
Sid
The program comments indicate that at j the·debug screen·indicates travel and gives the new X-Y position, but the spindle does not move in the Y direction.· At this point I switch to manual operation and the Y travel is OK.· Up to this instruction I have called a GOSUB maybe 120 times for the entire 7 slot program.· The Help file says on the BS2E, ·I can call a GOSUB 256 times.
Could I have a bad BS2E?· Where are the GOSUB addresses stored in the Stamp?
Sid
Comments
The programming style you're using is very inefficent -- I think that's more the problem than a possible dead bad Stamp (btw, RETURN addresses actually get compiled into the program, they are not stored on any kind of stack [noparse][[/noparse]there's not enough RAM to do that]).
What I suggest you do is recode you program such that the values for "f" (I think·that's for the distance of a move)·and the move you want to make get stored in a table like this:
Pattern1··· DATA··· 4··································' number of moves in this pattern··
········· · DATA··· Word 376, "I"
········· · DATA··· Word 100, "L"
········· · DATA·· ·Word·400, "O"
·········· ·DATA·· ·Word· 95, "R"
Note that the table uses three bytes per entry: two for the distance (even when less than 256), one for the command.· Now you can use a simple loop to handle the table data:
· eePntr = Pattern1
· GOSUB Make_Moves
· ...
Make_Moves:
··READ eePntr, numMoves······························· ' get number of moves from table header
· eePntr = eePntr + 1··································' point to first record
· DO WHILE (numMoves > 0)····························· ' loop through number of moves
··· READ eePntr, Word distance, theMove··············· ' retrieve distance and direction from table
··· LOOKDOWN theMove, [noparse][[/noparse]"IOLR"], theMove··············· ' convert letter command to·value, 0..3
··· ON theMove GOSUB Go_In, Go_Out, Go_Left, Go_Right· ' call the move code
··· eePntr = eePntr + 3······························· ' point to next record
··· numMoves = numMoves - 1··························· ' update moves count
· LOOP
· RETURN
With this strategy you can recode new move patterns quite easily.
Yes, I know you're an "old dog" , but you've certainly proved you can learn new tricks.· You might try using "The Elements of PBASIC Style" formatting guidelines in your programs as well -- it will make them easier for others (and you) to read and debug.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
I made the following changes:
Added a couple of lines after GOSUB Make_Moves so I could return to slot 0.
Changed WORD DISTANCE to WORD f, since f is the variable that the travel routines use.
Added a line after eePntr = eePntr + 3 to provide a cooling down stop for the spindle.
Sid
Personally, I wouldn't hard-code the "advise" condition -- it looks like you want to do that every 25 moves or so; just put another counter in the loop and mod that by 25.· If the result is zero then you run the advise code:
···coolChk = cookChk + 1 // 25
·· IF (coolChk = 0) THEN
···· ' advise code or call to it here
·· ENDIF
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Post Edited (Jon Williams (Parallax)) : 9/17/2005 8:26:10 PM GMT
I'll probably run it in the morning.· Once started, the program has to run to completion and its getting a bit late in the day to start.· And I still have to load it into a memory stick, then go out to the shop and reload the laptop.
Sid
Jon·wrote "DO WHILE (numMoves > 0)"
I finally figured out that when numMoves = 0 the loop terminates, leaving the last DATA statement unread.· I tried several things but couldn't fix it, so finally I increased numMoves from 60 to 61 and duplicated the last
Data statement.· Now it executes the next to last DATA statement, which puts the spindle where it should be, and the program terminates.
Is there a better way to do this?· I have atached the curent code.
I have to leave the "GOSUB Advise" as it was, because the pause for cooling is called depending on how long the spindle has been running.· There is no set rep rate.
Sid
· FOR idx = 1 TO numMoves
··· ' read and process a step
· NEXT
It occurred to me that with DO-LOOP there was no need to use the extra varialbe.· I use this little test program to prove that the loop logic would count properly.· Try it for yourself.
numMoves······· VAR···· Byte
Reset:
· numMoves = 4
Main:
· DO·WHILE (numMoves·> 0)
··· DEBUG "numMoves = ", DEC numMoves, CR
··· PAUSE 100
··· numMoves = numMoves - 1
· LOOP
· END
You'll see the DEBUG window count down 4, 3, 2, 1.· Maybe you miscounted your steps.
I still think there is a "better" way to do the "Advise" code.· Perhas you could add a counter that keeps track of how far the spindle has moved (just add the distance value after you read it from the table) and when it reaches a given threshold you do the cool-down subroutine.· See the attached simulation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Post Edited (Jon Williams (Parallax)) : 9/18/2005 11:07:48 PM GMT