Still working to catch up -- compiled libArduino libfdserial libsimpletext -- compiled with warnings -- creating both cmm and lmm -- in all three -- followed instructions from #10
Do we need to compile these libraries using Compiler Type C or C++ ?
Also, to get on right page -- Multiple Questions -- perhaps someone can help me set correct Project Options, Compiler Options, and Linker Options in SimpleIDE ?
Maybe someone could post the compiler line they are using -- from inside SimpleIDE -- I pointed to the correct library files but it seems to still use the ones under "My Documents"
propeller-elf-gcc.exe -v GCC 4.6.1 (propellergcc_v1_0_0_2162) -- NOT THIS LINE -- THE NEXT
Do the above settings and compiler switches seem normal -- are they the same as yours ?
Also,
I used whatever was set in SimpleIDE Project file -- but I may need to set each --- I used Compiler 32-bit Double and Linker Create Project Library
Do I need to select a certain Board Type in Project Options ? I want to follow for PropASC here -- I do not see PropASC in Board Type options
Do I need to have the board connected ? Can I use Prop BoE just as well ?
On to tonokip_with_serial.c
Now my typedef enum { false, true } bool; causes --> error: expected identifier before numeric constant -- this worked before and now does not
Next
When I compile tonokip_with_serial.c -- do I do so as C or C++ ? -- project file gives warning when C++ used --> cc1plus.exe: warning: command line option '-std=c99' is valid for C/ObjC but not for C++ [enabled by default]
Still working to catch up -- compiled libArduino libfdserial libsimpletext -- compiled with warnings -- creating both cmm and lmm -- in all three -- followed instructions from #10
Do we need to compile these libraries using Compiler Type C or C++ ?
To get on right page -- Multiple Questions -- perhaps someone can help me set correct Project Options, Compiler Options, and Linker Options in SimpleIDE ?
I used whatever was set in SimpleIDE Project file -- but I may need to set each --- I used Compiler 32-bit Double and Linker Create Project Library
Do I need to select a certain Board Type in Project Options ? I want to follow for PropASC here -- I do not see PropASC in Board Type options
Do I need to have the board connected ? Can I use Prop BoE just as well ?
On to tonokip_with_serial.c
Now my typedef enum { false, true } bool; causes --> error: expected identifier before numeric constant -- this worked before and now does not
Next
When I compile tonokip_with_serial.c -- do I do so as C or C++ ? -- project file gives warning when C++ used --> cc1plus.exe: warning: command line option '-std=c99' is valid for C/ObjC but not for C++ [enabled by default]
Thank you. I was just about to post an update that I used C++ for tonokip_with_serial.c and all errors went away except for error about typedef enum { false, true } bool;
firmware.h:64:2: warning: #warning "PropellerASC not defined yet" [-Wcpp]
firmware.h:4:16: error: expected identifier before numeric constant
firmware.h:4:16: error: expected '}' before numeric constant
firmware.h:4:16: error: expected unqualified-id before numeric constant
firmware.h:4:28: error: expected declaration before '}' token
Then build stops
How did you solve 'bool' problem ? do you remember ? I see no posts about this -- I thought it _was_ working -- the 'bool' solution that is
I'm not sure where firmware.h comes from. Part of the original package maybe?
I think tonokip_with_serial.c replaces firmware.c
bool is a type in C++ ... just remove that line no?
The Serial code builds (and works afaik) in the project I posted.
propeller-elf-gcc.exe -v GCC 4.6.1 (propellergcc_v1_0_0_2408)
propeller-elf-c++ -I . -L . -I ./library/libArduino -I ./library/libfdserial -I ./library/libsimpletext -L ./library/libArduino/cmm/ -L ./library/libfdserial/cmm/ -L ./library/libsimpletext/cmm/ -o cmm/tonokip_with_serial.elf -Os -mcmm -Wall -m32bit-doubles -fno-exceptions -fno-rtti -DMOTHERBOARD=PropellerASC -fpermissive -ffunction-sections -fdata-sections -Wl,--gc-sections tonokip_with_serial.c -lfdserial -lsimpletext -lArduino -lfdserial -lsimpletext -lfdserial
In file included from tonokip_with_serial.c:6:0:
pins.h:5:2: warning: #warning "PropellerASC not defined yet" [-Wcpp]
tonokip_with_serial.c: In function 'void kill(byte)':
tonokip_with_serial.c:611:12: warning: statement is a reference, not call, to function 'disable_x' [-Waddress]
tonokip_with_serial.c:611:12: warning: statement has no effect [-Wunused-value]
tonokip_with_serial.c:612:12: warning: statement is a reference, not call, to function 'disable_y' [-Waddress]
tonokip_with_serial.c:612:12: warning: statement has no effect [-Wunused-value]
tonokip_with_serial.c:613:12: warning: statement is a reference, not call, to function 'disable_z' [-Waddress]
tonokip_with_serial.c:613:12: warning: statement has no effect [-Wunused-value]
tonokip_with_serial.c:614:12: warning: statement is a reference, not call, to function 'disable_e' [-Waddress]
tonokip_with_serial.c:614:12: warning: statement has no effect [-Wunused-value]
propeller-load -s cmm/tonokip_with_serial.elf
propeller-elf-objdump -h cmm/tonokip_with_serial.elf
Done. Build Succeeded!
I just put everything in one header file so that I only have to deal with two files
I can see that your compiler switches line is much shorter than mine.
Yours is below -- mine is posted earlier -- and -- it seems to have gotten longer once I made sure your SIDE --> Project, Compiler, Linker Pptions were the same -- seems some items duplicated
propeller-elf-c++ -I . -L . -I ./library/libArduino -I ./library/libfdserial -I ./library/libsimpletext -L ./library/libArduino/cmm/ -L ./library/libfdserial/cmm/ -L ./library/libsimpletext/cmm/ -o cmm/tonokip_with_serial.elf -Os -mcmm -Wall -m32bit-doubles -fno-exceptions -fno-rtti -DMOTHERBOARD=PropellerASC -fpermissive -ffunction-sections -fdata-sections -Wl,--gc-sections tonokip_with_serial.c -lfdserial -lsimpletext -lArduino -lfdserial -lsimpletext -lfdserial
It does not seem that easy in SimpleIDE to define new clean project and then add everything -- still looking in to this
Finally,
I wonder if I have the same Serial.cpp and Serial.H file as you -- I can see that they both have April 9, 2014 dates on Google code
Now that I am more up to speed, I hope that I can help.
IMO, the entire 3D Printing DIY (or maker community) has evolved past the point of teaching anyone about the growth of the firmware -- I am not upset about this -- it just seems so. I believe that is more and more apparent as time goes by -- and -- the posts in this thread seem to support my beliefs about this. For example, just figuring out the workings of Teacup versus Tonokip.
One person -- for example -- has determined that one version of the firmware -- dont remember which -- has many files that simply support the many types of Arduino boards and/or shields. As everyone here knows, this is difficult to figure out when you are just trying to get the basics figured out --and --- then trying to implement just the basics
So, beyond helping on this, I think we should establish "milestones" as we go -- as Loopy, Jazzed, and Brian_B, etc. go -- so, we create a sort of tutorial about this -- where things get added in stages -- and each stage works -- just adds new functionality, perhaps -- or corrects code for efficiency. Maybe you guys disagree. Maybe you had the same idea. I just want to help and I believe that my C experience and the fact that I have some time for a month or so, will benefit some now.
For the record, I do not want any credit for this -- I do not want anyone who has started on this to think that I am trying to usurp their efforts -- I just want to help create a solution that other can understand
@vtee2014
Welcome !!!
I am now reworking Tonokip_with_serial with all the i/o configurged for the PropellerASC. I am happy to see you are interested in the code.
The i/o pins were a bit sloppy for testing and verification as they were using an Arduinio configuration. I have also pulled out all the Arduino hardware references and included a heading that states that the files are adapted for the Propeller.
The ThermistorTable.h doesn't need any revision for now, but other firmwares list quite a few alterantive tables. Tonokip only provides one list of 20 items.
I am attaching the revisions for you reference. This is a bit piecemeal as I am not provided a full zip. It is up to you if you want to swap them out or use what you have. There is only one motherboard and it is now the PropellerASC+ designated as 0
This housekeeping should have been done some time ago, but better late than never.
I am also the originator of Tonokip_with_serial_without_kill as the Kill( ) seemed unfinished as was generating error reports in the compile. But, I am once again trying to just make the Tonokip_with_serial work completely as it is supposed.
I am not at all knowledgible in C and worse with C++, so you may very well discover somethings I have overlooked. I have been jumping around quite a bit to gain background knowledge by reading the Teacup.zip, and other GITHUB zips for 3D printing. Also I have found GRBL to be very well explained, so I have been reading that to get a better idea of what the more advanced CNC and 3D stepper control from g-codes should do.
Of course all that can be distracting, SO for NOW... I am just trying to fix and verify Tonokip_with_serial.zip. Later I can get back to generating a Teacup-ette.
Tonokip is rather simple compared to the other 3D printer software. It is worthwhile for me to fit it for the sake of the learning process, but I suspect anyone that is running 3D printing will want to have the stepper motor control include accelleration/deceleration and lookahead. Just adding Teacup's g-codes to Tonokip might actually print compiles from Slic3r, but the performance.
I am just running test by entering G-codes from a serial terminal and watching a bank of leds on the Propeller i/o.
In the revised configuration.h file, I uncommented the #define MOTHERBOARD == 0 and it seems to compile fine.
Hello all,
I made a bit of progress with Tonokip_with_serial.
It seems to compile now without any errors or warnings. I have created one warning to verify the i/o pins with the PropelllerASC. It is just a strong reminder.
But this is not to claim that it does everything it is supposed to do.
I am including a .zip of this latest compile as a better starting point for verification of actual use. My impression is that the code hangs after one round of g-code input and that something is wrong in the flow of the parser. This may be real or imagined.
And so, I am also now attempting to add debugging to see what is actually performing and where it seems to hang after the entry of just one line of g-code.
The parsing for g-code uses a typical CASE statement, with one test after another falling through to the end. But it seems to not have a DEFAULT that would issue a message of some sort to indicate that the filtered input was 'none of the above'. So that seems an obvious approach to verify the parsing.
And with the very important G-1 command, it seems that the routines for stepping X, Y, Z, and E motors could temporarily include a message output to indicate each call to step.
So I am going to try to add those two elements to trace that the code is driving the right results. Of course if these fail, I will have to run down what is what in further detail or think up something else.
At this point in time, my testing is rather simple... two alternatives..
A. Using the insertion of messages to confirm operation, such as...
Serial.println("Test A") ;
delay(500) ; // 500 ms delay
B. Using a bank of 8 LEDs that plugs into my Propeller Proto Board to verify that outputs are active as expected. I can shift around to any of the 4 banks of 8 to observe.
Since I do not have an active ADC chip, I can't verify the MCP3208 behavior. I need to buy this chip and will likely order a PropeleerASC board from Parallax at the same time... which included the Mcp3208 in an Arduino shield compatible set up.
+++++++++
I suppose there is a C alternative as well.
C. Read sections of code and mark off the ones that I am sure are correct... slowly eliminating what I do understand so that I can focus on what I do not.
+++++++++++
I have had to jump around in reading a lot.
Arduinio is a special modified sub-set of C++, not really C. So I have had to learn something about Arduino code and Arduino libraries in contrast to Propeller C and Propeller libraries.
I have also had to sort out what the Propelleruino provides and doesn't provide. But for Tonokip_with_serial it is suppose to be filling in all the gaps in the Arduino code. It provides a ms timer, which is enough for Tonokip, but Teacup code desires a microsecond timer as well.. which it doesn't yet provide.
+++++++++++++++++++++
In sum, it is all learning by comparisons and contrasts.
I do NOT have a physical 3D printer to test the code on and I doubt I ever will. But I am working towards controlling X, Y, and Z stepper motors.. maybe the E as well. I am more interested in CNC routers than in 3D printers for my personal use. It is difficult to justify a budget for building both.
C. Read sections of code and mark off the ones that I am sure are correct... slowly eliminating what I do understand so that I can focus on what I do not.
Thanks for the info. You are doing a great job so far. Also, you cannot go wrong learning the C language and how to interact with the C++ object extensions when you need to.
These two languages are probably the most universal among the entire list of programming languages. ( not advocating -- just saying ).
Build the router sturdy... When you want to print 3d, replace router with extruder and swap software.
Actually I was considering buying an XY stage with stepper motors attached and then adding a Z of simpler design. Since the Z axis has gravity pulling down, backlash is less of a problem.
You should be able to find plenty of info about using the ASSERT macro at the Microsoft Developer Network (http://msdn.microsoft.com).
Since the Z axis has gravity pulling down, backlash is less of a problem.
In my opinion, gravity has nothing to do with it, but I could be wrong. Backlash is more or less a drive issue instead of axis. Whether it be a CNC router or 3D printer, there will be numerous times when the Z axis must be raised or lowered, at which point backlash will come into play. Backlash occurs with direction changes.
In addition to information pertaining to ASSERT, the MSDN web site will have gobs of information pertaining to C and C++ in general, as well as answers to some very specific questions.
Backlash occurs in cases where there is no restraining force on the mechanism to maintain(or bias) the load(threads or teeth on a pulley) to one side. Mechanisms to solve backlash are usually referred to as anti-backlash. There are various ideas to deal with this. On a system with a Z axis, gravity is inherently a component involved in Z anti backlash when there is sufficient weight to overcome the friction, so that the weight will maintain a force on the threads of the nut to the threads on the threaded rod. On a 3d printer, there is not a lot of downward force required on the extruder as on a CNC, so assuming the weight of all components attached to the X axis can overcome the friction of the axis, the Z will generally have little backlash.
Yes you are correct, but it all depends on the circumstances of weight. After writing my reply, I thought about it a bit more, and I now suppose that gravity would play a major role on the Z axis.
Wouldn't backlash not be a problem with a 3D printer's Z axis because it only moves up during the print?
Okay, maybe I was completely wrong with my reply. However, I would assume that Z axis raises during X and Y travel when not printing. I would have to examine the g-code to provide an accurate answer.
Loopy, sorry about the reply, without knowing or considering the facts.
Gravity is a factor only when the weight is sufficient to overcome the friction, so that at all times, the load maintains a minimal amount of play. Typically a spring loaded nut is used to maintain maximum thread contact in both directions of travel, although with enough force and friction, the springs can be compressed. Ball screws are used in cases where a minimal backlash is required, since lubricated bearings will last a lot longer than a plastic(delrin) nut. But for a 3d printer, that is overkill. On a 3d machine, it is easy and cheap enough to add these dumpstercnc.com ABL nuts, or make your own.
Well, I didn't explain entirely what I was considering.
But with a CNC router, many tasks can be done with only one depth of cut.
So I was consdering starting out with no stepper motor on the Z axis... just a solenoild that would lift and release a spring loaded carriage. I already own an industrial router that is 115VAC and turns at 20,000 rpm.
If one does include a Z-axis stepper motor, there certainly are a lot of different mechanical considerations depending on what you attach. A router might be substantially heavier than a 3D printer head. It also will twist at start up due to significant torque.
But there are other alterantives. One can have a flexible cable drive to the cutting head tool holder and the motor not directly attached to the Z bridge.
Or one may just use the XY table to cut stencils with a knife. In that case, rotating the knife point to follow the direction of cut would use another stepper... but a small one.
+++++++++++++++++++
I keep restating that I am learning the 3D printer code because it is likely the most demanding. But I have no plans of building a 3D printer. If I do anyting in 3D, it would likely be a 3D mould maker. Parts coulld be casted in metal from a cut block of Plaster of Paris.
For replicatiion, casting is far more economical that 3D printing. Milling and turning are likely more precise. That seems to leave 3D printing to serve mainly as a rapid prototyping device. If one could remelt the prototypes into filiment, they might make a few bucks selling such a device to the rest of the users.
==================
Tonokip with Serial
I am making a lot of progress with repairing this for the Propeller. I get the impression that the actual code was never completed. I have nothing to show right now as it would take more to explain it than I care to try to do at this point.
But the bottom line is it seems feasible for me to finish fixing it soon, and to have learned quite a bit of what I need to get a Teacup-ette in the eventual future.
You should be able to find plenty of info about using the ASSERT macro at the Microsoft Developer Network (http://msdn.microsoft.com).
.
Sorry, but GCC is really deep into Unix and Linux origins... I am wary of anything that has Microsoft involved. MS has a way of trying to keep the enduser dependent on MS product and that usually means learning lesslearning only what works with MS products, and paying $$$.
I can't believe I've missed this thread until now. I'm amazed that the porting went so cleanly.
I've built 2 3D printers, my printers now have had tens of children and grandchildren. I'm currently working on building my pick and place machine.
I've not read the entire thread as I'm on my cellphone but I wanted to offer my assistance and congratulations.
I've always run marlin and sprinter on my printers and currently running tiny-g on my pick and place.
Print quality is strongly influenced by firmware. Some firmwares, marlin iirc looks at series of small moves and tries to determine if they're points on a curve. If they are, it substitutes those points for its own calculation.
I haven't followed this thread in detail. Did i understand right that the porting to a propeller-chip is done??!!!?
Does there exist a downloadadbe firmware that's as easy to use as a Arduino GRBL-firmware:
I mean download hexfile to arduino-clone connect wires and start your machine??
if not Is there some status-post or other website showing the actual status?
I haven't followed this thread in detail. Did i understand right that the porting to a propeller-chip is done??!!!?
Does there exist a downloadadbe firmware that's as easy to use as a Arduino GRBL-firmware:
I mean download hexfile to arduino-clone connect wires and start your machine??
if not Is there some status-post or other website showing the actual status?
best regards
Stefan
I don't believe it is done to that extent. It requires contributions of someone who is competent in C/C++, has time to help more, and has drive to finish.
Seeing __red__ contribute makes me believe that given his available time, this may be completed to his satisfaction.
I've done as much as I have time for, but will happily help if there is a SimpleIDE and/or PropellerGCC tools issue.
I'm not sure the concept of available time exists in my life anymore, sadly.
On Monday I quit my job of 10 years and the Hackerspace that I founded four years ago because combined they were preventing me from watching my beautiful 2 year old daughter grow. My lack of presence was very obviously having a negative influence on her development.
The only project I have retained is for this year's SkyDogCon conference badge. It will be propeller based again like last year except this time we won't go from request to full production in the impossible 6 week timeframe.
I really wish I had time to commit as this is a project close to my heart but I have to complete the commitments that I have made already.
I haven't followed this thread in detail. Did i understand right that the porting to a propeller-chip is done??!!!?
Does there exist a downloadadbe firmware that's as easy to use as a Arduino GRBL-firmware:
I mean download hexfile to arduino-clone connect wires and start your machine??
if not Is there some status-post or other website showing the actual status?
best regards
Stefan
Hi Stefan,
I would love for there to be a GRBL port to the Propeller, but we haven't gotten that far with this project. The only port that has been done is the Tonokip_with_serial and it seems not to work.
I have been using that to learn C on the Propeller and muddling along slowly with debugging it with the eventual goal of getting Teacup ported to the Propeller.
I have also looked at porting GRBL to the Propeller as a seperate project and have glanced at the code. In fact its code looks cleaner and easier to follow that the 3D printer code for Teacup. But I can only deal with one project at a time.
As best as I recall, you provided the Propeller OBEX with its one and only CNC object. Many thanks.
If any newcomers want to push ahead with a GRBL project, please feel free to do so. But I am concerned that in porting C to the Propeller, the 32K hubram might be too small. It may have to be replicated in PASM for an optimal fit on the Propeller.
Comments
Do we need to compile these libraries using Compiler Type C or C++ ?
Also, to get on right page -- Multiple Questions -- perhaps someone can help me set correct Project Options, Compiler Options, and Linker Options in SimpleIDE ?
Maybe someone could post the compiler line they are using -- from inside SimpleIDE -- I pointed to the correct library files but it seems to still use the ones under "My Documents"
propeller-elf-gcc.exe -v GCC 4.6.1 (propellergcc_v1_0_0_2162) -- NOT THIS LINE -- THE NEXT
propeller-elf-gcc.exe -I . -L . -L library/libArduino/cmm/ -I library/libArduino -L library/libfdserial/cmm/ -I library/libfdserial -L library/libsimpletext/cmm/ -I library/libsimpletext -I
Do the above settings and compiler switches seem normal -- are they the same as yours ?
Also,
I used whatever was set in SimpleIDE Project file -- but I may need to set each --- I used Compiler 32-bit Double and Linker Create Project Library
Do I need to select a certain Board Type in Project Options ? I want to follow for PropASC here -- I do not see PropASC in Board Type options
Do I need to have the board connected ? Can I use Prop BoE just as well ?
On to tonokip_with_serial.c
Now my typedef enum { false, true } bool; causes --> error: expected identifier before numeric constant -- this worked before and now does not
Next
When I compile tonokip_with_serial.c -- do I do so as C or C++ ? -- project file gives warning when C++ used --> cc1plus.exe: warning: command line option '-std=c99' is valid for C/ObjC but not for C++ [enabled by default]
So, I assume C for tonokip_with_serial.c ?
Boardtype GENERIC or ActivityBot is fine for now. The role of Board Types is mostly for clock settings and xmm features.
firmware.h:64:2: warning: #warning "PropellerASC not defined yet" [-Wcpp]
firmware.h:4:16: error: expected identifier before numeric constant
firmware.h:4:16: error: expected '}' before numeric constant
firmware.h:4:16: error: expected unqualified-id before numeric constant
firmware.h:4:28: error: expected declaration before '}' token
Then build stops
How did you solve 'bool' problem ? do you remember ? I see no posts about this -- I thought it _was_ working -- the 'bool' solution that is
I think tonokip_with_serial.c replaces firmware.c
bool is a type in C++ ... just remove that line no?
The Serial code builds (and works afaik) in the project I posted.
I can see that your compiler switches line is much shorter than mine.
Yours is below -- mine is posted earlier -- and -- it seems to have gotten longer once I made sure your SIDE --> Project, Compiler, Linker Pptions were the same -- seems some items duplicated
propeller-elf-c++ -I . -L . -I ./library/libArduino -I ./library/libfdserial -I ./library/libsimpletext -L ./library/libArduino/cmm/ -L ./library/libfdserial/cmm/ -L ./library/libsimpletext/cmm/ -o cmm/tonokip_with_serial.elf -Os -mcmm -Wall -m32bit-doubles -fno-exceptions -fno-rtti -DMOTHERBOARD=PropellerASC -fpermissive -ffunction-sections -fdata-sections -Wl,--gc-sections tonokip_with_serial.c -lfdserial -lsimpletext -lArduino -lfdserial -lsimpletext -lfdserial
It does not seem that easy in SimpleIDE to define new clean project and then add everything -- still looking in to this
Finally,
I wonder if I have the same Serial.cpp and Serial.H file as you -- I can see that they both have April 9, 2014 dates on Google code
https://code.google.com/p/lib-propelleruino/source/browse/#git%2FlibPropelleruino%3Fstate%3Dclosed
I may have to re-build libArduino with those changes -- I thought I encompassed them already -- still working
IMO, the entire 3D Printing DIY (or maker community) has evolved past the point of teaching anyone about the growth of the firmware -- I am not upset about this -- it just seems so. I believe that is more and more apparent as time goes by -- and -- the posts in this thread seem to support my beliefs about this. For example, just figuring out the workings of Teacup versus Tonokip.
One person -- for example -- has determined that one version of the firmware -- dont remember which -- has many files that simply support the many types of Arduino boards and/or shields. As everyone here knows, this is difficult to figure out when you are just trying to get the basics figured out --and --- then trying to implement just the basics
So, beyond helping on this, I think we should establish "milestones" as we go -- as Loopy, Jazzed, and Brian_B, etc. go -- so, we create a sort of tutorial about this -- where things get added in stages -- and each stage works -- just adds new functionality, perhaps -- or corrects code for efficiency. Maybe you guys disagree. Maybe you had the same idea. I just want to help and I believe that my C experience and the fact that I have some time for a month or so, will benefit some now.
For the record, I do not want any credit for this -- I do not want anyone who has started on this to think that I am trying to usurp their efforts -- I just want to help create a solution that other can understand
Welcome !!!
I am now reworking Tonokip_with_serial with all the i/o configurged for the PropellerASC. I am happy to see you are interested in the code.
The i/o pins were a bit sloppy for testing and verification as they were using an Arduinio configuration. I have also pulled out all the Arduino hardware references and included a heading that states that the files are adapted for the Propeller.
The ThermistorTable.h doesn't need any revision for now, but other firmwares list quite a few alterantive tables. Tonokip only provides one list of 20 items.
I am attaching the revisions for you reference. This is a bit piecemeal as I am not provided a full zip. It is up to you if you want to swap them out or use what you have. There is only one motherboard and it is now the PropellerASC+ designated as 0
This housekeeping should have been done some time ago, but better late than never.
I am also the originator of Tonokip_with_serial_without_kill as the Kill( ) seemed unfinished as was generating error reports in the compile. But, I am once again trying to just make the Tonokip_with_serial work completely as it is supposed.
I am not at all knowledgible in C and worse with C++, so you may very well discover somethings I have overlooked. I have been jumping around quite a bit to gain background knowledge by reading the Teacup.zip, and other GITHUB zips for 3D printing. Also I have found GRBL to be very well explained, so I have been reading that to get a better idea of what the more advanced CNC and 3D stepper control from g-codes should do.
Of course all that can be distracting, SO for NOW... I am just trying to fix and verify Tonokip_with_serial.zip. Later I can get back to generating a Teacup-ette.
Tonokip is rather simple compared to the other 3D printer software. It is worthwhile for me to fit it for the sake of the learning process, but I suspect anyone that is running 3D printing will want to have the stepper motor control include accelleration/deceleration and lookahead. Just adding Teacup's g-codes to Tonokip might actually print compiles from Slic3r, but the performance.
I am just running test by entering G-codes from a serial terminal and watching a bank of leds on the Propeller i/o.
In the revised configuration.h file, I uncommented the #define MOTHERBOARD == 0 and it seems to compile fine.
I made a bit of progress with Tonokip_with_serial.
It seems to compile now without any errors or warnings. I have created one warning to verify the i/o pins with the PropelllerASC. It is just a strong reminder.
But this is not to claim that it does everything it is supposed to do.
I am including a .zip of this latest compile as a better starting point for verification of actual use. My impression is that the code hangs after one round of g-code input and that something is wrong in the flow of the parser. This may be real or imagined.
And so, I am also now attempting to add debugging to see what is actually performing and where it seems to hang after the entry of just one line of g-code.
The parsing for g-code uses a typical CASE statement, with one test after another falling through to the end. But it seems to not have a DEFAULT that would issue a message of some sort to indicate that the filtered input was 'none of the above'. So that seems an obvious approach to verify the parsing.
And with the very important G-1 command, it seems that the routines for stepping X, Y, Z, and E motors could temporarily include a message output to indicate each call to step.
So I am going to try to add those two elements to trace that the code is driving the right results. Of course if these fail, I will have to run down what is what in further detail or think up something else.
I would like to mimic your setup especially if it is a Linux hosted env but Windows would be fine too...I cant believe that I just said that, huh?
A. Using the insertion of messages to confirm operation, such as...
Serial.println("Test A") ;
delay(500) ; // 500 ms delay
B. Using a bank of 8 LEDs that plugs into my Propeller Proto Board to verify that outputs are active as expected. I can shift around to any of the 4 banks of 8 to observe.
Since I do not have an active ADC chip, I can't verify the MCP3208 behavior. I need to buy this chip and will likely order a PropeleerASC board from Parallax at the same time... which included the Mcp3208 in an Arduino shield compatible set up.
+++++++++
I suppose there is a C alternative as well.
C. Read sections of code and mark off the ones that I am sure are correct... slowly eliminating what I do understand so that I can focus on what I do not.
+++++++++++
I have had to jump around in reading a lot.
Arduinio is a special modified sub-set of C++, not really C. So I have had to learn something about Arduino code and Arduino libraries in contrast to Propeller C and Propeller libraries.
I have also had to sort out what the Propelleruino provides and doesn't provide. But for Tonokip_with_serial it is suppose to be filling in all the gaps in the Arduino code. It provides a ms timer, which is enough for Tonokip, but Teacup code desires a microsecond timer as well.. which it doesn't yet provide.
+++++++++++++++++++++
In sum, it is all learning by comparisons and contrasts.
I do NOT have a physical 3D printer to test the code on and I doubt I ever will. But I am working towards controlling X, Y, and Z stepper motors.. maybe the E as well. I am more interested in CNC routers than in 3D printers for my personal use. It is difficult to justify a budget for building both.
Build the router sturdy... When you want to print 3d, replace router with extruder and swap software.
Thanks for the info. You are doing a great job so far. Also, you cannot go wrong learning the C language and how to interact with the C++ object extensions when you need to.
These two languages are probably the most universal among the entire list of programming languages. ( not advocating -- just saying ).
I revised the pins.h file, but I see that actual code doesn't actually initialize and call of of the i/o. This obviously needs some clean up.
Also I am reading about debugging in C. There is an assert.h, but most of what I have read seems to not say much about how to use this.
Actually I was considering buying an XY stage with stepper motors attached and then adding a Z of simpler design. Since the Z axis has gravity pulling down, backlash is less of a problem.
You should be able to find plenty of info about using the ASSERT macro at the Microsoft Developer Network (http://msdn.microsoft.com).
In my opinion, gravity has nothing to do with it, but I could be wrong. Backlash is more or less a drive issue instead of axis. Whether it be a CNC router or 3D printer, there will be numerous times when the Z axis must be raised or lowered, at which point backlash will come into play. Backlash occurs with direction changes.
In addition to information pertaining to ASSERT, the MSDN web site will have gobs of information pertaining to C and C++ in general, as well as answers to some very specific questions.
Yes you are correct, but it all depends on the circumstances of weight. After writing my reply, I thought about it a bit more, and I now suppose that gravity would play a major role on the Z axis.
Okay, maybe I was completely wrong with my reply. However, I would assume that Z axis raises during X and Y travel when not printing. I would have to examine the g-code to provide an accurate answer.
Loopy, sorry about the reply, without knowing or considering the facts.
But with a CNC router, many tasks can be done with only one depth of cut.
So I was consdering starting out with no stepper motor on the Z axis... just a solenoild that would lift and release a spring loaded carriage. I already own an industrial router that is 115VAC and turns at 20,000 rpm.
If one does include a Z-axis stepper motor, there certainly are a lot of different mechanical considerations depending on what you attach. A router might be substantially heavier than a 3D printer head. It also will twist at start up due to significant torque.
But there are other alterantives. One can have a flexible cable drive to the cutting head tool holder and the motor not directly attached to the Z bridge.
Or one may just use the XY table to cut stencils with a knife. In that case, rotating the knife point to follow the direction of cut would use another stepper... but a small one.
+++++++++++++++++++
I keep restating that I am learning the 3D printer code because it is likely the most demanding. But I have no plans of building a 3D printer. If I do anyting in 3D, it would likely be a 3D mould maker. Parts coulld be casted in metal from a cut block of Plaster of Paris.
For replicatiion, casting is far more economical that 3D printing. Milling and turning are likely more precise. That seems to leave 3D printing to serve mainly as a rapid prototyping device. If one could remelt the prototypes into filiment, they might make a few bucks selling such a device to the rest of the users.
==================
Tonokip with Serial
I am making a lot of progress with repairing this for the Propeller. I get the impression that the actual code was never completed. I have nothing to show right now as it would take more to explain it than I care to try to do at this point.
But the bottom line is it seems feasible for me to finish fixing it soon, and to have learned quite a bit of what I need to get a Teacup-ette in the eventual future.
Sorry, but GCC is really deep into Unix and Linux origins... I am wary of anything that has Microsoft involved. MS has a way of trying to keep the enduser dependent on MS product and that usually means learning lesslearning only what works with MS products, and paying $$$.
I am no longer a Windows user.
I've built 2 3D printers, my printers now have had tens of children and grandchildren. I'm currently working on building my pick and place machine.
I've not read the entire thread as I'm on my cellphone but I wanted to offer my assistance and congratulations.
I've always run marlin and sprinter on my printers and currently running tiny-g on my pick and place.
Print quality is strongly influenced by firmware. Some firmwares, marlin iirc looks at series of small moves and tries to determine if they're points on a curve. If they are, it substitutes those points for its own calculation.
Does there exist a downloadadbe firmware that's as easy to use as a Arduino GRBL-firmware:
I mean download hexfile to arduino-clone connect wires and start your machine??
if not Is there some status-post or other website showing the actual status?
best regards
Stefan
I don't believe it is done to that extent. It requires contributions of someone who is competent in C/C++, has time to help more, and has drive to finish.
Seeing __red__ contribute makes me believe that given his available time, this may be completed to his satisfaction.
I've done as much as I have time for, but will happily help if there is a SimpleIDE and/or PropellerGCC tools issue.
On Monday I quit my job of 10 years and the Hackerspace that I founded four years ago because combined they were preventing me from watching my beautiful 2 year old daughter grow. My lack of presence was very obviously having a negative influence on her development.
The only project I have retained is for this year's SkyDogCon conference badge. It will be propeller based again like last year except this time we won't go from request to full production in the impossible 6 week timeframe.
I really wish I had time to commit as this is a project close to my heart but I have to complete the commitments that I have made already.
Red
Hi Stefan,
I would love for there to be a GRBL port to the Propeller, but we haven't gotten that far with this project. The only port that has been done is the Tonokip_with_serial and it seems not to work.
I have been using that to learn C on the Propeller and muddling along slowly with debugging it with the eventual goal of getting Teacup ported to the Propeller.
I have also looked at porting GRBL to the Propeller as a seperate project and have glanced at the code. In fact its code looks cleaner and easier to follow that the 3D printer code for Teacup. But I can only deal with one project at a time.
As best as I recall, you provided the Propeller OBEX with its one and only CNC object. Many thanks.
If any newcomers want to push ahead with a GRBL project, please feel free to do so. But I am concerned that in porting C to the Propeller, the 32K hubram might be too small. It may have to be replicated in PASM for an optimal fit on the Propeller.
Can you summarize what the problem is?