Well, I completely respect and agree with Jack's position.
In my own case, for the moment my efforts are focussed on the mechanical design phase. Compatible electronics and embedded (SX) motion software come later.
I intend to publish the mechanical design for hobby use, meaning that the design is not intended to be exploited for commercial gain. More specifically, I'd be REALLY annoyed if someone were to "lift" the essence of the design and then turned it into a product for sale, as I have some interest in that direction. Whereas for hobbyists, build all you want as long as you don't sell them.
As with the other contributors, I am going to significant expense in materials (over $1,000 so far) and time (using paid CAD designers and machinists) to build the prototypes. I expect that by the time I'm done this phase, the investment will be in the range of $25,000, and considerably more if we have to make molds for plastic pieces. So, I am looking to recoup that eventually through sales of the componenets and full kits. Thats where Parallax comes in as a distributor.
I intend to publish the dimensions and assembly details of the various components so that hobbyists capably talented and equipped, can choose to make or buy any or all pieces to build the standard design. Or alternately, only use some of the components such as recirculating slide bearings or the lead screws and design their own.
To ensure we have a design that can be built by a competent assembler with limited tools, I need to make the design as fool-proof as possible, and yet let the experimenter add his own flavor. To facilitate this, the machining of components will be done in-house on our CNC equipment (mill, lathe and punch), and 3 sizes of "kits" are being designed targeted to such an assembler, yielding a target accuracy of 0.002 or 0.003. Presently the kit includes the table and motion drive system, but no motors or electronics as these can be readily sourced elsewhere. The limit switches and "home" detectors are a critical element of the design precision, so they will be included, as will be the motor shaft couplers. Three (stepper) motor sizes are contemplated, perhaps not all three for each table size or each axis.
At a later date I expect to have drive motors and drive electronics and SX motion software available also, either in kit form or fully assembled. The issue here is that in supplying a complete kit we can better assure that the performance will be close to the tagrets.
As far as intellectual property rights go, I intend to retain those, and the SX embedded software that I design and supply in later phases of this project will only be released in binary form. Like Jack, I can't afford to give away my "bag of tricks"; it's all I have and they are the tools I use to make my living .
The premise of this "community" project was that everyone or anyone could participate and have access to all resources.
I understand how some libraries might be of proprietary use with your personal/business tasks and you don't want to release them....so maybe they don't get used....create new ones! (a pain indeed.....)
The second you start closing doors on different aspects of this "project"....it's no longer community based.....only in the polled questions/votes.
Anyhow, timelines can be quickly met if you use your 'tricks'.....going totally from scratch will take longer.....the caveat is obvious!
If the code goes open source, then up-and-comers will be able to learn from having the code to look at.
I won't build something that I can't tweak myself. My interest is shaky now.....(not that I'm the 'end-all-be-all'!)
Cheers
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·
Steve "Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
It's hard for some of us to draw the line between hobby and commercial. For all my commercial clients, NO ONE get source code, period. This in part is based on commercial self preservation, and also in part on support and liability. When we design a product we need to wrap some boundaries around it se we can clearly delineate where our responibilities and obligations end. Some of the work indeed is very tricky and having someone unsufficiently knowledgable "tweak" the code or hardware design can create a support nightmare, and it is our good reputation and competency that gets us the next job.
Also I suspect that commercial secrecy is exactly the reason why you have never seen Parallax publish the source code and inner workings of their SX Key debugger, or their basic interpreter, or (Al Williams' ?) floatng point co-processor. They are very cleverly designed, and their technical "one-up-manship" is the very essence of these business' commercial existence. Try and get the source code for someone's commercial software for free; it just won't happen from anyone who makes their living from selling exactly that.
I have nothing against those who want to "roll their own", and hence I am publishing the mechanical design for folks to use and modify as they wish. The caveat being of course that any "non-standard" design or sub standard fabrication may not yield the desired results. So for greater certainty the pre-made kits should eliminate or at least reduce the potential for disappointment.
Steve, I sincerely hope that you, or for that matter anyone else, will not throw in the towel on this project; even without full design disclosure there is much to be gained by participating and building one. It appears to me that there will be numerous sources for code as this thing develops, and some will be non-commercial in nature. Heavens, Jack appears to be willing to provide the binaries for free, just not the revealing source of his cleverness, and I can't blame him for that. The 1000 hours he anticipates putting into this effort should be indicative of his commitment and effort, and grant him some level of commercial protection.
Anyhow, I'm sure there are many views on this subject; these are mine, and I'm moving forward.
Well, I hope I haven't put a brake on the development efforts of PLJack and the others with my previous question. (about releasing the source code)
Anyhow, one of the reasons I was asking this is that I wanted to contribute to the development.
I don't have any mechanical skills, nor do I know anything about SX. (PIC microcontrollers I do know)
So, the only place I could contribute was the software. (and since my main job is software development ... )
I'm somewhat limited in time, (many projects at work and a newborn at home -> very short nights) but the few hours that I've left over I wanted to contribute to the software of this community PCB mill project.
Seen that I'm a bit limited in time, it was not an option for me to spend more than 1000 hours on this project. But I was willing to contribute the best I could to the software development.
I for one don't mind sharing my source code since I see it as a possibility for personal growth. -> all the feedback from the community can be an enormous learning experience with which I can improve my own skills.
But I do understand the commercial tradeoffs and I respect everyone's choice in this matter.
Note that I do believe that not releasing all of the source code doesn't have to be a problem.
It's a bit like with game development. The game developers don't release the source code for their games, instead they provide a well documented SDK with which users can tweak/change/modify/... the system.
And if a certain functionality is not present it can be added (read programmed) by the users.
A few posts ago I was also asking for an interface specification between the SX and the PC software. One of the reasons was that I wanted to contribute, but I also think this is a crucial bit of information for the complete system.
I think these crucial bits of the system need to be released. They need to be open and everyone should have the possibility to inspect them. Note that I'm not talking about the actual code here, but the actual specification/design of the system.
I would love to see some reaction of the guys from parallax. I'm really curious about which way they want to go with this.
And for peter, jack, bean and all the others contributing to this project: keep up the good work - it is REALLY appreciated!!!
Thanks for the encouragement Noxus, this is a pretty major effort, and from my side it's all going to take a while.
I agree that interfaces and protocols should be very much documented and open. Afterall, that is what permits inter-operability among different devices and modules. When these are well defined, anyone can add their own high level or low level software or hardware.
PC software free as well. Distributed as a ready to run package.
I apparently completely misunderstood this second statement, based of recent comments.· I can see how this initial statement could be understood to mean that PLJack had never ment anything other than binary distribution of the PC software.· However, the the juxtaposition of the "PC software free" with "SX source code is free" statment can be easily misunderstood, especially with the appellation of "communitity" project.
It is the perceived change of direction of the project from a community project to essentially an private research and development project that gave me concern.· I admit that I may have misunderstood the project's intention from the beginning.
In a much later message:
pjv said...
...those who are commercially in the elctronics/software design business have the intrinsic right to keep what they strive to create....
While I recognize all of the arguements put forth defending PLJack's statements, and notwithstanding the fact that I would be in general agreement of the defense of commercical interests, and futher not particularly wanting to pick a fight over semnatics, I do think that this statement, in this context, seems one-sided, as it appears to neglect the intrinsic rights of creativity of those outside the boundary drawn in that statement, specifically the rest of the participants in this project who do not stand to enjoy the economic benefit/risk.
I do recognize that pvj stated early and publicly his intention of kitting and marketing the mechanics of this mill, and given that early and frank disclosure, I had no problem with it.· I remain interested in the finished mechanicals, if/when they reach alpha/beta-testing or market readiness.·
I, too, go forward, but perhaps in a slightly different direction from the project at large.· My focus will be direct execution of G-Code in an embedded stepper controller: Stamp if possible; SX or other microcontroller if not.
I wasn't going to post my MF70 "Encore", but then I decided I would because there is a lesson to be learned here.
When you look at the photo, notice the big gouge at lower right. Things were going along nicely, until............my cutter plunged into the PC board and I had to hit the Panic Stop.· Why?· I didn't have it tight enough.· If you're using a .020 cutter, or maybe an .030, then tight is good enough, but if you're using a .125 cutter, turning at 20,000 rpm like I was, then it has to VERY TIGHT!· And I mean VERY, VERY TIGHT!· With a .125 cutter there is a tremendous, constant downward pull on the cutter, and if it is not two-blocked it will plunge, just like it did with me.
I reset the cutter, repositioned the X and Y tables and continued.· My dial indicators have a max range of 1.000 and I was travelling 0 to 3.400 and 0 to 1.200.· I positioned the indicators at max travel, noted the readings, and checked the indicators each time I was at max, which as you can see by the pattern, was a bunch.· I was never off by more than .001, so my compensation for backlash is working quite well.
This board is the interface for my BS2E, the LCD, the keypad, the Gecko drive and the IB463 drive.· Everything is tied to this board and gets routed to its destination.· Now I can get rid of my messy breadboard.
I have NOT copyrighted my submissions so far, I guess I should have.
I too will be looking to develop SX code to process G-Codes directly.
I may start with DXF files first since I'm more familar with them.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
As I understand copyright law, you have·copyright protection·for anything you create without the need to register it.· I'm sure someone else in these forums know more than I do, so if I'm wrong I will stand corrected.
We may be·worrying too much about what would be released as public information at this point. Good ol' market forces and creative developers will drive who releases what, whether for free or at a reasonable cost. In fact, as Jack pointed out, one of the most important points about the software is the following:
"b) There is nothing stopping anyone from plugging an off the shelf CNC motor control into this machine and using any software they wish."
He's exactly right, especially considering the popularity of the GeckoDrive stepper motor controllers and Mach2 software. For a couple hundred bucks you can build something with·the most basic functionality of a driver system made by Haas,·FlashCut,·and other big companies.
Once we've got a basic working mechanical system, some control hardware and software we'll see this evolve with all kinds of great solutions. Our intent is to keep this as open as possible to encourage community support, and I'm sure the key contributors will adjust their open-source contribution as appropriate.
Has anyone been able to check the SX "stepper.sxb" code with a real X-Y table ?
If so, can you give me/us some feedback.
My next step is to be able to receive some G-Codes and make lines.
I guess I'll need to get the Z-Axis working too.
P.S. Can someone please let me know what is a reasonable stepping speed (steps per second) for an X-Y table.
Both for moving and for milling (I would assume you move MUCH slower when milling).
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
A "rapid" move (that is G00) would be in the range of 10 inches/sec at the top end, and would be painfully slow (almost unusable) at 1 inch/sec.
With a lead screw pitch of 0.20 inches per revolution, and a motor with 200 full steps per revolution the distance per step is 0.001
The speeds for a G00 therefore are in the range of 10,000 steps per second or less. This might be "pushing" it for some circuitry or motors, but I believe that should be the target.
I have not had time to try out the software; perhaps this coming weekend, although I'm very booked.
Thanks Peter,
I imagine that the torque is quite low at 10,000 steps per second, I guess that's why we need Accel/Decel [noparse];)[/noparse]
I will try to make the speed 20,000 / speed factor (1 to 255). This will give me 2500 clocks per interrupt @ 50MHz.
So speed factor of 2 = 10K steps per second = 10.00 inches per second
and we can go down to less than 80 steps per second (speed factor = 255) = 0.08 inches per second
Does this make sense ?
EDIT: Let's make that 19,200 instead of 20,000·to match serial data speeds...
So 2 = 9,600 steps per second
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
I tried to use your sample stepper driver code to run my demo steppers but couldn't do it because your code drives each stepper coil directly, but my steppers are run by MC3479 controllers that need step and direction TTL inputs. But my motors aren't in an XY configuration anyway - they're just two motors mounted on a board for the most basic testing.
Okay here's the latest version.
I'm not sure if it works, but I would like thoses involed to give it a "sanity check" before I proceed to make everything interrupt driven.
It will accept g-code data in ASCII and sends back (1) when it has received a command string. And sends back (2) when it has COMPLETED the command string movement.
Comments please...Before I get too far along...
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
Hi Bean.
Code is looking very good.
A few questions though.
Is there a reason your are interpreting G-Code within the SX?
The PC software is doing all that for you.
Why are there no D codes?. For example, D1 would be to plunge Z into the material, D2 would be to lift Z.
Why support the "*" symbol at all?
If you plan to interpret G_Codes via SX be aware that G_code files come in many favors and can vary greatly.
If not you might want to rename any references to "G" and "M" to avoid any confusion.
' 0x01 = Received Command String
' 0x02 = Command Completed Successfully
I like this approach. Although the commands are unprintable, it's not a big thing though.
As for my side I will be posting an update in a day or two.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - PLJack - - -
Perfection in design is not achieved when there is nothing left to add. It is achieved when there is nothing left to take away.
Is there a reason your are interpreting G-Code within the SX?
Why are there no D codes?. For example, D1 would be to plunge Z into the material, D2 would be to lift Z.
Why support the "*" symbol at all?
If you plan to interpret G_Codes via SX be aware that G_code files come in many favors and can vary greatly.
If not you might want to rename any references to "G" and "M" to avoid any confusion.
' 0x01 = Received Command String
' 0x02 = Command Completed Successfully
I like this approach. Although the commands are unprintable, it's not a big thing though.
Jack,
· I was working from your basic stamp code.
· I thought maybe the SX could interprete G-Code...Hmmm maybe not.
··If we want to just pass the binary values then I guess I can forget about g-code and just make the primatives that the table needs to understand. Maybe something like:
I don't hear much about the hardware. Its the critical path to a reasonable CNC system. There are a wide variety of controllers and software from very good low cost, to very sophisticated systems. There are many suppliers of controllers and motors.
The real question for me is the CNC table, its design and cost. I've got motors and controllers sitting here, ready to install. I was going to build a Crankorgan.com Brute, but wasn't happy with the quality of aluminum extrusion I was able to find locally.
I'm looking for something small, able to work a 6 inch square area using 50 inch ounce motors. I'll bet some readers have much larger machines in mind.
The mission statement for this project is unclear to me.
I thought maybe the SX could interprete G-Code...Hmmm maybe not.
I guess it could. Its the variability of G-Code files that wold be the issue.
Some have line numbers, some don't. Some have drill apertures at the top, some don't. And so on.
Oops, Sorry that was Daniel's code.
I will work on changing the SX program to accept the "!M" type data format.
I think status/error codes will be returned to the PC as [noparse][[/noparse]"!S", value, checksum] with value and checksum being a binary byte.
"!S", 0 will mean accepted command
"!S", 1 will mean completed command
and so on... (of course the checksum byte will there too...)
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
I just ran across an announcement of a new book's 1-AUG release.· I dunno what it is really like, but might ease the pain.
The book is "Easy CNC", A Beginner's Guide to CNC"·, the link to the table of contents is http://www.imsrv.com/deskcnc/easyCNC.htm.· It is by David Benson (Square 1 Electronics) of the PIC'n series.
There is a lot in this post so if you are short on time come back later to read it.
It's time to move forward with the PC software. But first I need to explain my new position on the development and my solutions.
As for all this copyright talk. STOP!
This project is dead in the water if this becomes an issue. We all need to find a compromise.
As for the open source issue, I was not surprised at all when that came up. I was never crazy about holding all the code, but I think I made my point on that issue.
What I did find surprising was stopping development three times while we worked out these issues. I can't code like that.
So here is my solution.
The software is made up of half a dozen parts.
G-Code Parser:
Type Class
Includes: None
3rd Party: STL Vectors
Graphic Plotter:
Type Class
Includes: Parser
3rd Party: GR32
SX Plotter:
Type: Class
Includes: Parser
3rd Party: TurboPower Async
App Configuration:
Type: Class
Includes: None
3rd Party: Turbo Power Orpheus
Interface:
Type: Application
Includes: Parser, Graphic Plotter, SX Plotter, Configuration,
3rd Party: C++ Compiler of your choice.
Of all these classes, there are only two that are required to operate the machine.
The G-Code Parser and the SX Plotter. All the rest is just fluff. With these two classes anyone that can write software could communicate with the mill.
Having said all that I have decides to move the application in house. That means I would love to hear your suggestions but in order to stop development outages it is no longer a community project.
What IS a community project is the G-Code Parser and the SX Plotter.
When I feel these two classes are up to snuff I will release them to the community.
Then develop my application along side the community parser and plotter.
I will keep the master code up to date and release them as we add new features.
You can enhance these classes for yourself or add your enhancements to the master code for everyone to share.
In other words, I am still writing the SX Mill software. I'm just wrapping my wing around it in order to ensure it's survival. At the same time providing two open source classes.
Seems like a good solution.
I forget who mentioned the Bresenham formulas, but they work like a charm.
The software still has a long way to go. The parser still needs a little work to completely parse the BS1 G-Codes. After that I will work on enlarging support for more sophisticated G-Codes formats. At the same time I will rewrite the parser to be a little more cross platform friendly.
Instead of a software update I just made a SWF movie of the software in action.
I tried to upload them four times but failed. The movies are a little over 1.5mb via a dialup modem.
I think the upload time is confusing the forum.
I will upload them on Monday.
So, on to the SX protocol.
First off I think we should develop a schematic and parts list for the development proto board.
This would consist of one of those 10 buck SX proto boards, a MAXX chip and some leds to simulate X, Y and Z steppers. I assume the stepper control voltages can be seen via an LED. Or any cheap design you can think of.
We need a volunteer to design the development circuit that goes on the proto board and parts list.
With that we can develop a SX protocol and test it.
I would like everyone to talk about the protocol so that Bean can start nailing down some code.
Lets take a stab at a typical SX communication:
First, Bean brought up a great suggestion of CRC's. For those that do not know what CRC is, it's a method of detecting errors in a transmission. We really dont know what is going to be on the other side of this machine so CRC seems like a must for the protocol.
16bit numbers are send as two bytes at LSB or MSB. Whatever Bean prefers.
All the commands listed below are CRC and LSB(MSB) assumed.
Commas are for better readability.
I don't have Beans code in front of me so all of the below can be modified if needed.
Returns:
The MC can communicate via a one byte arrangement of bits. This will give up to eight channels of communication.
Bit 1 = "A" Command acknowledgment.
Bit 2 = "F" Command finished.
Bit 3 = "R" Ready to receive.
Etc.
With this method we can tell the PC more than one state at a time. For instance FR meaning the command is finished, and by the way I'm ready for more.
When the start project command is first given the first thing we need to do is ask the controller if it is alive and ready.
We will call this the JobStart command. This is basically a one character command.
PC > 'J' - 'AFR' < SX
This will do two things.
It will tell the PC that the motor controller is ready.
Allow Bean's code a chance to setup any variables that he may need to start a job.
Now we tell the motor controller a few things about the job.
I'm a big fan of prefixing so these types of things should be Initialize Commands and start with an 'I'. These only happen at the start of a job so performance is not an issue.
StepsPerInch, For the XYZ motors. For example "ISPI,100,100,98" would be X 100, Y 100 and Z 98.
ZeroPos, The position to consider zero. "IZP,1234, 1234" would be X 1234, Y 1234 from the machines ZP.
Plunge Speed, Speed, in steps per second, to move Z plunge commands.. "IP,100"
FastSpeed, Max steps per second.."IFS,100"
SlowSpeed, Min steps per second. "ISS,1"
RampSpeed, Multiplier for rampping. "IRS,50"
Etc...
Moving around.
Lets start with Z. there are a couple of maneuvers here we can do.
Plunge for drilling. This would be a one number command. "P,415" would be travel straight down 415 steps at Plunge Speed then retract 415 steps at Plunge Speed.
HeadCmd. If we avoid negative numbers we can get higher numbers with two bytes. Given that Z will often times be a low performance maneuver we should spend the extra byte for direction. "H, U, 1234". Move head up 1234 steps.
XY:
These commands will be the bottle neck of the system.
Things we need to know in order to move:
Speed,
Type of speed.
X position, 16bit number
Y position, 16bit number
Speed and speed type we can most likely fit into the first byte. 7 bits for a speed multiplier and 1 bit for linear or ramp movement.
If the SX recorded the last X and Y positions we could save from sending the from position and just send the to position.
So that would be a 6 byte command in all. Using a "Z" prefix. "Z, 253, 1234, 2345"
The SX will perform the Bresenham Line algorithm on all positions.
6N = 16 bit number
1N = 8 bit number
D = Direction
A = bit 1
F = bit 2
R = bit 3
SB = SpeedByte
Plunge 6N P AFR "P1254"
Head D6N H AFR "HU1235"
XYMove SB6N6N X AFR "X, 12, 14324, 25432"
Something like that.
This is the kind of stuff we need to nail down for Bean.
Fleshing out the protocol would be a large milestone in the project.
We still need to find some steppers for Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - PLJack - - -
Perfection in design is not achieved when there is nothing left to add. It is achieved when there is nothing left to take away.
There has been a lot of back and forth conversation about how to sense position using physical switches, grinding into end stops, etc. In the quest to re-invent the wheel, the solution that industry has used for years has been overlooked - use an optical slot sensor. There are numerous companies, but I happen to use Omron. Here is a pair of potential parts on the DigiKey site:
OR518-ND
OR562-ND
The first is designed to solder on a PCB, and the other has leads. In truth,you can solder leads onto the PCB version yourself.
I have also attached a pair of images showing similar devices mounted to a stepper motor. In this particular application, the sensors are mounted directly to the motor, and the the motor shaft has a disc with a slot in it. In the case of the mill, you would mount the sensor to a fixed part of the mill and attach a small metal tab to to a moving part. When the motor moves the axis, at some point the metal slot will pass through the sensor and the SX will note this and pass the info back to the PC. This will provide a very accurate zero position that can be found at any time. Remember, use the leading edge of when the tab first changes the state of the optical sensor. This provides an extremely high level of accuracy regardless of how wide the metal tab is.
This accuracy can be further amplified by also mounting a sensor on the motor as I have done in the attached images. In this case, the idea is to use the sensor on the machine as a a "coarse" position, and then use the one on the motor as a "fine" position. By mounting the fixed slot near one end of the axis travel, you will always approach it from a known position, and once the "coarse" sensor it found, it's simply a matter of continuing to travel in the same direction (although likely at a slower speed) until the "fine" sensor is found. At this point, the SX moves the axis back a pre-determined offset from the home sensor and tells the PC it is at "zero."
To prevent bad things happening, a physical switch is typically mounted past the home sensor and is used to tell the electronics that the end of safe travel has been reached and to stop moving the motors. This is the "limit switch", and it can be a physical switch rather than optical since it merely needs to indicate the rough end of travel, not the exact home position.
The idea of using physical switches for home sensors is bad because they have lots of slop and bounce and all sorts of built in errors.
The idea of grinding the axis into the end stops is bad becuase you put unneccasry wear and tear on the machine and the motors.
The optical sensors I mention here have a turn on/turn off time of 4 us. I haven't bothered to do the math for how far you'll travel in 4 millionths of a second when travelling at a few inches per second, but I can guarantee you it's really tiny.
Whether the SX parses G-Code or some other high level instruction set is largely moot. The single most important thing is that I think you've collectively realized that it must be a high level instruction and not single pulse information that is sent to the SX. Using a serial port as almost a direct drive system for the steppers is a completely flawed idea. The SX can guarantee pulse stability that is orders of magnitude higher than what the PC running a GUI can. The idea behind distributed CPUs is to have each do that things it is good at. The PC has gobs of memory and can parse like nobody's business. The SX can guarantee rock solid timing on each and every pulse it puts out. Let each do what it is good at.
Having said all of that, please stop re-inventing the wheel (again) and just use G-Code on the SX side. It was brought up that G-Code can arrive with many subtle formatting differences that are best parsed out by the PC, and hence it is a better idea to use some other language for communicating with the SX. While true, this is another case of re-inventing the wheel for very little gain. Basically, the PC will now have to translate from G-Code into "Community Mill Code" (a.k.a. CM-Code) and the CM-Code language will have to be defined, agreed upon, etc. Just skip the whole "lets make another language" thing and use G-Code.
The key you all have missed is that the PC should not be used to translate G-Code into the mythical CM-Code, but rather to clean up the G-Code and send it in a clean, known format without any of the spurious characters that might make parsing on the SX side harder. Furthermore, it can translate (or in essence compile) all known G-Codes into an agreed upon subset of codes for the SX, allowing further simplification on the SX side of things. In other words, let the PC remove the inconsistency and variation and provide clean, vanilla G-Code to the SX using a fixed number of agreed upon G-codes.
Here are the advantages:
1 - You have the SX parsing an industry standard, but allow the SX parsing code to be simpler since it doesn't have to handle every variation of formatting under the sun.
2 - You don't waste time trying to come up with the rules, etc for CM-Code.
3 - You can agree to a subset of G-Code for the SX and let the PC translate any instructions that are outside of that subset into only the agreed upon G-Codes. If the PC code convert any known G-Code instruction into CM-Code, it can convert any known G-Code instruction into the agreed upon subset just as easily.
Your description of homing is precisely what I intend to implement in the mill's mechanical design, with the small exception that the rotary sensing will also be done by an appropriately activated switch.
Regarding the G Code issue, in principle I think your comments are well founded, however........ IF the target tool-path speed is sufficiently high, the SX could have trouble calculating the step rates for making complex moves, in particular arcs and circles. Bearing in mind it is imperative that tool movements must NEVER be interrupted until each is completed, even while some communication or action occurs within the SX. Such an interruption guarantees breaking bits and taps, as well as making "interrupted cut" blemishes in a milled surface. In essence the software must be multi-tasking; X, Y, Z steps at varying rates, communication with the PC, sensing limit and safety swithches, controlling the power supply level for each axis, and for some users even controlling the spindle speed, or controlling some "other" tool mounted on the Z axis.
So, the "best" answer is not obvious, and Bean's (much) earlier suggestion of having the SX only do relatively simple tasks seems like a good idea; making one or more complete tool moves by building list of step primitives in an SX buffer for realtime execution.
This then implies that the SX will NOT be doing the G Code interpretation.
This is probably the final presentation in the MF70 trilogy.· The significant difference in this PB board and the other two is that this one was
COMPLETELY computer controlled.· I pressed a key to start and away she went.· When it got to the end at right center, the program gave me a pause to raise the cutter, then it returned to origin.· The X table was .001 short of 0, the Y table .001 over.··Had the Z axis drive been finished I could have drilled holes at any point.· Oh, well.............
Comments
Well, I completely respect and agree with Jack's position.
In my own case, for the moment my efforts are focussed on the mechanical design phase. Compatible electronics and embedded (SX) motion software come later.
I intend to publish the mechanical design for hobby use, meaning that the design is not intended to be exploited for commercial gain. More specifically, I'd be REALLY annoyed if someone were to "lift" the essence of the design and then turned it into a product for sale, as I have some interest in that direction. Whereas for hobbyists, build all you want as long as you don't sell them.
As with the other contributors, I am going to significant expense in materials (over $1,000 so far) and time (using paid CAD designers and machinists) to build the prototypes. I expect that by the time I'm done this phase, the investment will be in the range of $25,000, and considerably more if we have to make molds for plastic pieces. So, I am looking to recoup that eventually through sales of the componenets and full kits. Thats where Parallax comes in as a distributor.
I intend to publish the dimensions and assembly details of the various components so that hobbyists capably talented and equipped, can choose to make or buy any or all pieces to build the standard design. Or alternately, only use some of the components such as recirculating slide bearings or the lead screws and design their own.
To ensure we have a design that can be built by a competent assembler with limited tools, I need to make the design as fool-proof as possible, and yet let the experimenter add his own flavor. To facilitate this, the machining of components will be done in-house on our CNC equipment (mill, lathe and punch), and 3 sizes of "kits" are being designed targeted to such an assembler, yielding a target accuracy of 0.002 or 0.003. Presently the kit includes the table and motion drive system, but no motors or electronics as these can be readily sourced elsewhere. The limit switches and "home" detectors are a critical element of the design precision, so they will be included, as will be the motor shaft couplers. Three (stepper) motor sizes are contemplated, perhaps not all three for each table size or each axis.
At a later date I expect to have drive motors and drive electronics and SX motion software available also, either in kit form or fully assembled. The issue here is that in supplying a complete kit we can better assure that the performance will be close to the tagrets.
As far as intellectual property rights go, I intend to retain those, and the SX embedded software that I design and supply in later phases of this project will only be released in binary form. Like Jack, I can't afford to give away my "bag of tricks"; it's all I have and they are the tools I use to make my living .
Hope this makes my intent clear.
Peter (pjv)
The premise of this "community" project was that everyone or anyone could participate and have access to all resources.
I understand how some libraries might be of proprietary use with your personal/business tasks and you don't want to release them....so maybe they don't get used....create new ones! (a pain indeed.....)
The second you start closing doors on different aspects of this "project"....it's no longer community based.....only in the polled questions/votes.
Anyhow, timelines can be quickly met if you use your 'tricks'.....going totally from scratch will take longer.....the caveat is obvious!
If the code goes open source, then up-and-comers will be able to learn from having the code to look at.
I won't build something that I can't tweak myself. My interest is shaky now.....(not that I'm the 'end-all-be-all'!)
Cheers
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
Steve
"Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
It's hard for some of us to draw the line between hobby and commercial. For all my commercial clients, NO ONE get source code, period. This in part is based on commercial self preservation, and also in part on support and liability. When we design a product we need to wrap some boundaries around it se we can clearly delineate where our responibilities and obligations end. Some of the work indeed is very tricky and having someone unsufficiently knowledgable "tweak" the code or hardware design can create a support nightmare, and it is our good reputation and competency that gets us the next job.
Also I suspect that commercial secrecy is exactly the reason why you have never seen Parallax publish the source code and inner workings of their SX Key debugger, or their basic interpreter, or (Al Williams' ?) floatng point co-processor. They are very cleverly designed, and their technical "one-up-manship" is the very essence of these business' commercial existence. Try and get the source code for someone's commercial software for free; it just won't happen from anyone who makes their living from selling exactly that.
I have nothing against those who want to "roll their own", and hence I am publishing the mechanical design for folks to use and modify as they wish. The caveat being of course that any "non-standard" design or sub standard fabrication may not yield the desired results. So for greater certainty the pre-made kits should eliminate or at least reduce the potential for disappointment.
Steve, I sincerely hope that you, or for that matter anyone else, will not throw in the towel on this project; even without full design disclosure there is much to be gained by participating and building one. It appears to me that there will be numerous sources for code as this thing develops, and some will be non-commercial in nature. Heavens, Jack appears to be willing to provide the binaries for free, just not the revealing source of his cleverness, and I can't blame him for that. The 1000 hours he anticipates putting into this effort should be indicative of his commitment and effort, and grant him some level of commercial protection.
Anyhow, I'm sure there are many views on this subject; these are mine, and I'm moving forward.
Cheers,
Peter (pjv)
Well, I hope I haven't put a brake on the development efforts of PLJack and the others with my previous question. (about releasing the source code)
Anyhow, one of the reasons I was asking this is that I wanted to contribute to the development.
I don't have any mechanical skills, nor do I know anything about SX. (PIC microcontrollers I do know)
So, the only place I could contribute was the software. (and since my main job is software development ... )
I'm somewhat limited in time, (many projects at work and a newborn at home -> very short nights) but the few hours that I've left over I wanted to contribute to the software of this community PCB mill project.
Seen that I'm a bit limited in time, it was not an option for me to spend more than 1000 hours on this project. But I was willing to contribute the best I could to the software development.
I for one don't mind sharing my source code since I see it as a possibility for personal growth. -> all the feedback from the community can be an enormous learning experience with which I can improve my own skills.
But I do understand the commercial tradeoffs and I respect everyone's choice in this matter.
Note that I do believe that not releasing all of the source code doesn't have to be a problem.
It's a bit like with game development. The game developers don't release the source code for their games, instead they provide a well documented SDK with which users can tweak/change/modify/... the system.
And if a certain functionality is not present it can be added (read programmed) by the users.
A few posts ago I was also asking for an interface specification between the SX and the PC software. One of the reasons was that I wanted to contribute, but I also think this is a crucial bit of information for the complete system.
I think these crucial bits of the system need to be released. They need to be open and everyone should have the possibility to inspect them. Note that I'm not talking about the actual code here, but the actual specification/design of the system.
I would love to see some reaction of the guys from parallax. I'm really curious about which way they want to go with this.
And for peter, jack, bean and all the others contributing to this project: keep up the good work - it is REALLY appreciated!!!
Bye for now,
noxus
I agree that interfaces and protocols should be very much documented and open. Afterall, that is what permits inter-operability among different devices and modules. When these are well defined, anyone can add their own high level or low level software or hardware.
Cheers,
Peter (pjv)
I apparently completely misunderstood this second statement, based of recent comments.· I can see how this initial statement could be understood to mean that PLJack had never ment anything other than binary distribution of the PC software.· However, the the juxtaposition of the "PC software free" with "SX source code is free" statment can be easily misunderstood, especially with the appellation of "communitity" project.
It is the perceived change of direction of the project from a community project to essentially an private research and development project that gave me concern.· I admit that I may have misunderstood the project's intention from the beginning.
In a much later message: While I recognize all of the arguements put forth defending PLJack's statements, and notwithstanding the fact that I would be in general agreement of the defense of commercical interests, and futher not particularly wanting to pick a fight over semnatics, I do think that this statement, in this context, seems one-sided, as it appears to neglect the intrinsic rights of creativity of those outside the boundary drawn in that statement, specifically the rest of the participants in this project who do not stand to enjoy the economic benefit/risk.
I do recognize that pvj stated early and publicly his intention of kitting and marketing the mechanics of this mill, and given that early and frank disclosure, I had no problem with it.· I remain interested in the finished mechanicals, if/when they reach alpha/beta-testing or market readiness.·
I, too, go forward, but perhaps in a slightly different direction from the project at large.· My focus will be direct execution of G-Code in an embedded stepper controller: Stamp if possible; SX or other microcontroller if not.
Daniel
When you look at the photo, notice the big gouge at lower right. Things were going along nicely, until............my cutter plunged into the PC board and I had to hit the Panic Stop.· Why?· I didn't have it tight enough.· If you're using a .020 cutter, or maybe an .030, then tight is good enough, but if you're using a .125 cutter, turning at 20,000 rpm like I was, then it has to VERY TIGHT!· And I mean VERY, VERY TIGHT!· With a .125 cutter there is a tremendous, constant downward pull on the cutter, and if it is not two-blocked it will plunge, just like it did with me.
I reset the cutter, repositioned the X and Y tables and continued.· My dial indicators have a max range of 1.000 and I was travelling 0 to 3.400 and 0 to 1.200.· I positioned the indicators at max travel, noted the readings, and checked the indicators each time I was at max, which as you can see by the pattern, was a bunch.· I was never off by more than .001, so my compensation for backlash is working quite well.
This board is the interface for my BS2E, the LCD, the keypad, the Gecko drive and the IB463 drive.· Everything is tied to this board and gets routed to its destination.· Now I can get rid of my messy breadboard.
The MF70 charges on!
Sid
I too will be looking to develop SX code to process G-Codes directly.
I may start with DXF files first since I'm more familar with them.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
Product web site: www.sxvm.com
"One experiment is worth a thousand theories"
·
As I understand copyright law, you have·copyright protection·for anything you create without the need to register it.· I'm sure someone else in these forums know more than I do, so if I'm wrong I will stand corrected.
Chris I.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
Product web site: www.sxvm.com
"One experiment is worth a thousand theories"
·
We may be·worrying too much about what would be released as public information at this point. Good ol' market forces and creative developers will drive who releases what, whether for free or at a reasonable cost. In fact, as Jack pointed out, one of the most important points about the software is the following:
"b) There is nothing stopping anyone from plugging an off the shelf CNC motor control into this machine and using any software they wish."
He's exactly right, especially considering the popularity of the GeckoDrive stepper motor controllers and Mach2 software. For a couple hundred bucks you can build something with·the most basic functionality of a driver system made by Haas,·FlashCut,·and other big companies.
Once we've got a basic working mechanical system, some control hardware and software we'll see this evolve with all kinds of great solutions. Our intent is to keep this as open as possible to encourage community support, and I'm sure the key contributors will adjust their open-source contribution as appropriate.
Ken Gracey
Parallax, Inc.
If so, can you give me/us some feedback.
My next step is to be able to receive some G-Codes and make lines.
I guess I'll need to get the Z-Axis working too.
P.S. Can someone please let me know what is a reasonable stepping speed (steps per second) for an X-Y table.
Both for moving and for milling (I would assume you move MUCH slower when milling).
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
Product web site: www.sxvm.com
"One experiment is worth a thousand theories"
Post Edited (Bean (Hitt Consulting)) : 7/26/2005 4:57:39 PM GMT
A "rapid" move (that is G00) would be in the range of 10 inches/sec at the top end, and would be painfully slow (almost unusable) at 1 inch/sec.
With a lead screw pitch of 0.20 inches per revolution, and a motor with 200 full steps per revolution the distance per step is 0.001
The speeds for a G00 therefore are in the range of 10,000 steps per second or less. This might be "pushing" it for some circuitry or motors, but I believe that should be the target.
I have not had time to try out the software; perhaps this coming weekend, although I'm very booked.
Cheers,
Peter (pjv)
I imagine that the torque is quite low at 10,000 steps per second, I guess that's why we need Accel/Decel [noparse];)[/noparse]
I will try to make the speed 20,000 / speed factor (1 to 255). This will give me 2500 clocks per interrupt @ 50MHz.
So speed factor of 2 = 10K steps per second = 10.00 inches per second
and we can go down to less than 80 steps per second (speed factor = 255) = 0.08 inches per second
Does this make sense ?
EDIT: Let's make that 19,200 instead of 20,000·to match serial data speeds...
So 2 = 9,600 steps per second
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
Product web site: www.sxvm.com
"One experiment is worth a thousand theories"
Post Edited (Bean (Hitt Consulting)) : 7/26/2005 9:00:09 PM GMT
I tried to use your sample stepper driver code to run my demo steppers but couldn't do it because your code drives each stepper coil directly, but my steppers are run by MC3479 controllers that need step and direction TTL inputs. But my motors aren't in an XY configuration anyway - they're just two motors mounted on a board for the most basic testing.
David
I'm not sure if it works, but I would like thoses involed to give it a "sanity check" before I proceed to make everything interrupt driven.
It will accept g-code data in ASCII and sends back (1) when it has received a command string. And sends back (2) when it has COMPLETED the command string movement.
Comments please...Before I get too far along...
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
Product web site: www.sxvm.com
"One experiment is worth a thousand theories"
Code is looking very good.
A few questions though.
Is there a reason your are interpreting G-Code within the SX?
The PC software is doing all that for you.
Why are there no D codes?. For example, D1 would be to plunge Z into the material, D2 would be to lift Z.
Why support the "*" symbol at all?
If you plan to interpret G_Codes via SX be aware that G_code files come in many favors and can vary greatly.
If not you might want to rename any references to "G" and "M" to avoid any confusion.
' 0x01 = Received Command String
' 0x02 = Command Completed Successfully
I like this approach. Although the commands are unprintable, it's not a big thing though.
As for my side I will be posting an update in a day or two.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - PLJack - - -
Perfection in design is not achieved when there is nothing left to add.
It is achieved when there is nothing left to take away.
· I was working from your basic stamp code.
· I thought maybe the SX could interprete G-Code...Hmmm maybe not.
··If we want to just pass the binary values then I guess I can forget about g-code and just make the primatives that the table needs to understand. Maybe something like:
·"!M" (for move)·X-delta LSB, X-delta MSB, Y-delta LSB, Y-delta MSB, Z-delta LSB, Z-delta MSB, Speed, checksum
·"!H" (for home) checksum
·"!P" (for pause) milliseconds, checksum
· This will make the code MUCH simpler.
· This is exactly why I posted to get some feedback, Thanks Jack.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
Product web site: www.sxvm.com
"One experiment is worth a thousand theories"
·
The real question for me is the CNC table, its design and cost. I've got motors and controllers sitting here, ready to install. I was going to build a Crankorgan.com Brute, but wasn't happy with the quality of aluminum extrusion I was able to find locally.
I'm looking for something small, able to work a 6 inch square area using 50 inch ounce motors. I'll bet some readers have much larger machines in mind.
The mission statement for this project is unclear to me.
My what?
I guess it could. Its the variability of G-Code files that wold be the issue.
Some have line numbers, some don't. Some have drill apertures at the top, some don't. And so on.
That looks more like a micro controller protocol.
That is why I brought it up. I would hate for you to go through G_code hell as I am right now.
I have to go now, I will post tomorrow night.
Then we should start focusing on the SX protocol so that you have a road map to follow.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - PLJack - - -
Perfection in design is not achieved when there is nothing left to add.
It is achieved when there is nothing left to take away.
I will work on changing the SX program to accept the "!M" type data format.
I think status/error codes will be returned to the PC as [noparse][[/noparse]"!S", value, checksum] with value and checksum being a binary byte.
"!S", 0 will mean accepted command
"!S", 1 will mean completed command
and so on... (of course the checksum byte will there too...)
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
Product web site: www.sxvm.com
"One experiment is worth a thousand theories"
·
Scroll back a page or two... Peter(pjv) has been doing some heavy duty work under wraps. Check his post made on 7/22/2005 9:00 PM (GMT -6).
-dave
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
This is not a sig. This is a duck. Quack.
The book is "Easy CNC", A Beginner's Guide to CNC"·, the link to the table of contents is http://www.imsrv.com/deskcnc/easyCNC.htm.· It is by David Benson (Square 1 Electronics) of the PIC'n series.
Daniel
There is a lot in this post so if you are short on time come back later to read it.
It's time to move forward with the PC software. But first I need to explain my new position on the development and my solutions.
As for all this copyright talk. STOP!
This project is dead in the water if this becomes an issue. We all need to find a compromise.
As for the open source issue, I was not surprised at all when that came up. I was never crazy about holding all the code, but I think I made my point on that issue.
What I did find surprising was stopping development three times while we worked out these issues. I can't code like that.
So here is my solution.
The software is made up of half a dozen parts.
G-Code Parser:
Type Class
Includes: None
3rd Party: STL Vectors
Graphic Plotter:
Type Class
Includes: Parser
3rd Party: GR32
SX Plotter:
Type: Class
Includes: Parser
3rd Party: TurboPower Async
App Configuration:
Type: Class
Includes: None
3rd Party: Turbo Power Orpheus
Interface:
Type: Application
Includes: Parser, Graphic Plotter, SX Plotter, Configuration,
3rd Party: C++ Compiler of your choice.
Of all these classes, there are only two that are required to operate the machine.
The G-Code Parser and the SX Plotter. All the rest is just fluff. With these two classes anyone that can write software could communicate with the mill.
Having said all that I have decides to move the application in house. That means I would love to hear your suggestions but in order to stop development outages it is no longer a community project.
What IS a community project is the G-Code Parser and the SX Plotter.
When I feel these two classes are up to snuff I will release them to the community.
Then develop my application along side the community parser and plotter.
I will keep the master code up to date and release them as we add new features.
You can enhance these classes for yourself or add your enhancements to the master code for everyone to share.
In other words, I am still writing the SX Mill software. I'm just wrapping my wing around it in order to ensure it's survival. At the same time providing two open source classes.
Seems like a good solution.
I forget who mentioned the Bresenham formulas, but they work like a charm.
The software still has a long way to go. The parser still needs a little work to completely parse the BS1 G-Codes. After that I will work on enlarging support for more sophisticated G-Codes formats. At the same time I will rewrite the parser to be a little more cross platform friendly.
Instead of a software update I just made a SWF movie of the software in action.
I tried to upload them four times but failed. The movies are a little over 1.5mb via a dialup modem.
I think the upload time is confusing the forum.
I will upload them on Monday.
So, on to the SX protocol.
First off I think we should develop a schematic and parts list for the development proto board.
This would consist of one of those 10 buck SX proto boards, a MAXX chip and some leds to simulate X, Y and Z steppers. I assume the stepper control voltages can be seen via an LED. Or any cheap design you can think of.
We need a volunteer to design the development circuit that goes on the proto board and parts list.
With that we can develop a SX protocol and test it.
I would like everyone to talk about the protocol so that Bean can start nailing down some code.
Lets take a stab at a typical SX communication:
First, Bean brought up a great suggestion of CRC's. For those that do not know what CRC is, it's a method of detecting errors in a transmission. We really dont know what is going to be on the other side of this machine so CRC seems like a must for the protocol.
16bit numbers are send as two bytes at LSB or MSB. Whatever Bean prefers.
All the commands listed below are CRC and LSB(MSB) assumed.
Commas are for better readability.
I don't have Beans code in front of me so all of the below can be modified if needed.
Returns:
The MC can communicate via a one byte arrangement of bits. This will give up to eight channels of communication.
Bit 1 = "A" Command acknowledgment.
Bit 2 = "F" Command finished.
Bit 3 = "R" Ready to receive.
Etc.
With this method we can tell the PC more than one state at a time. For instance FR meaning the command is finished, and by the way I'm ready for more.
When the start project command is first given the first thing we need to do is ask the controller if it is alive and ready.
We will call this the JobStart command. This is basically a one character command.
PC > 'J' - 'AFR' < SX
This will do two things.
It will tell the PC that the motor controller is ready.
Allow Bean's code a chance to setup any variables that he may need to start a job.
Now we tell the motor controller a few things about the job.
I'm a big fan of prefixing so these types of things should be Initialize Commands and start with an 'I'. These only happen at the start of a job so performance is not an issue.
StepsPerInch, For the XYZ motors. For example "ISPI,100,100,98" would be X 100, Y 100 and Z 98.
ZeroPos, The position to consider zero. "IZP,1234, 1234" would be X 1234, Y 1234 from the machines ZP.
Plunge Speed, Speed, in steps per second, to move Z plunge commands.. "IP,100"
FastSpeed, Max steps per second.."IFS,100"
SlowSpeed, Min steps per second. "ISS,1"
RampSpeed, Multiplier for rampping. "IRS,50"
Etc...
Moving around.
Lets start with Z. there are a couple of maneuvers here we can do.
Plunge for drilling. This would be a one number command. "P,415" would be travel straight down 415 steps at Plunge Speed then retract 415 steps at Plunge Speed.
HeadCmd. If we avoid negative numbers we can get higher numbers with two bytes. Given that Z will often times be a low performance maneuver we should spend the extra byte for direction. "H, U, 1234". Move head up 1234 steps.
XY:
These commands will be the bottle neck of the system.
Things we need to know in order to move:
Speed,
Type of speed.
X position, 16bit number
Y position, 16bit number
Speed and speed type we can most likely fit into the first byte. 7 bits for a speed multiplier and 1 bit for linear or ramp movement.
If the SX recorded the last X and Y positions we could save from sending the from position and just send the to position.
So that would be a 6 byte command in all. Using a "Z" prefix. "Z, 253, 1234, 2345"
The SX will perform the Bresenham Line algorithm on all positions.
6N = 16 bit number
1N = 8 bit number
D = Direction
A = bit 1
F = bit 2
R = bit 3
SB = SpeedByte
Name Send Receive Example
JobStart J AFR "J"
StepsPerInch 6N6N6N ISPI AFR "ISP,100,100,98"
PlundgeSpeed IP AFR "IP, 100"
ZeroPos 6N6N IZP AFR "IZP, 1234, 1234"
FastSpeed 6N IFS AFR "IFS,100"
SlowSpeed 1N ISS AFR "ISS,1"
RampSpeed 1N IRS AFR "IRS,50"
Plunge 6N P AFR "P1254"
Head D6N H AFR "HU1235"
XYMove SB6N6N X AFR "X, 12, 14324, 25432"
Something like that.
This is the kind of stuff we need to nail down for Bean.
Fleshing out the protocol would be a large milestone in the project.
We still need to find some steppers for Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - PLJack - - -
Perfection in design is not achieved when there is nothing left to add.
It is achieved when there is nothing left to take away.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - PLJack - - -
Perfection in design is not achieved when there is nothing left to add.
It is achieved when there is nothing left to take away.
There has been a lot of back and forth conversation about how to sense position using physical switches, grinding into end stops, etc. In the quest to re-invent the wheel, the solution that industry has used for years has been overlooked - use an optical slot sensor. There are numerous companies, but I happen to use Omron. Here is a pair of potential parts on the DigiKey site:
OR518-ND
OR562-ND
The first is designed to solder on a PCB, and the other has leads. In truth,you can solder leads onto the PCB version yourself.
I have also attached a pair of images showing similar devices mounted to a stepper motor. In this particular application, the sensors are mounted directly to the motor, and the the motor shaft has a disc with a slot in it. In the case of the mill, you would mount the sensor to a fixed part of the mill and attach a small metal tab to to a moving part. When the motor moves the axis, at some point the metal slot will pass through the sensor and the SX will note this and pass the info back to the PC. This will provide a very accurate zero position that can be found at any time. Remember, use the leading edge of when the tab first changes the state of the optical sensor. This provides an extremely high level of accuracy regardless of how wide the metal tab is.
This accuracy can be further amplified by also mounting a sensor on the motor as I have done in the attached images. In this case, the idea is to use the sensor on the machine as a a "coarse" position, and then use the one on the motor as a "fine" position. By mounting the fixed slot near one end of the axis travel, you will always approach it from a known position, and once the "coarse" sensor it found, it's simply a matter of continuing to travel in the same direction (although likely at a slower speed) until the "fine" sensor is found. At this point, the SX moves the axis back a pre-determined offset from the home sensor and tells the PC it is at "zero."
To prevent bad things happening, a physical switch is typically mounted past the home sensor and is used to tell the electronics that the end of safe travel has been reached and to stop moving the motors. This is the "limit switch", and it can be a physical switch rather than optical since it merely needs to indicate the rough end of travel, not the exact home position.
The idea of using physical switches for home sensors is bad because they have lots of slop and bounce and all sorts of built in errors.
The idea of grinding the axis into the end stops is bad becuase you put unneccasry wear and tear on the machine and the motors.
The optical sensors I mention here have a turn on/turn off time of 4 us. I haven't bothered to do the math for how far you'll travel in 4 millionths of a second when travelling at a few inches per second, but I can guarantee you it's really tiny.
Thanks, PeterM
Whether the SX parses G-Code or some other high level instruction set is largely moot. The single most important thing is that I think you've collectively realized that it must be a high level instruction and not single pulse information that is sent to the SX. Using a serial port as almost a direct drive system for the steppers is a completely flawed idea. The SX can guarantee pulse stability that is orders of magnitude higher than what the PC running a GUI can. The idea behind distributed CPUs is to have each do that things it is good at. The PC has gobs of memory and can parse like nobody's business. The SX can guarantee rock solid timing on each and every pulse it puts out. Let each do what it is good at.
Having said all of that, please stop re-inventing the wheel (again) and just use G-Code on the SX side. It was brought up that G-Code can arrive with many subtle formatting differences that are best parsed out by the PC, and hence it is a better idea to use some other language for communicating with the SX. While true, this is another case of re-inventing the wheel for very little gain. Basically, the PC will now have to translate from G-Code into "Community Mill Code" (a.k.a. CM-Code) and the CM-Code language will have to be defined, agreed upon, etc. Just skip the whole "lets make another language" thing and use G-Code.
The key you all have missed is that the PC should not be used to translate G-Code into the mythical CM-Code, but rather to clean up the G-Code and send it in a clean, known format without any of the spurious characters that might make parsing on the SX side harder. Furthermore, it can translate (or in essence compile) all known G-Codes into an agreed upon subset of codes for the SX, allowing further simplification on the SX side of things. In other words, let the PC remove the inconsistency and variation and provide clean, vanilla G-Code to the SX using a fixed number of agreed upon G-codes.
Here are the advantages:
1 - You have the SX parsing an industry standard, but allow the SX parsing code to be simpler since it doesn't have to handle every variation of formatting under the sun.
2 - You don't waste time trying to come up with the rules, etc for CM-Code.
3 - You can agree to a subset of G-Code for the SX and let the PC translate any instructions that are outside of that subset into only the agreed upon G-Codes. If the PC code convert any known G-Code instruction into CM-Code, it can convert any known G-Code instruction into the agreed upon subset just as easily.
Thanks, PeterM
Your description of homing is precisely what I intend to implement in the mill's mechanical design, with the small exception that the rotary sensing will also be done by an appropriately activated switch.
Regarding the G Code issue, in principle I think your comments are well founded, however........ IF the target tool-path speed is sufficiently high, the SX could have trouble calculating the step rates for making complex moves, in particular arcs and circles. Bearing in mind it is imperative that tool movements must NEVER be interrupted until each is completed, even while some communication or action occurs within the SX. Such an interruption guarantees breaking bits and taps, as well as making "interrupted cut" blemishes in a milled surface. In essence the software must be multi-tasking; X, Y, Z steps at varying rates, communication with the PC, sensing limit and safety swithches, controlling the power supply level for each axis, and for some users even controlling the spindle speed, or controlling some "other" tool mounted on the Z axis.
So, the "best" answer is not obvious, and Bean's (much) earlier suggestion of having the SX only do relatively simple tasks seems like a good idea; making one or more complete tool moves by building list of step primitives in an SX buffer for realtime execution.
This then implies that the SX will NOT be doing the G Code interpretation.
Cheers,
Peter (pjv)
COMPLETELY computer controlled.· I pressed a key to start and away she went.· When it got to the end at right center, the program gave me a pause to raise the cutter, then it returned to origin.· The X table was .001 short of 0, the Y table .001 over.··Had the Z axis drive been finished I could have drilled holes at any point.· Oh, well.............
We're getting there
Sid
Daniel