I have changed my mind pertaining to a previous post.
The way I see it, the easiest way to introduce the G-Code to the Propeller is through file access to the microSD card of the Propeller Memory Card. So this is where it all begins, a G-Code file on the SD card.
Okay, now that we have established that point, the question then becomes, should I provide multiple file support, and if so, should I also provide folder support? Considering that most SD cards are of a substantial size, I suppose the obvious answer would be yes, that way numerous G-Code files can be stored to the SD card and they can further be divided by subject.
Now considering the fact that I have never done this before, I imagine the learning curve will be pretty steep to set up the file and folder system , and learning how to efficiently access it.
Once again, I am just shooting from the hip, so I intend to use the FAT16/32 Full File System Driver, available from the OBEX at this location: http://obex.parallax.com/object/16
Additionally, considering the complexity of a file/folder system, as compared to a single file, I must also establish a method of navigating the file system through the user interface of the proposed Propeller 3D printer controller. Basically I see this as somewhat of a nightmare that I am not looking forward to.
Please be patient until the smoke clears
Instead of having this issue bog down my creative process, I have decided to make this the very last issue of my programming endeavors concerning this parser. So for now, I will only be using one file on the SD card, and instead of searching the SD for the file, I will provide a local path.
While I still think you are focussing on the wrong part (application software vs mechanics) of your project, I would like to suggest the following, in case you had not considered it:
For generic CNC applications you will surely need to interrupt the processing of a file due to some unpredictable mechanical issue. And for 3D printing I believe the same will be true. So to "continue" processing a partly completed object, you will then need a method of traversing the G code file on the SD card to the spot where you want to re-start the machine. This might be quite complicated or at least inconvenient on a minimal HMI. You might want to reconsider using a PC as your G code source.
I would be focusing on the mechanics aspect of my project, but I am still currently facing strained back muscle issues. When I start to heal, then I go back to work and strain them again, so I have decided to take it easy for a while and work on issues that are not so physically demanding.
Since achieving a single Propeller design for a controller, my goal has since shifted to being PC independent, as you have noticed. Although not represented in the G-Code compiled by the KISSlicer, there are slicers that will proceed every line of G-Code, with a line number. I would imagine this line number is utilized for for determining a location in case of unforeseen circumstances, and perhaps performing a recovery as you mention. And perhaps there is a setting within KISSlicer where line numbers can be utilized. If line numbers cannot be utlized, it should be easy enough to insert them or track the current line.
To be perfectly honest, I have not put too much thought into, but I have thought about it. However since you brought it up, I may as well put a little more thought into it.
As far as I could tell from the Teacup firmware, the software always kept track of the machine's current position (supposedly ). And I suppose, after reading your post, it would be wise for me to do the same. By knowing the current position of the machine and the current line of G-Code being acted upon, perhaps a recovery can be made. In case of an orderly shutdown, such as E-Stop, the file name, the last known coordinates of the machine, and the current line of G-Code, could be saved to "recovery.txt" on the SD or some other suitable location, however in case of a catastrophical shutdown, such as a power outage, I think all is lost, unless of course you monitor power and have battery backup for the Propeller.
I am not really sure what is possible at this point, pertaining to the user interface, but I foresee a menu that can be traversed by buttons and displayed by LCD, and being likewise for the future directories of the SD. Perhaps on startup, the machine should always search the SD card for "recovery.txt". If found, then the machine should go into recovery mode and immediately display the recovery menu, whatever that might entail.
In case of recovery, I don't think the hard part will be seeking the last known position of the machine on the SD card. I think the hard part will be recomputing machine operation from the last known position of the machine.
Most likely the CNC/3D print errors will occur well before you notice them, and the dozens or even hundreds or thousands of G codes processed since the error will need to be examined for validity. Not very easy to do with line numbers on a small display. A big screen is much easier. Also, I would not rely on a recovery file generated by the system. The machine will not know when the error occurred. So searching for such a file is pointless. And if there had been a motor stall or mechanical crash ( guaranteed to happen, almost regardless of safety switches) the machine will have lost its coordinates.
It is "discovering" these kinds of things that cause me to urge you to build the moving mechanics before implementing controller board or application software designs. Regardless of your full understanding of the system needs, you will not get it right, and have to redo a bunch of stuff..... including the mechanics.
Get a simple propeller board, write some PASM motor motion code (SPIN will not be adequate except for the slowest and most basic applications), write some SPIN application code to interface to the PASM motion control code, and start experimenting with "feeds and speeds" to find out what your mechanics and motors really need. Mess with the linear and circular Bresenham algorithms until you understand them.
Only after you have accomplished a full understanding of these basics, talk about G code files on SD cards is futile. The devil is in the details, and they surely will trip you up.
Most likely the CNC/3D print errors will occur well before you notice them, and the dozens or even hundreds or thousands of G codes processed since the error will need to be examined for validity. Not very easy to do with line numbers on a small display. A big screen is much easier. Also, I would not rely on a recovery file generated by the system. The machine will not know when the error occurred. So searching for such a file is pointless. And if there had been a motor stall or mechanical crash ( guaranteed to happen, almost regardless of safety switches) the machine will have lost its coordinates.
Good point.
It is "discovering" these kinds of things that cause me to urge you to build the moving mechanics before implementing controller board or application software designs. Regardless of your full understanding of the system needs, you will not get it right, and have to redo a bunch of stuff..... including the mechanics.
As mentioned, I am having back issues and I am not going to remain stagnant in the meantime.
Besides, if that was truly the case, then controllers and software would all have to be created on a machine by machine basis. FiveD, Teacup, Sprinter, Marlin, and Repetier firmware would all be useless, as well as Mach3, and the various numerous controllers from a wide variety of manufacturers would also be useless. The controllers and software should be machine independent. Feeds and speeds should be settings controlled by the controller and software, to match the machines capabilities.
.........Feeds and speeds should be settings controlled by the controller and software, to match the machines capabilities.
Precisely my point.
To me it seems you are building a controller with little knowledge of what is required by the machine. You flip-flop ideas and land on "perfect" or "ideal" solutions so often it is hard to keep up.
Driving some motors with low level PASM software and dissecting Bressenham's algorithms is hardly backbreaking work, and such will at least get partway to the answers you will need to discover...... SD card formats and files come much later.
Not if you don't delve into PASM, and not well if you don't embrace Bressenham or like algorithms. That is unless you will accept rather lackluster performance, and I think that's not your goal.
I believe your aim is perfection, or at least very close to it. And I also believe you are going at it backwards, with a lot of rework in your approach.
Not if you don't delve into PASM, and not well if you don't embrace Bressenham or like algorithms. That is unless you will accept rather lackluster performance, and I think that's not your goal.
I believe your aim is perfection, or at least very close to it. And I also believe you are going at it backwards, with a lot of rework in your approach.
That has nothing to do with your statement and my question.
Providing there is ample space and providing adequate software is installed on that controller and providing there is no minor error in my components, that contoller should run a CNC or 3D printer, regardless of whether I write the software or not. So my knowledge of PASM or algorithms has nothing to do with the controller. It is an entity all by itself. Anyone can write software for that design. It is all there.
Seems to me, a "controller" is something active, composed of both a circuit and logic where logic can be hardware or software itself. A circuit, sans software, is just a circuit.
The help offered here Bruce isn't intended to make you look bad somehow, or wrong. It's just help!
In reality, the controller needs software to make it work, but that does not mean that I have to write the software or even understand the software. The important thing is that all the critical components are there and someone can write software for it, to enable it to function and control a CNC or 3D printer.
The controller has nothing to do with the mechanics of my machine or my knowledge of algorithms. Furthermore, that controller will not control any machine, unless software is written for the controller. So without the controller or the software, the mechanics of the machine are basically pointless.
Nothing quite the same as trying to push several wheelbarrows full of concrete and having some yahoo just standing and flapping his yap on or near the pathway.
I had a minor setback... I do not have a microSD card reader for my PC or laptop.
Instead of purchasing an SD card reader, I am going to attempt to feed the G-Code file information serially from the PC to the Propeller Board of Education and write it to the SD card. To do this, I am going to tinker with one of my unfinished projects, which might turn out to be useful for this project one way or another. The project I am referring to is a serial terminal intended for the Propeller. For the lastest design files pertaining to this project, which are VS C++ 6.0, please visit this post: http://forums.parallax.com/showthread.php/133979-Project-In-Progress-New-Serial-Terminal-Taking-Suggestions?p=1047778&viewfull=1#post1047778
I had a minor setback... I do not have a microSD card reader for my PC or laptop.
Instead of purchasing an SD card reader, I am going to attempt to feed the G-Code file information serially from the PC to the Propeller Board of Education and write it to the SD card.
SimpleIDE can do this. Use the ActivityBoard pins and board type.
I never noticed that before. So are you are talking about simply clicking the sub-menu item "File to SD Card" in the "Program" menu? If so, that is sweet.
Nice project and in fact something I am going to work on as well. Since January I own a small CNC system which is capable of milling, cutting and 3D printing, but I don't like the software which came with it (limited starter version anyway). So, to have the full g-code capability I'd like to build my own controller. Before my CNC system arrived I already spend some time for coding. What I currently have is covering 3 different aspects of such a controller.
1. I have a Quickstart board running a program to display the machine coordinates. It also has a menu system.
There is a COG which really counts the step-signals in the background. This allows me to attach the system to any CNC controller and use the propeller as display-only. There is also the idea of counting the runtime of the machine to remember the user to maintain the machine (degrease/grease and oil).
I use a TFT display with PAL in.
There is a screen-capture in this thread post #11 http://forums.parallax.com/showthread.php/152710-TV-TFT-display-problems
Here is an image:
2. In an other coding session I started with a proof of concept for the motion-system.
The concept behind this is, having code that implements the bresnham, currently it's running in a COG per axis. (This is mainly because the proof of concept is simply written in SPIN. Of course in PASM all 3 axes can be driven by one COG.)
Another COG cares for the timing.
The plans are to have a queue for coordinates and another queue for the timing. The axes COGs are fed by the coordinate queue whereas the timing COG is fed by the timing queue, which contains a strategy for ramp-up/down.
One nice effect is, that the timing COG could for example read an input for emergeny stops or pausing and do a quick ramp-down. After fixing the problem the g-code program can be resumed by ramping up again.
3. In another coding session I started parsing g-code.
First I simply started by reading the g-code-line input from keyboard.
From my point of view it would be desirable to have a standalone system which can be used to do usefull things without attaching a PC. So, I also thought about adding an SD-card for storing all the g-code-files. But the file-exchange should be easy which means that a full FAT driver like Kyes SD driver would be a must have. This on the other hand means that a lot of HUB-RAM is already occupied by this driver. That's where I thought it would be a good idea to add a second propeller - one for driving the machine, one for the user interface and file handling.
But then it came into my mind that sharing the files via network would be much better.
So, the current status is, that I want to use a raspberry pi hosting the files and the propeller concentrating on the motor control. The connection would be master-master style. Which means that a milling/printing/cutting job can be started by the raspberry (maybe triggered via network) or it can be triggered by the propellers menu (the propeller would then for example request a g-code-file from the pi)
Sorry ... this chaotic post ... for the moment my goal only was to share my thoughts - maybe later in this thread I'll manage to sort them out ;o)
That is great news.... I wish more people were taking the initiative to attempt Propeller CNC. However since everyone keeps bringing up the issue of memory, I am seriously beginning to wonder whether I am wasting my time. Hopefully the limited amount of G-Codes will save me some grief. Oh well, the money is invested now, so I shall go forward. Worst case scenario, I will lose a Proto Board and a lot of time.
I am not exactly sure what I am doing for software just yet, but I do have a small glimpse of a plan.
Unless I run out of cogs, I want each axis to run in it's own cog, with each axis receiving it's movement profile from a queue.
I want to parse the G-Code using arrays.
I am hoping to achieve a fairly complex menu system with LCD and buttons to display user options and a file system.
I think the Propeller 2 will provide many more opportunites for a better controller, but for now, with the Propeller 1, I am trying to keep everything to the bare minimum, with the exception of the menu system. So the first edition surely won't be anything fancy.
My first plan of attack is to seperate G-Code lines by element and saving them as a data type required for further process, eg... G1 - String, X, Y, Z, and E as either floating point or integer, etc...
At this point I have not done anything except talk, but that will change soon.
Upto this point, I have been becoming more familiar with the Propeller Memory Card, but so far I have only toyed with the flash memory and SRAM. At first glance, it appears that the SRAM will be much more useful than the flash memory. In fact, I don't believe the flash memory will be of much use to this project at all, but I could be wrong. The problem that I have with it, is that it is nonvolatile, and it must be erased unless you have some actual data that you want to store. Perhaps I could use it for error records or build records. As for the SRAM, I wish I had a lot more of it, and I can readily see that I will need to clearly define my queue strategy to make the most of this resource.
I probably won't get back to this project until tomorrow evening, at which point, I will start tinkering with the SD card, retrieving G-Code file lines, and displaying them on a serial terminal. Or perhaps instead of lines, one character at a time.
I'd use the flash memory for all the menus and string messages you want to output on the lcd. This is what I usually store in a swap-file on the SD card. It is pretty easy to achieve: Simply write an extra program which stores all the strings on the flash. If some string needs to be changed you'd simply change it in this program and run it once by uploading it into RAM.
The main program only contains a small routine to fetch messages from there and write it to the LCD.
Of course you can also store the machine parameters (size of the print-area, resolution, ramp-up/down profiles .... ) in flash.
I would at least think of running 2 or 3 different propeller 32kB code-images, one for UI and file-handling (as the full FAT driver is really fat ;o), maybe another one for parsing a g-code file into the processing queue format (depends on how much room is left by menu system and file-handling) and an image for running the g-code.
For g-code parsing I started to go in direction of integers. All the machine can do is integer (a step is per definition integer), so there is no point in working with float - well at least if you don't plan CAM functions in your controller.
If you are interested I can upload the proof of concept code for motion control. Currently it only outputs the coordinates to a serial interface, so it should run with little changes on any hardware. (Don't have it with me, so this evening I can upload it).
Let me know if you need other code or maybe code snippets as well, even if it's just to learn how I do things. It's hard to share my code because I have a whole ecosystem of functionalities I use in most of my propeller code, which needs some installation work. But on the other hand this gives me a whole lot of extra memory. For example COG drivers placed in upper EEPROM not wasting RAM after being started or SD card swap file(s) for string messages, menus and other data ...
By the way ... I posted a ConfigReader in obex, which already handles reading a file line by line, parsing the content into an array. It currently can only parse integers in different formats, but it should be easy to enhance it. Maybe you want to have a look.
I'd use the flash memory for all the menus and string messages you want to output on the lcd.
I thought about that, but I figured it would be pretty slow from the read to the output on the display, but I was only guessing and perhaps I should at least try it. I don't know how they do it now, but Visual Studios C++ once held all user created "resource" defines in a file called "resource.h" and the strings and layout and such, were stored in an ".rc" file. Perhaps if I could do something like that, it might work well.
Of course you can also store the machine parameters (size of the print-area, resolution, ramp-up/down profiles .... ) in flash.
Once again, I thought about that to, but once again, I figured it would be pretty slow. However, perhaps I am underestimating the speed of these reads.
I would at least think of running 2 or 3 different propeller 32kB code-images
Please elaborate, because I do not know what you mean by 32kB code-images.
For g-code parsing I started to go in direction of integers. All the machine can do is integer (a step is per definition integer), so there is no point in working with float
Yea, this is a tuff subject. Basically, I will be trying to hunt down the best algorithms that I can find for movement and ramping, and port them. If they require floating support, then I will support it, if not, then I won't.
If you are interested I can upload the proof of concept code for motion control.
All code, snippets,, and ideas, are generally welcome. This thread was created to share ideas and concepts, and the more the merrier, as far as I am concerned. I am sure my solution will be far from the ideal solution, so any positive input is always welcome. And it always nice to see things from another's point of view or a different perspective. For instance, you already see possibilities with the flash memory, when I was simply going to abandoned it.
For example COG drivers placed in upper EEPROM not wasting RAM after being started
If you have the time, please elaborate.
SD card swap file(s) for string messages, menus and other data
Hmmmmm....
By the way ... I posted a ConfigReader in obex, which already handles reading a file line by line, parsing the content into an array. It currently can only parse integers in different formats, but it should be easy to enhance it. Maybe you want to have a look.
LOL.... Maybe? Definitely!
You certainly gave me a variety of things to think about. Thanks for your input.
I notice you rarely sign your name, would you prefer I refer to you as MagIO2
As soon as I finished my last post, this idea popped into my head, and I am going to stick with this one, because my previous line of thinking, was way off base.
I was initially thinking that machine parameters could be set as constants, as in the Teacup firmware, but that would require the abiltity to edit and rebuild the software. Then MagIO2, mentioned his ConfigReader, and the thought of a configuration file popped into my head. I am a firm believer that configuration settings should not require a rebuild of the main software and that settings can be changed by altering a simple file in any text editor.
From this day forward, at least for my plan, all machine parameters or configuration settings will be stored in a file named CONFIG.CFG. This file will always be stored in the Top Level directory of the SD card. The settings that will be contained in this file have yet to be determined.
Comments
Very good points. I will have to remember your post and advice.
Instead of having this issue bog down my creative process, I have decided to make this the very last issue of my programming endeavors concerning this parser. So for now, I will only be using one file on the SD card, and instead of searching the SD for the file, I will provide a local path.
While I still think you are focussing on the wrong part (application software vs mechanics) of your project, I would like to suggest the following, in case you had not considered it:
For generic CNC applications you will surely need to interrupt the processing of a file due to some unpredictable mechanical issue. And for 3D printing I believe the same will be true. So to "continue" processing a partly completed object, you will then need a method of traversing the G code file on the SD card to the spot where you want to re-start the machine. This might be quite complicated or at least inconvenient on a minimal HMI. You might want to reconsider using a PC as your G code source.
Just trying to help.....
Cheers,
Peter (pjv)
Point taken.
I would be focusing on the mechanics aspect of my project, but I am still currently facing strained back muscle issues. When I start to heal, then I go back to work and strain them again, so I have decided to take it easy for a while and work on issues that are not so physically demanding.
Since achieving a single Propeller design for a controller, my goal has since shifted to being PC independent, as you have noticed. Although not represented in the G-Code compiled by the KISSlicer, there are slicers that will proceed every line of G-Code, with a line number. I would imagine this line number is utilized for for determining a location in case of unforeseen circumstances, and perhaps performing a recovery as you mention. And perhaps there is a setting within KISSlicer where line numbers can be utilized. If line numbers cannot be utlized, it should be easy enough to insert them or track the current line.
To be perfectly honest, I have not put too much thought into, but I have thought about it. However since you brought it up, I may as well put a little more thought into it.
As far as I could tell from the Teacup firmware, the software always kept track of the machine's current position (supposedly
I am not really sure what is possible at this point, pertaining to the user interface, but I foresee a menu that can be traversed by buttons and displayed by LCD, and being likewise for the future directories of the SD. Perhaps on startup, the machine should always search the SD card for "recovery.txt". If found, then the machine should go into recovery mode and immediately display the recovery menu, whatever that might entail.
In case of recovery, I don't think the hard part will be seeking the last known position of the machine on the SD card. I think the hard part will be recomputing machine operation from the last known position of the machine.
Bruce
And on second thought, perhaps I should also provide the alternative of a serial interface for the G-Code.
Most likely the CNC/3D print errors will occur well before you notice them, and the dozens or even hundreds or thousands of G codes processed since the error will need to be examined for validity. Not very easy to do with line numbers on a small display. A big screen is much easier. Also, I would not rely on a recovery file generated by the system. The machine will not know when the error occurred. So searching for such a file is pointless. And if there had been a motor stall or mechanical crash ( guaranteed to happen, almost regardless of safety switches) the machine will have lost its coordinates.
It is "discovering" these kinds of things that cause me to urge you to build the moving mechanics before implementing controller board or application software designs. Regardless of your full understanding of the system needs, you will not get it right, and have to redo a bunch of stuff..... including the mechanics.
Get a simple propeller board, write some PASM motor motion code (SPIN will not be adequate except for the slowest and most basic applications), write some SPIN application code to interface to the PASM motion control code, and start experimenting with "feeds and speeds" to find out what your mechanics and motors really need. Mess with the linear and circular Bresenham algorithms until you understand them.
Only after you have accomplished a full understanding of these basics, talk about G code files on SD cards is futile. The devil is in the details, and they surely will trip you up.
Cheers,
Peter (pjv)
Good point.
As mentioned, I am having back issues and I am not going to remain stagnant in the meantime.
Besides, if that was truly the case, then controllers and software would all have to be created on a machine by machine basis. FiveD, Teacup, Sprinter, Marlin, and Repetier firmware would all be useless, as well as Mach3, and the various numerous controllers from a wide variety of manufacturers would also be useless. The controllers and software should be machine independent. Feeds and speeds should be settings controlled by the controller and software, to match the machines capabilities.
Precisely my point.
To me it seems you are building a controller with little knowledge of what is required by the machine. You flip-flop ideas and land on "perfect" or "ideal" solutions so often it is hard to keep up.
Driving some motors with low level PASM software and dissecting Bressenham's algorithms is hardly backbreaking work, and such will at least get partway to the answers you will need to discover...... SD card formats and files come much later.
Cheers,
Peter(pjv)
I don't see how you figure that statement.
Are you trying to say that my controller will not run a CNC machine or a 3D Printer with basic requirements?
I believe your aim is perfection, or at least very close to it. And I also believe you are going at it backwards, with a lot of rework in your approach.
I do however wish you success in your persuit.
Cheers,
Peter (pjv)
That has nothing to do with your statement and my question.
Providing there is ample space and providing adequate software is installed on that controller and providing there is no minor error in my components, that contoller should run a CNC or 3D printer, regardless of whether I write the software or not. So my knowledge of PASM or algorithms has nothing to do with the controller. It is an entity all by itself. Anyone can write software for that design. It is all there.
Seems to me, a "controller" is something active, composed of both a circuit and logic where logic can be hardware or software itself. A circuit, sans software, is just a circuit.
The help offered here Bruce isn't intended to make you look bad somehow, or wrong. It's just help!
The controller has nothing to do with the mechanics of my machine or my knowledge of algorithms. Furthermore, that controller will not control any machine, unless software is written for the controller. So without the controller or the software, the mechanics of the machine are basically pointless.
I heard it as "Lead, follow, or get out of the way." ;-)
Nothing quite the same as trying to push several wheelbarrows full of concrete and having some yahoo just standing and flapping his yap on or near the pathway.
Instead of purchasing an SD card reader, I am going to attempt to feed the G-Code file information serially from the PC to the Propeller Board of Education and write it to the SD card. To do this, I am going to tinker with one of my unfinished projects, which might turn out to be useful for this project one way or another. The project I am referring to is a serial terminal intended for the Propeller. For the lastest design files pertaining to this project, which are VS C++ 6.0, please visit this post: http://forums.parallax.com/showthread.php/133979-Project-In-Progress-New-Serial-Terminal-Taking-Suggestions?p=1047778&viewfull=1#post1047778
SimpleIDE can do this. Use the ActivityBoard pins and board type.
I never noticed that before. So are you are talking about simply clicking the sub-menu item "File to SD Card" in the "Program" menu? If so, that is sweet.
Could be. LOL.
If you change the SD card pins, you'll need a different board.cfg file.
Nice project and in fact something I am going to work on as well. Since January I own a small CNC system which is capable of milling, cutting and 3D printing, but I don't like the software which came with it (limited starter version anyway). So, to have the full g-code capability I'd like to build my own controller. Before my CNC system arrived I already spend some time for coding. What I currently have is covering 3 different aspects of such a controller.
1. I have a Quickstart board running a program to display the machine coordinates. It also has a menu system.
There is a COG which really counts the step-signals in the background. This allows me to attach the system to any CNC controller and use the propeller as display-only. There is also the idea of counting the runtime of the machine to remember the user to maintain the machine (degrease/grease and oil).
I use a TFT display with PAL in.
There is a screen-capture in this thread post #11 http://forums.parallax.com/showthread.php/152710-TV-TFT-display-problems
Here is an image:
2. In an other coding session I started with a proof of concept for the motion-system.
The concept behind this is, having code that implements the bresnham, currently it's running in a COG per axis. (This is mainly because the proof of concept is simply written in SPIN. Of course in PASM all 3 axes can be driven by one COG.)
Another COG cares for the timing.
The plans are to have a queue for coordinates and another queue for the timing. The axes COGs are fed by the coordinate queue whereas the timing COG is fed by the timing queue, which contains a strategy for ramp-up/down.
One nice effect is, that the timing COG could for example read an input for emergeny stops or pausing and do a quick ramp-down. After fixing the problem the g-code program can be resumed by ramping up again.
3. In another coding session I started parsing g-code.
First I simply started by reading the g-code-line input from keyboard.
From my point of view it would be desirable to have a standalone system which can be used to do usefull things without attaching a PC. So, I also thought about adding an SD-card for storing all the g-code-files. But the file-exchange should be easy which means that a full FAT driver like Kyes SD driver would be a must have. This on the other hand means that a lot of HUB-RAM is already occupied by this driver. That's where I thought it would be a good idea to add a second propeller - one for driving the machine, one for the user interface and file handling.
But then it came into my mind that sharing the files via network would be much better.
So, the current status is, that I want to use a raspberry pi hosting the files and the propeller concentrating on the motor control. The connection would be master-master style. Which means that a milling/printing/cutting job can be started by the raspberry (maybe triggered via network) or it can be triggered by the propellers menu (the propeller would then for example request a g-code-file from the pi)
Sorry ... this chaotic post ... for the moment my goal only was to share my thoughts - maybe later in this thread I'll manage to sort them out ;o)
That is great news.... I wish more people were taking the initiative to attempt Propeller CNC. However since everyone keeps bringing up the issue of memory, I am seriously beginning to wonder whether I am wasting my time. Hopefully the limited amount of G-Codes will save me some grief. Oh well, the money is invested now, so I shall go forward. Worst case scenario, I will lose a Proto Board and a lot of time.
I am not exactly sure what I am doing for software just yet, but I do have a small glimpse of a plan.
- Unless I run out of cogs, I want each axis to run in it's own cog, with each axis receiving it's movement profile from a queue.
- I want to parse the G-Code using arrays.
- I am hoping to achieve a fairly complex menu system with LCD and buttons to display user options and a file system.
I think the Propeller 2 will provide many more opportunites for a better controller, but for now, with the Propeller 1, I am trying to keep everything to the bare minimum, with the exception of the menu system. So the first edition surely won't be anything fancy.My first plan of attack is to seperate G-Code lines by element and saving them as a data type required for further process, eg... G1 - String, X, Y, Z, and E as either floating point or integer, etc...
At this point I have not done anything except talk, but that will change soon.
- The SD card has been formatted to FAT32
- The G-Code file of Post #26 has been saved to the SD card with a 8.3 short file name
- The Propeller Memory Card has been installed on the Propeller Board Of Education
- The Propeller Board Of Education is now hooked up to the PC and hardware has been identified
- The SD card has been inserted into the Propeller Memory Card
- The switch has been turned on
- And I have started a SPIN file, declaring constants and objects
It all feels wierd, because it has been such a very long time since I have done any SPIN programming or any other programming for that matter.I probably won't get back to this project until tomorrow evening, at which point, I will start tinkering with the SD card, retrieving G-Code file lines, and displaying them on a serial terminal. Or perhaps instead of lines, one character at a time.
Baby steps
The main program only contains a small routine to fetch messages from there and write it to the LCD.
Of course you can also store the machine parameters (size of the print-area, resolution, ramp-up/down profiles .... ) in flash.
I would at least think of running 2 or 3 different propeller 32kB code-images, one for UI and file-handling (as the full FAT driver is really fat ;o), maybe another one for parsing a g-code file into the processing queue format (depends on how much room is left by menu system and file-handling) and an image for running the g-code.
For g-code parsing I started to go in direction of integers. All the machine can do is integer (a step is per definition integer), so there is no point in working with float - well at least if you don't plan CAM functions in your controller.
If you are interested I can upload the proof of concept code for motion control. Currently it only outputs the coordinates to a serial interface, so it should run with little changes on any hardware. (Don't have it with me, so this evening I can upload it).
Let me know if you need other code or maybe code snippets as well, even if it's just to learn how I do things. It's hard to share my code because I have a whole ecosystem of functionalities I use in most of my propeller code, which needs some installation work. But on the other hand this gives me a whole lot of extra memory. For example COG drivers placed in upper EEPROM not wasting RAM after being started or SD card swap file(s) for string messages, menus and other data ...
By the way ... I posted a ConfigReader in obex, which already handles reading a file line by line, parsing the content into an array. It currently can only parse integers in different formats, but it should be easy to enhance it. Maybe you want to have a look.
I thought about that, but I figured it would be pretty slow from the read to the output on the display, but I was only guessing and perhaps I should at least try it. I don't know how they do it now, but Visual Studios C++ once held all user created "resource" defines in a file called "resource.h" and the strings and layout and such, were stored in an ".rc" file. Perhaps if I could do something like that, it might work well.
Once again, I thought about that to, but once again, I figured it would be pretty slow. However, perhaps I am underestimating the speed of these reads.
Please elaborate, because I do not know what you mean by 32kB code-images.
Yea, this is a tuff subject. Basically, I will be trying to hunt down the best algorithms that I can find for movement and ramping, and port them. If they require floating support, then I will support it, if not, then I won't.
All code, snippets,, and ideas, are generally welcome. This thread was created to share ideas and concepts, and the more the merrier, as far as I am concerned. I am sure my solution will be far from the ideal solution, so any positive input is always welcome. And it always nice to see things from another's point of view or a different perspective. For instance, you already see possibilities with the flash memory, when I was simply going to abandoned it.
If you have the time, please elaborate.
Hmmmmm....
LOL.... Maybe? Definitely!
You certainly gave me a variety of things to think about. Thanks for your input.
I notice you rarely sign your name, would you prefer I refer to you as MagIO2
As soon as I finished my last post, this idea popped into my head, and I am going to stick with this one, because my previous line of thinking, was way off base.
I was initially thinking that machine parameters could be set as constants, as in the Teacup firmware, but that would require the abiltity to edit and rebuild the software. Then MagIO2, mentioned his ConfigReader, and the thought of a configuration file popped into my head. I am a firm believer that configuration settings should not require a rebuild of the main software and that settings can be changed by altering a simple file in any text editor.
From this day forward, at least for my plan, all machine parameters or configuration settings will be stored in a file named CONFIG.CFG. This file will always be stored in the Top Level directory of the SD card. The settings that will be contained in this file have yet to be determined.