3D Printer Firmware In Spin.
davidsaunders
Posts: 1,559
I am in the process of doing a complete rewrite of my 3D printer firmware for the Propeller in SPIN.
The original was written almost completely in PASM, and was only sparsely commented. I am rewriting it in SPIN to make it easier for others to deal with. I am also commenting as I go, so it is easier for others to understand.
The goals at present are:
1: Use a total of 6 or fewer cogs.
2: Use less than 24 pins total (going to attempt to keep the HW close to original, a few needed changes).
3: Use only hub ram for buffering (no more external SRAM, or EEPROM required)
4: Use as little PASM as possible.
5: Use less than 8KB for the code that is to be in hub RAM (leaving the rest for a command buffer).
The design features for this firmware:
1: Must control 3 Steppers through ULN2803's.
2: Must handle one continuous rotation servo, for feeding the filament.
3: Will have the One Pin TV Text object for status display over NTSC.
4: Use PWM to control the heating element.
5: Monitor 3 contact switches for zero limit on X, Y, and Z. This is done with a single pin.
6: Must be easy to update.
7: Using serial communication in a single cog to receive commands, and send an ack+OK, or error as needed back. This will require PASM, sorry.
Status as of now:
The 3D printer is still running the original code.
I have almost completed the Stepper control and zero switch sensor code, these are run on the same COG.
I have nearly completed the Servo and heating element control. These use a single cog.
I am still figuring a few things out for the remaining portions. I am think about abandoning G-Code on the controller board, and using a host system program for that instead, any input is welcome.
MORE:
I will be posting the code in this thread as each section is completed. Much of it will be posted untested as it is largely reliant on other sections. I will be making heavy use of debug output on the NTSC display once it is all together.
I decided to post this thread before the rewrite is usable, in response to idbruce giving up on TeaCup.
Files:
Currently these are untested, these are the Objects in SPIN that are close to complete. There may be errors that I overlooked, if so please reply to the thread letting me know. The files are attached:
The original was written almost completely in PASM, and was only sparsely commented. I am rewriting it in SPIN to make it easier for others to deal with. I am also commenting as I go, so it is easier for others to understand.
The goals at present are:
1: Use a total of 6 or fewer cogs.
2: Use less than 24 pins total (going to attempt to keep the HW close to original, a few needed changes).
3: Use only hub ram for buffering (no more external SRAM, or EEPROM required)
4: Use as little PASM as possible.
5: Use less than 8KB for the code that is to be in hub RAM (leaving the rest for a command buffer).
The design features for this firmware:
1: Must control 3 Steppers through ULN2803's.
2: Must handle one continuous rotation servo, for feeding the filament.
3: Will have the One Pin TV Text object for status display over NTSC.
4: Use PWM to control the heating element.
5: Monitor 3 contact switches for zero limit on X, Y, and Z. This is done with a single pin.
6: Must be easy to update.
7: Using serial communication in a single cog to receive commands, and send an ack+OK, or error as needed back. This will require PASM, sorry.
Status as of now:
The 3D printer is still running the original code.
I have almost completed the Stepper control and zero switch sensor code, these are run on the same COG.
I have nearly completed the Servo and heating element control. These use a single cog.
I am still figuring a few things out for the remaining portions. I am think about abandoning G-Code on the controller board, and using a host system program for that instead, any input is welcome.
MORE:
I will be posting the code in this thread as each section is completed. Much of it will be posted untested as it is largely reliant on other sections. I will be making heavy use of debug output on the NTSC display once it is all together.
I decided to post this thread before the rewrite is usable, in response to idbruce giving up on TeaCup.
Files:
Currently these are untested, these are the Objects in SPIN that are close to complete. There may be errors that I overlooked, if so please reply to the thread letting me know. The files are attached:
Comments
'This provides PWM based control of one servo, and PWM control of one heating element. 'This code is based losely on the parallax Servo Example code. CON ServoPin = 13 HeatingPin = 14 VAR LONG HeatTime,IncTmp,Cycle,SrvTime,t PUB Init ctra[30..26] := %00100 ctra[8..0] := ServoPin ctrb[30..26] := %00100 ctrb[8..0] := HeatingPin PUB SrvMov(S) 'S must be in the range of -200 to 200. 'S is the speed for a continous rotation servo, ' or the angle for a standard servo. IncTmp := clkfreq/1_000_000 Cycle := IncTmp * 21_500 SrvTime := IncTmp * (1500+S) t := cnt PUB HeatLvl(H) 'H must be between 0 and 100. 100 is max heat, and equal to 50% 'duty cucle. HeatTime := clkfreq/(100*H) PRI DoIt 'This procedure runs by itself on a COG. 'Just prerforms the output repeatedly, for both the Heating element, and the servo. repeat phsa := -SrvTime phsb := -HeatTime t += Cycle waitcnt(t) DATI will be adding more comments, and giving it another look over.
I just threw this together in 10 minutes, so it may contain errors that I over looked.
Please point out any error, or anything you see that can be done better. The same for any code I post, please.
Sorry for the embarrassing error, it has been corrected (I think, a quick throw together).
Did you want to use both A and B counters in "DoIt"? I see phsa is set twice.
Thank you.
Just have to put in the negative direction stepping, and I will be good to post it.
Stepper.spin
'This is a simple stepper motor controler for a three axis device like a 3D printer. 'We are only using full stepping for this one. CON xBPin = 0 'Base pin for X axis stepper. yBpin = 4 'Base pin for Y axis stepper. zBpin = 8 'Base pin for Z axis stepper. zrPin = 12 'Zeroing switch input. MxSpd = 512 'Max steps per second for X axis. MySpd = 512 'Max steps per second for Y axis. MzSpd = 1024 'Max steps per second for Z axis. xMax = $7FFFFFFF 'Furthest from zero allowed for X axis. yMax = $7FFFFFFF 'Furthest from zero allowed for Y axis. zMax = $7FFFFFFF 'Furthest from zero allowed for Z axis. VAR LONG xCur,yCur,zCur 'The current positions of the axises from zero. LONG XR,YR,ZR LONG m 'Used in some local calculations. LONG zSpd,ySpd,xSpd PUB Init 'Set the Stepper control pins to outputs, and the zero sensor pin to an input. DIRA[11..0]~~ DIRA[12] := 0 zSpd := 128 ySpd := 128 xSpd := 128 PUB AllStop 'Stop all three steppers, and release OUTA[0..11] := 0 PUB FwdX(D,S) 'Move the X axis stepper D steps at S steps per second. m := D if S > xSpd S := xSpd if (m + xCur) > xMax m := xMax - xCur REPEAT m := m - 1 XR := (xCur + 1) // 4 OUTA[0..3] := cStep[XR] waitcnt(clkfreq/S + cnt) while m => 0 PUB FwdY(D,S) 'Move the Y axis stepper D steps at S steps per second. m := D if S > ySpd S := ySpd if (m + zCur) > yMax m := yMax - yCur REPEAT m := m - 1 YR := (xCur + 1) // 4 OUTA[4..7] := cStep[YR] waitcnt(clkfreq/S + cnt) while m => 0 PUB FwdZ(D,S) 'Move the Z axis stepper D steps at S steps per second. m := d if S > zSpd S := zSpd if (m + zCur) > zMax m := zMax - zCur REPEAT m := m - 1 ZR := (zCur + 1) // 4 OUTA[8..11] := cStep[ZR] waitcnt(clkfreq/S + cnt) while m => 0 PUB BckX(D,S) m := D if S > xSpd S := xSpd if (xCur - m) < 0 m := xCur REPEAT m := m - 1 XR := (xCur - 1) // 4 OUTA[0..3] := cStep[XR] waitcnt(clkfreq/S + cnt) while m => 0 PUB BckY(D,S) m := D if S > ySpd S := ySpd if (zCur - m) < 0 m := yCur REPEAT m := m - 1 YR := (xCur - 1) // 4 OUTA[4..7] := cStep[YR] waitcnt(clkfreq/S + cnt) while m => 0 PUB BckZ(D,S) m := d if S > zSpd S := zSpd if (zCur - m) < 0 m := zCur REPEAT m := m - 1 ZR := (zCur - 1) // 4 OUTA[8..11] := cStep[ZR] waitcnt(clkfreq/S + cnt) while m => 0 PUB StpLine(Xa,Xb,Ya,Yb,S) 'calculate an angled line and move along 'the X,Y axis to describe the line. DAT 'The states of a the four pins to control a steper in forward order. cStep BYTE %0011, %0110, %1100, %1001NOTE:I need to insert the delays to keep the speed in check. I forgot to do so before posting.
I also need to add the check for the zeroing switch between steps.
This would be a lot easier if I still had the PASM code of the original as a reference. Though that is lost, so this is a from scratch rewrite. I have written a lot more than I posted, including three different variants of what I posted (just posting the versions I think I will end up using).
It seems that each time I post, I manage to leave out something important in the source, that I realize I left out after I post.
'This is a simple stepper motor controler for a three axis device like a 3D printer. 'We are only using full stepping for this one. CON xBPin = 0 'Base pin for X axis stepper. yBpin = 4 'Base pin for Y axis stepper. zBpin = 8 'Base pin for Z axis stepper. zrPin = 12 'Zeroing switch input. MxSpd = 512 'Max steps per second for X axis. MySpd = 512 'Max steps per second for Y axis. MzSpd = 1024 'Max steps per second for Z axis. xMax = $7FFFFFFF 'Furthest from zero allowed for X axis. yMax = $7FFFFFFF 'Furthest from zero allowed for Y axis. zMax = $7FFFFFFF 'Furthest from zero allowed for Z axis. VAR LONG xCur,yCur,zCur 'The current positions of the axises from zero. LONG XR,YR,ZR LONG m 'Used in some local calculations. LONG zSpd,ySpd,xSpd PUB Init 'Set the Stepper control pins to outputs, and the zero sensor pin to an input. DIRA[11..0]~~ DIRA[12] := 0 zSpd := 128 ySpd := 128 xSpd := 128 PUB AllStop 'Stop all three steppers, and release OUTA[0..11] := 0 PUB FwdX(D,S) 'Move the X axis stepper D steps at S steps per second. m := D if S > xSpd S := xSpd if (m + xCur) > xMax m := xMax - xCur REPEAT m := m - 1 XR := (xCur + 1) // 4 OUTA[0..3] := cStep[XR] waitcnt(clkfreq/S + cnt) WHILE m => 0 PUB FwdY(D,S) 'Move the Y axis stepper D steps at S steps per second. m := D if S > ySpd S := ySpd if (m + zCur) > yMax m := yMax - yCur REPEAT m := m - 1 YR := (xCur + 1) // 4 OUTA[4..7] := cStep[YR] waitcnt(clkfreq/S + cnt) while m => 0 PUB FwdZ(D,S) 'Move the Z axis stepper D steps at S steps per second. m := d if S > zSpd S := zSpd if (m + zCur) > zMax m := zMax - zCur REPEAT m := m - 1 ZR := (zCur + 1) // 4 OUTA[8..11] := cStep[ZR] waitcnt(clkfreq/S + cnt) while m => 0 PUB BckX(D,S) m := D if S > xSpd S := xSpd if (xCur - m) < 0 m := xCur REPEAT m := m - 1 XR := (xCur - 1) // 4 OUTA[0..3] := cStep[XR] HPn := INA[zrPin] 'Check for zero switch, and stop if detected. IF HPn > 0 IF xCur <> 0 xCur := 0 RETURN waitcnt(clkfreq/S + cnt) while m => 0 PUB BckY(D,S) m := D if S > ySpd S := ySpd if (zCur - m) < 0 m := yCur REPEAT m := m - 1 YR := (xCur - 1) // 4 OUTA[4..7] := cStep[YR] HPn := INA[zrPin] 'Check for zero switch, and stop if detected. IF HPn > 0 IF yCur <> 0 yCur := 0 RETURN waitcnt(clkfreq/S + cnt) while m => 0 PUB BckZ(D,S) m := d if S > zSpd S := zSpd if (zCur - m) < 0 m := zCur REPEAT m := m - 1 ZR := (zCur - 1) // 4 OUTA[8..11] := cStep[ZR] HPn := INA[zrPin] 'Check for zero switch, and stop if detected. IF HPn > 0 IF zCur <> 0 zCur := 0 RETURN waitcnt(clkfreq/S + cnt) while m => 0 PUB StpLine(Xa,Xb,Ya,Yb,S) 'calculate an angled line and move along 'the X,Y axis to describe the line. DAT 'The states of a the four pins to control a steper in forward order. cStep BYTE %0011, %0110, %1100, %1001 {{ ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ TERMS OF USE: MIT License │ ├──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ │Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation │ │files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, │ │modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software│ │is furnished to do so, subject to the following conditions: │ │ │ │The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.│ │ │ │THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE │ │WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR │ │COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, │ │ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. │ └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ }}If you see any errors please let me know. If you see anything that can be improved please point it out.Thank you. I hope that each object I post can benefit from the Propeller comunity, before the project is done. As I will put the entire project in the OBEX once it has been tested to be good enough.
I am attempting to make everything in this new code as generic as possible, so that it can be easily modified, as well as not needing to re-upload if the scale or similar is off (that was a problem with the old PASM version).
'Command processor. 'This uses a simple set of byte commands. {The Commands are in the upper nibble of the first byte of each command, each command it two bytes long. The commands are: 1 = Move X, forward. 2 = Move Y forward. 3 = Move Z forward. 4 = Move X reverse. 5 = Move Y reverse. 6 = Move Z reverse. D = Set current feed rate. E = Set Heat. F = Extended commands. F0 = All Stop. F7 = Set current X position as Zero (for manual zeroing [no zero switch]) F8 = Set current Y position as Zero (for manual zeroing [no zero switch]) F9 = Set current Z position as Zero (for manual zeroing [no zero switch]) FA = Zero X. FB = Zero Y. FC = Zero Z.I am redoing it in SPIN for two reasons.
1: I lost the PASM source in my RPi failure.
2: For many people that are new to the Prop SPIN is easier to understand. And I am doing this project in part to lower the entry barrier for people to get into 3D printing (using home built 3D printers).
There are still a few things that have to be in PASM, like the single COG serial and one pin tv text. Though I am attempting to keep as much as possible in SPIN.
I do not know if I will include a G-Code interpreter in the new version or not. I may just do the G-Code to native command processing on the host system. This would save a COG and eliminate the small buffer for unconverted incoming G-Code. i will decide on that once I get far enough to know how much HUB memory everything else takes up.
I have decided that once I finish the native command interpreter I will rewrite everything in PASM. I will continue both variants, thus giving a complete set of firmware in PASM, and another in SPIN.
If there is a C compiler for the Prop that compiles to pure COG code only, I may end up doing a rewrite with that C variant. Though the only C compilers I know of for the Propeller use extended memory of some form for code (the very reason I do not use C on the propeller).
Where can I find the source of OpenSpin, and what are the dependancies? The same question for any open source Propeller Loader software?
I ask as My Raspberry Pi's decided to start working again (at least in RISC OS), and I would like to get back to saving power. So I wish to port these programs to RISC OS.
OpenSpin: https://github.com/parallaxinc/OpenSpin
p1load: https://github.com/dbetz/p1load
Actually, all of the Parallax tools are open source except for the Propeller Tool.
If it is compatible with the compiler things will be great. Then I will only have to modify the file system handling stuff, as RISC OS uses the "." (period) character as the directory separator, and the "/" character for extensions (only for compatible with file names from other OSes, RISC OS uses a file type in the directory metadata for identifying filetypes). I will let you know when I attempt to compile it.
For the rest of today, I am looking at what has been done with the Prop 1 verilog implementation. I had not previously looked at it.
If you are doing a project that you know will have two forms, that feature of PropGCC sound well worth a close look.
That allows a much higher level control over what runs in Assembler inside a COG, and what runs slower outside the COG.
There was no standard back then. The thing I do not understand is why most systems ended up using file extensions to track file types, the system of metadata in the FS makes more sense (like used in RISC OS, BeOS/Haiku-OS, Macintosh System Software, ProDOS, etc). Though things did not work out for what makes the most since, it worked out for who had the best marketing.
I have always thought so. But, we ended up with a lot of data management in file names anyway. File name, author, purpose, revision, format, and all sorts of stuff has ended up crammed in there. Also "final" lol Even more funny, "finalfinal"
8 bit computers showed some of this divergence. Apple 8 bit computers employed long names, spaces and who knows what else were permitted. Was pretty common to CATALOG a disk and get, "THAT THING RICH WROTE LAST WEEK IT IS COOL RUN IT WITH..." sigh
A file type was there to classify data and help identify which programs would handle which files. Atari, Tandy, and others went 8.3 and didn't have this metadata. Some systems used drive letters, others used volume identifiers... Was a total mess back then.
Of course, having a database as filesystem is out there. Some cloud things are using it, so there aren't files anymore! Just objects. Of course, you can ask for them to be packed into a file, so whatever.
I really liked long names and the metadata because I really didn't like little, stubby extensions having to represent so many things.
And they got overloaded too. How many CAD systems centered in on .prt, for example? Pretty much all of them. Then, everybody seemed to abandon just three characters about the same time... We got .jpg .jpeg .stp .step .myownextensionsothere and so on... Moving stuff from IRIX to a PC saw problems like that, until Windows got a bit smarter and the longer extensions made sense.
Of course, UNIX. Multiple dots, multiple extensions .tar.gz ?
Paths... On short file name systems, we got ugly paths, because people like stuffing all sorts of stuff into the name! /user/doug/project/idea/version/final/reallyfinal/test.txt.tar.gz Yeah. Love those.
I'm sure some clown somewhere made the program the file name too. Somehow.
Blocks are nice. Just blocks. Lots of blocks. But of course, we've got block freaking SIZES! Big blocks, little blocks. Contiguous blocks, non contiguous blocks. Bad blocks. Deliberately bad blocks. (thanks guys, for that one)
And then case insensitivity. Either allow case or don't. Hate that one.
So it is a total mess! Just like time is a total mess. Simple time is simple. Anything else? Takes a whole ton of time just to understand how to properly handle time. Ugh.
This is just what humans seem to do. We are so screwed. Really.
I always wondered where all that metadata was supposed to come from.
Where it comes from is simple. The real question is what do we actually care about and where do we put it, what do we call it, etc???