You should be able to just PWM the laser driver, or even the laser itself, depending on how it's connected. Laser diodes will usually be connected to a constant-current power supply, and that should have an "enable" pin on it that you can control with the Prop. In fact, you likely already are, given what you're doing. PWM that nice and low, like 1/4096, and you should have no issues with the camera. I had a 6W laser that could be PWM'd down to the point where it was just barely perceptible to the eye.
I am assuming that you read what I intend to do, since you have a valid response.
Here is an issue with my proposed plan...
As you may have read, I am using the bearing ID of the PCB driller as a reference measurement of 0.127 inches. If I don't have some sort of semi-translucent backstop at the bottom of the bearing, and just shoot straight into the camera, then I lose my reference measurement.
I am now thinking that some sort of backstop SHOULD be there, in order to establish size.
Unless of course you have a solution to establish size
The bottom of the bearing is approximately 5/8" above the webcam lense.
Or, just use it to evaluate the surface the laser hits too. Position it off axis and set focus to the target area.
Here's the thing: Those diodes will vary some. Everything does. In the end, your machine will need to adjust focus through some range.
For a given diode and target material, a direct observation focus will get you close. Real precision will need to be dynamic to get the resolution you want.
I would be surprised at the focus staying constant across anything other than a really small PCB, when using a near focus lens.
Do you have a height gauge and dial indicator?
Clean and clamp a nice chunk to a surface plate, or the best you have got. Run the gauge over it and see the flatness variation. There is a hint at that range. Call it a minimum. If you can't determine that range, your ability to measure, with the gear you have, isn't sufficient to succeed.
I would check that right away.
600 dpi is a .001666 spot size. Your average human hair cross section is .004. Human repeatability on standard measuring tools, caliper, height gauge, etc... sans dial indicator is .002. With indicator, you can improve on that approximately 5 to 10x, which puts your ability to measure in the range needed. 0.0002 - 4
Think about the cone shaped beam with a near focus lens. The closer the focal point is, the less tolerance you have to maintain spot size, thus the higher the precision requirement. And the lower the tolerance for part variations is too.
Honestly, you might consider researching lenses. One that has a more distant focal point will also make a much sharper cone, which can very significantly relax your precision requirement.
In short, you can engineer some of your difficulty away.
This is all dependent upon whether I destroy my webcam or not, by shining a laser beam directly into it
Can you sacrifice a Webcam for this research ? - if the dot is small, & damage is real, you can always move around the damaged area, and still get a collection of data points... until the whole pixel area is toast..
As I see it, unless I reverse engineer one of the Blu-Ray sleds, with auto-focus or enable some auto focus system of my own, the machine I am building will never have near perfect resolution. I faced this fact, before I even started designing the machine, which is one of the reasons why I was thinking about overlap during the rasterization.
My goal is to know the dpi set by the pulleys and belts, and do my very best to match the laser to that dpi. Undoubtedly, there will be minor imperfections, due to board height variances, improper focus, etc..., simply because I do not have the time or money to put into these issues. However, I do want to be able to output the nicest board possible without the auto-focusing feature. I am not certain, but I believe that nice boards, although not perfect, can be made without auto-focus and though there may be slight variances in the thickness of material.
If a given track is supposed to be 10 mil wide throughout the whole trace, but there are areas along the trace where it jumps from 9 ~ 11 mil, I think I can live with that as long as it doesn't produce shorts or opens, and as long as the trace can carry the current that it needs for its intended purpose. In my eyes, this is meant to be a rough draft machine for prototyping circuitry, and any design flaws in the machine itself will most likely have to be taken into consideration, when designing a rough draft board.
Of course, I could be wrong about all of this, and all my time, effort, and money will have been wasted, but discovery is half the fun of doing what I do. Whatever I do, I either succeed or I fail
Indeed, 0.0016666666666666668" is a mighty fine dot, but the dot size I seek is much larger, which is 0.00167391304347826"
Actually, when I first started to develop my theory on this machine, I thought that a square aperture would be the best way to go. They can make some fairly small round and square holes these days. And that way, my focus would never need to be perfect, just close.
Considering that I know that my target array on the webcam is in between 2 * 2 and 3 * 3 pixels, I suppose I could attempt to make my own aperture with a very sharp needlepoint and tin foil. It is possible, but not likely to work.
It won't. Those turn into micro lenses. Cameras. Try this, pinch your fingers together to make a tiny hole. Now take your glasses off and look at some text through that hole. Literally, lens in a pinch!
I would find a lens with a long focal length. It will significantly improve dot size variations due to these variables.
Perhaps 598 dpi is overkill for making prototype boards. How about going for a pixel size closer to the minimum feature width on the pcb. That would make the mechanics simpler and decrease scanning time.
I would find a lens with a long focal length. It will significantly improve dot size variations due to these variables.
Undoubtedly you are correct, on several issues, but I am first going to build it with what I have on hand and what I have already ordered. In other words, before I go seeking a special lens, I am certainly going to try the one I already have, and before I buy a precision made bed plate, I am certainly going to attempt it with the most true sheet stock I have available.
I am sure there will have to be many kinds of adjustments, in addition to lens changes and bed straightness, that I will have to make before I can get a decent board. The spring bender CNC took a lot of trial and error on a lot of the various assemblies just to get it to work properly. Although this machine is much less complicated in design and various assemblies than the spring bender, I am sure this machine will provide similar aggravation, especially since it will require much higher precision.
Lens focus and bed straightness, are just two of the problems involved, now consider the clearances required for X and Y axis travel. I am almost 99.9% certain that there has to be scan line overlap to account for these discrepancies.
@kwinn
Perhaps 598 dpi is overkill for making prototype boards. How about going for a pixel size closer to the minimum feature width on the pcb. That would make the mechanics simpler and decrease scanning time.
After considering many different options, with various prerequisites in mind, and without switching to a gear driven system, 399 dpi (FULL Step)/598 dpi (HALF Step) was the best belt driven combination that I could come up with.
At this point, I am pretty much committed to 399 dpi (FULL Step)/598 dpi (HALF Step), because the belts and pulleys have been purchased and are on their way.
Believe me, it helps. Odds are that I will most likely and eventually need a lens with a long focal length and a precision bed, but for now, I am just going for what I have on a hand and what I ordered.
Until the rest of my parts arrive, here is my current challenge...
As mentioned, this machine is designed around the EAGLE maximum board size for their freeware, so of course, considering the size of the board, it is not going to be a big machine, in fact it will be quite small. With this in mind, I have made every attempt to keep the footprint as small as possible, with an 1/8" or 1/16" here and there, meanwhile keeping the stages as light as possible, so less torque would be needed. During my research, I discovered that the laser must be held firmly, to provide any kind of decent output. So instead of going with single row V-groove bearings for the laser carriage, I decided to go with double row radial ball bearings, because I certainly want as little slop as possible for this carriage. To make a long story short, there will be a total of eight bearings for the carriage, with each bearing having a 1/4" ID, a 5/8" OD, and a 0.196" width, and two bearing sets, along with a spacer for each set, will be pressed into (4) steel V-groove sleeves, which I am currently turning on a wood lathe. The OD of each sleeve will be 7/8", the width of each sleeve will be 0.4545", and each sleeve will have an 80 degree V-groove cut across the center.
In the image below, you will see a side view of my carriage assembly, with the V-groove sleeves being cross sectioned. The laser housing, the laser module clamp, and the carriage are already made, and all I need to finish the carriage is those v-groove sleeves. Making those steel v-groove sleeves on a wood lathe is a real treat. So much fun, I can hardly control my excitement
As mentioned, this machine is designed around the EAGLE maximum board size for their freeware, so of course, considering the size of the board, it is not going to be a big machine, in fact it will be quite small...
Keep in mind that KiCAD has no area limits, and Mentor's very new PADS Maker, has a simple 25 square inch area limit, which could mean 12.5" x 2", so focusing on one vendor's free solution is inflexible...
Keep in mind that KiCAD has no area limits, and Mentor's very new PADS Maker, has a simple 25 square inch area limit, which could mean 12.5" x 2", so focusing on one vendor's free solution is inflexible...
I must admit that EAGLE is the only PCB software that I really know anything about. Howevr I would be willing to wager a penny that it is the most widely used freeware for making PCBs
That being said, yes the current design and my focus on EAGLE is limited, but I am not inflexible, nor is the design. As it stands, in it's current design, the machine will be capable of 4" * 4", but I am sure that the design is easily adaptable to a larger size. If you look at the previous illustration for the carriage, the only real limiting factor for increasing the width of the X axis would be deflection issues of the guide rail support, but that could easily be made wider, made of a different material, or reinforced, so no big issue there. The Y axis is a slightly different story, but no major issue there either.
About the only real issue that I see, is bitmap support from the other software. EAGLE allows you to export bitmaps with a dpi setting, all the way up to 2400 dpi. So in other words, EAGLE will allow me to export a board image with my required dpi(s), which are:
I believe with a couple alterations of some drawings, I suppose I could easily support a 12" * 12" board. The main limiting factor, is the dpi(s) stated above. If other PCB software allows exportation of bitmaps with a user specified dpi setting, then I really don't see any major limitations, except for the time that it would take to produce a larger board. However production time may change, when I become better acquainted with the machine and photo resist, make alterations, etc...
PWM that nice and low, like 1/4096, and you should have no issues with the camera.
I just received my laser module today, but I am still waiting for the belts and pulleys, as well as a couple other things. Either way, I am still thinking about the design and my strategy. As you may have guessed, I am getting pretty eager to test a couple of things, but most importantly my dot size.
When you mentioned "1/4096" above, I am assuming that is meant to mean 4096 pulses per second. Is my assumption correct?
No, I meant PWM with a ratio of 1:4096 - There are a bunch of PWM objects available that let you specify the overall cycle length and the on time within that cycle. Turning the LED on for 1 count, and off for the other 4095, somewhat independent of the actual frequency, will get you a nice low power output. I'd PWM it as fast as you possibly can, as that'll interfere least with your process.
I finally got around to doing a little work on the controller today. The photo is not that great, but I believe you can clearly see the work that has been done. At this point, an SD micro card reader has been added, as well as two removable DRV8825 high current stepper drivers from Pololu. The harnesses for these two drivers are also removable.
I should be receiving an order from Digikey tomorrow, containing some of my missing parts, which includes, a 12V LDO regulator for the laser module, a 5V switching regulator for an LCD display, various connectors, and several capacitors.
After tomorrow, this board should start to take shape, and be able to provide some capabilities for it's intended purpose, such as driving the laser and steppers.
Anyhow, I know it is a little early for this and unfinished, but here is a photo of the board on it's way to becoming the controller for the new machine.
My parts arrived today, so I was able to do quite a bit more work to the controller.
As it stands now, the Propeller Project board now has four different nominal voltages, which are:
1. 3.3V for powering the Propeller chip, pushbuttons, and LEDs
2. 5.0V for powering the LCD display
3. 12.0V for powering the laser driver
4. 15.0V for running the stepper motors
Now I have to figure out how many pushbuttons and LEDs I want, and get all that circuitry to fit. I am running out of board space
At this point, I am beginning to think that I should supply the machine code via USB from a PC as compared to obtaining the machine code from a microSD card.
Although the controller is currently ready for microSD and an LCD display, I do believe it would be much easier to feed the machine code by USB, because in order to permit microSD navigation, I would now need to add IO expansion, which I can always do in the future, if the machine works. As it stands now, I do believe the controller is in good shape to accept PC supplied machine code.
I guess it all really boils down to the path of least resistance. All things considered, I do believe it would be much easier to create a PC application to perform all of the necessary tasks required for communication, as compared to completing all the necessary circuitry and machining that would be required for a stand alone machine that can navigate and run off of a microSD card.
I will certainly need to provide the machine with a USB port, for programming the Propeller chip, and since I must provide a USB port, I might as well just expand the PC application, to send the machine code.
If the machine works, then it would be well worth the effort of IO expansion, and thus making the machine PC compatible or a stand alone machine that can read and navigate microSD cards.
For the sake of testing / prototyping I'd say this makes the most sense. If you can prove that it works and decide you want to make it stand-alone, then decide if you want to pursue adding an SD interface. A PC-side app to feed it via serial should be fast enough to feed it - the mechanical speed will likely be the limiting factor, so even a relatively small read-ahead buffer should be plenty, and serial is easier on memory and cogs than an SD reader.
Way back when... I was working on an application to replace the Propeller Terminal, which is nearly completed, just never finished it up... Anyhow, at that time, USB for the Propeller was not around yet, so I was using a serial API for the task. Now that most, if not all of the Propeller boards, are USB, I had to do a little research, just to see if I could actually implement software for USB, without using the Windows driver SDK.
From my brief research, it appears that Parallax uses FTDIs 2.12.26 Virtual COM port (VCP) driver for the FT231X chip and FTDI has this to say about their VCP drivers:
Virtual COM port (VCP) drivers cause the USB device to appear as an additional COM port available to the PC. Application software can access the USB device in the same way as it would access a standard COM port.
Concerning FTDIs statement and from my deductions about Parallax's driver usage, I believe I can use the same serial API for communicating with the FT231X chip.
Besides working on this code, I now have my LCD display attached to the Prop BOE, and have been toying around with that a bit. I still need to do the bread boarding for the required pushbuttons, to navigate the file system. The pushbuttons will likely be comprised of the following:
scroll file list up the LCD display
scroll file list down the LCD display
select file or folder
confirm selection
reset LCD display to current directory
go to parent directory
When I wrote that code two years ago, the six button scheme was the best I could come up with at that time, for navigating through the file structure of an SD card, with the supplied code of course. Looking back, six buttons seems a bit overly complex, but it would do the trick. However, I did put some thought into the matter, while I pondered a better solution.... At first, I looked at Phil's "Goertzel-based speech recognizer" located here: forums.parallax.com/discussion/115725/goertzel-based-speech-recognizer-now-with-source-code/p1, which would be really cool to navigate the card with speech commands and eliminate button control altogether. And then I also thought about Micksters recommendation in another thread about the Micromite Explore 100, which can be seen in action in this video, https://youtube.com/watch?v=j12LidkzG2A which seems a bit of overkill for file navigation
If you have any ideas about the file navigation code linked to above and something better than a six button scheme, I would sure love to here it and I would be all ears.
At this point, I am still on the fence as to which way to go, however I am now leaning towards the hardware interface again :sick:
Use a rotary encoder with a button in it? They take 5 pins (less if you use a serial input chip) and are pretty easy to manage. Navigating long-ish menus is easier if you have a knob that clicks and can spin an arbitrary number of times. Sparkfun sells one I've used before, and I like it.
This layout was intended for a 4 X 4 X 16 enclosure and it was clearly drawn before I had worked on the SD navigation code, but at least I now have a better idea of what it would look like.
The enclosure for the LDI machine will be 4 X 10 X 12, with the 10 inch dimension being the front of the unit. Of course the button names would be different, but I think it might be okay.
My 3D printer uses this for input. It's not perfect, but for up/down/select/back it works really well - much better than buttons. For start / stop / pause you'd likely want distinct buttons.
Comments
You have a good point there. Perhaps a cigarette rolling paper would be better.
I am assuming that you read what I intend to do, since you have a valid response.
Here is an issue with my proposed plan...
As you may have read, I am using the bearing ID of the PCB driller as a reference measurement of 0.127 inches. If I don't have some sort of semi-translucent backstop at the bottom of the bearing, and just shoot straight into the camera, then I lose my reference measurement.
I am now thinking that some sort of backstop SHOULD be there, in order to establish size.
Unless of course you have a solution to establish size
The bottom of the bearing is approximately 5/8" above the webcam lense.
EDIT: But then the webcam wouldn't focus on something on top of the lens... ARRRRGGG
Or, just use it to evaluate the surface the laser hits too. Position it off axis and set focus to the target area.
Here's the thing: Those diodes will vary some. Everything does. In the end, your machine will need to adjust focus through some range.
For a given diode and target material, a direct observation focus will get you close. Real precision will need to be dynamic to get the resolution you want.
I would be surprised at the focus staying constant across anything other than a really small PCB, when using a near focus lens.
Do you have a height gauge and dial indicator?
Clean and clamp a nice chunk to a surface plate, or the best you have got. Run the gauge over it and see the flatness variation. There is a hint at that range. Call it a minimum. If you can't determine that range, your ability to measure, with the gear you have, isn't sufficient to succeed.
I would check that right away.
600 dpi is a .001666 spot size. Your average human hair cross section is .004. Human repeatability on standard measuring tools, caliper, height gauge, etc... sans dial indicator is .002. With indicator, you can improve on that approximately 5 to 10x, which puts your ability to measure in the range needed. 0.0002 - 4
Think about the cone shaped beam with a near focus lens. The closer the focal point is, the less tolerance you have to maintain spot size, thus the higher the precision requirement. And the lower the tolerance for part variations is too.
Honestly, you might consider researching lenses. One that has a more distant focal point will also make a much sharper cone, which can very significantly relax your precision requirement.
In short, you can engineer some of your difficulty away.
My goal is to know the dpi set by the pulleys and belts, and do my very best to match the laser to that dpi. Undoubtedly, there will be minor imperfections, due to board height variances, improper focus, etc..., simply because I do not have the time or money to put into these issues. However, I do want to be able to output the nicest board possible without the auto-focusing feature. I am not certain, but I believe that nice boards, although not perfect, can be made without auto-focus and though there may be slight variances in the thickness of material.
If a given track is supposed to be 10 mil wide throughout the whole trace, but there are areas along the trace where it jumps from 9 ~ 11 mil, I think I can live with that as long as it doesn't produce shorts or opens, and as long as the trace can carry the current that it needs for its intended purpose. In my eyes, this is meant to be a rough draft machine for prototyping circuitry, and any design flaws in the machine itself will most likely have to be taken into consideration, when designing a rough draft board.
Of course, I could be wrong about all of this, and all my time, effort, and money will have been wasted, but discovery is half the fun of doing what I do. Whatever I do, I either succeed or I fail
Indeed, 0.0016666666666666668" is a mighty fine dot, but the dot size I seek is much larger, which is 0.00167391304347826"
dataoptics.com/PDF/Pinholes%20%26%20Slits.pdf
I would find a lens with a long focal length. It will significantly improve dot size variations due to these variables.
Undoubtedly you are correct, on several issues, but I am first going to build it with what I have on hand and what I have already ordered. In other words, before I go seeking a special lens, I am certainly going to try the one I already have, and before I buy a precision made bed plate, I am certainly going to attempt it with the most true sheet stock I have available.
I am sure there will have to be many kinds of adjustments, in addition to lens changes and bed straightness, that I will have to make before I can get a decent board. The spring bender CNC took a lot of trial and error on a lot of the various assemblies just to get it to work properly. Although this machine is much less complicated in design and various assemblies than the spring bender, I am sure this machine will provide similar aggravation, especially since it will require much higher precision.
Lens focus and bed straightness, are just two of the problems involved, now consider the clearances required for X and Y axis travel. I am almost 99.9% certain that there has to be scan line overlap to account for these discrepancies.
@kwinn
After considering many different options, with various prerequisites in mind, and without switching to a gear driven system, 399 dpi (FULL Step)/598 dpi (HALF Step) was the best belt driven combination that I could come up with.
At this point, I am pretty much committed to 399 dpi (FULL Step)/598 dpi (HALF Step), because the belts and pulleys have been purchased and are on their way.
Just sharing experiences in the hope it helps.
There always is just build it, use it, and you get the dot you get. Then make the PCB that can be made.
Believe me, it helps. Odds are that I will most likely and eventually need a lens with a long focal length and a precision bed, but for now, I am just going for what I have on a hand and what I ordered.
Until the rest of my parts arrive, here is my current challenge...
As mentioned, this machine is designed around the EAGLE maximum board size for their freeware, so of course, considering the size of the board, it is not going to be a big machine, in fact it will be quite small. With this in mind, I have made every attempt to keep the footprint as small as possible, with an 1/8" or 1/16" here and there, meanwhile keeping the stages as light as possible, so less torque would be needed. During my research, I discovered that the laser must be held firmly, to provide any kind of decent output. So instead of going with single row V-groove bearings for the laser carriage, I decided to go with double row radial ball bearings, because I certainly want as little slop as possible for this carriage. To make a long story short, there will be a total of eight bearings for the carriage, with each bearing having a 1/4" ID, a 5/8" OD, and a 0.196" width, and two bearing sets, along with a spacer for each set, will be pressed into (4) steel V-groove sleeves, which I am currently turning on a wood lathe. The OD of each sleeve will be 7/8", the width of each sleeve will be 0.4545", and each sleeve will have an 80 degree V-groove cut across the center.
In the image below, you will see a side view of my carriage assembly, with the V-groove sleeves being cross sectioned. The laser housing, the laser module clamp, and the carriage are already made, and all I need to finish the carriage is those v-groove sleeves. Making those steel v-groove sleeves on a wood lathe is a real treat. So much fun, I can hardly control my excitement
I must admit that EAGLE is the only PCB software that I really know anything about. Howevr I would be willing to wager a penny that it is the most widely used freeware for making PCBs
That being said, yes the current design and my focus on EAGLE is limited, but I am not inflexible, nor is the design. As it stands, in it's current design, the machine will be capable of 4" * 4", but I am sure that the design is easily adaptable to a larger size. If you look at the previous illustration for the carriage, the only real limiting factor for increasing the width of the X axis would be deflection issues of the guide rail support, but that could easily be made wider, made of a different material, or reinforced, so no big issue there. The Y axis is a slightly different story, but no major issue there either.
About the only real issue that I see, is bitmap support from the other software. EAGLE allows you to export bitmaps with a dpi setting, all the way up to 2400 dpi. So in other words, EAGLE will allow me to export a board image with my required dpi(s), which are:
598 dpi HALF Step
1196 dpi QUARTER Step
2392 dpi EIGHTH Step
I believe with a couple alterations of some drawings, I suppose I could easily support a 12" * 12" board. The main limiting factor, is the dpi(s) stated above. If other PCB software allows exportation of bitmaps with a user specified dpi setting, then I really don't see any major limitations, except for the time that it would take to produce a larger board. However production time may change, when I become better acquainted with the machine and photo resist, make alterations, etc...
I just received my laser module today, but I am still waiting for the belts and pulleys, as well as a couple other things. Either way, I am still thinking about the design and my strategy. As you may have guessed, I am getting pretty eager to test a couple of things, but most importantly my dot size.
When you mentioned "1/4096" above, I am assuming that is meant to mean 4096 pulses per second. Is my assumption correct?
Thanks for the response. I appreciate you clarifying that for me, because I was clearly way off base
I finally got around to doing a little work on the controller today. The photo is not that great, but I believe you can clearly see the work that has been done. At this point, an SD micro card reader has been added, as well as two removable DRV8825 high current stepper drivers from Pololu. The harnesses for these two drivers are also removable.
I should be receiving an order from Digikey tomorrow, containing some of my missing parts, which includes, a 12V LDO regulator for the laser module, a 5V switching regulator for an LCD display, various connectors, and several capacitors.
After tomorrow, this board should start to take shape, and be able to provide some capabilities for it's intended purpose, such as driving the laser and steppers.
Anyhow, I know it is a little early for this and unfinished, but here is a photo of the board on it's way to becoming the controller for the new machine.
My parts arrived today, so I was able to do quite a bit more work to the controller.
As it stands now, the Propeller Project board now has four different nominal voltages, which are:
2. 5.0V for powering the LCD display
3. 12.0V for powering the laser driver
4. 15.0V for running the stepper motors
Now I have to figure out how many pushbuttons and LEDs I want, and get all that circuitry to fit. I am running out of board space
Although the controller is currently ready for microSD and an LCD display, I do believe it would be much easier to feed the machine code by USB, because in order to permit microSD navigation, I would now need to add IO expansion, which I can always do in the future, if the machine works. As it stands now, I do believe the controller is in good shape to accept PC supplied machine code.
I guess it all really boils down to the path of least resistance. All things considered, I do believe it would be much easier to create a PC application to perform all of the necessary tasks required for communication, as compared to completing all the necessary circuitry and machining that would be required for a stand alone machine that can navigate and run off of a microSD card.
I will certainly need to provide the machine with a USB port, for programming the Propeller chip, and since I must provide a USB port, I might as well just expand the PC application, to send the machine code.
If the machine works, then it would be well worth the effort of IO expansion, and thus making the machine PC compatible or a stand alone machine that can read and navigate microSD cards.
Way back when... I was working on an application to replace the Propeller Terminal, which is nearly completed, just never finished it up... Anyhow, at that time, USB for the Propeller was not around yet, so I was using a serial API for the task. Now that most, if not all of the Propeller boards, are USB, I had to do a little research, just to see if I could actually implement software for USB, without using the Windows driver SDK.
From my brief research, it appears that Parallax uses FTDIs 2.12.26 Virtual COM port (VCP) driver for the FT231X chip and FTDI has this to say about their VCP drivers:
Concerning FTDIs statement and from my deductions about Parallax's driver usage, I believe I can use the same serial API for communicating with the FT231X chip.
That being said, my main concern with making it stand alone pertains to this thread: forums.parallax.com/discussion/160923/c-simpleide-directory-listing-of-sd-card-files/p1
On page 2 of that thread, I state the following:
When I wrote that code two years ago, the six button scheme was the best I could come up with at that time, for navigating through the file structure of an SD card, with the supplied code of course. Looking back, six buttons seems a bit overly complex, but it would do the trick. However, I did put some thought into the matter, while I pondered a better solution.... At first, I looked at Phil's "Goertzel-based speech recognizer" located here: forums.parallax.com/discussion/115725/goertzel-based-speech-recognizer-now-with-source-code/p1, which would be really cool to navigate the card with speech commands and eliminate button control altogether. And then I also thought about Micksters recommendation in another thread about the Micromite Explore 100, which can be seen in action in this video, https://youtube.com/watch?v=j12LidkzG2A which seems a bit of overkill for file navigation
If you have any ideas about the file navigation code linked to above and something better than a six button scheme, I would sure love to here it and I would be all ears.
At this point, I am still on the fence as to which way to go, however I am now leaning towards the hardware interface again :sick:
Out of curiosity and since I could not readily find an illustration of the user interface that I intended for the 3D printer, I began looking in the older posts, trying to find one that I had posted many moons ago. Well, I found one... The illustration shown in the first post of this page, doesn't look too bad: forums.parallax.com/discussion/155404/input-needed-combining-propeller-proto-board-prop-dip-40-and-adc-for-3d-printer/p6
This layout was intended for a 4 X 4 X 16 enclosure and it was clearly drawn before I had worked on the SD navigation code, but at least I now have a better idea of what it would look like.
The enclosure for the LDI machine will be 4 X 10 X 12, with the 10 inch dimension being the front of the unit. Of course the button names would be different, but I think it might be okay.
If you can highlight or mark one item in the list, you need 2 buttons to scroll and one to select.
confirm could be the same as select, just pressed again.
back to parent is just selecting directory ".."
reset to current? what is that supposed to do?
Mike
(watch from about 1:22)
My 3D printer uses this for input. It's not perfect, but for up/down/select/back it works really well - much better than buttons. For start / stop / pause you'd likely want distinct buttons.