PLJack said...
Your not honestly suggesting that we send commands to a machine spinning sharp things without a checksum are you?
He probably wasn't.·
Those machines spinning sharp things are sometimes larger than·small houses.· In the good ol' days, the CNC data transmissions (typically from paper tape) used 7 data bits and one parity bit per byte.· Also as only certain bit patterns were expected, erroneous patters were detected (it is curious how just a little oil on the paper made it transparent enough to look like additional punched holes).· And finally, a CRC or CHECKSUM was computed on the entire transmission.· Even modern machines tend to be as conservative as the older ones, often following the defacto standard.
Having a per-transmission checksum is prudent.
Likewise, having an ESTOP circuit of sufficient robustness (industrial grade components) is also prudent.
For my mockup, I've worked out a start/stop circuit that encompases most of the features of the modern implementations of ESTOP safety circuits.· Or at least, my circuit would have passed the muster a decade or so ago.· I believe it is reasonably SAFE for ME, you will need to make your own decision.· The circuit should be within reach of any who can strip wire, twist a screwdriver, and check off wire placements against an schematic.
I'll be releasing this circuit in a few days, along with a few other items as I prepare a mechanical mockup for evaluating various machine control schemes/softwares.·
This leads me to this implied·question.
Bean (Hitt Consulting) said...
I just wanted to get the program working first.
Are you confident that the algorithm is working?· If not, what exactly do you need to establish that confidence?· I'll soon have a 3-axis mechanical mockup that I'll be able to swap an SX52 proto board into to·run code on, if desired.
From the images, it seems that the diagonals are more jagged than the straight lines.· Is this your impression, too?· If so, then continue on...
On examining the criss-cross code, you seem to be programming a 0.1" [noparse][[/noparse]51 step] movement in the X, then a 0.1 [noparse][[/noparse]21 step] movment in the Y until you have etched the diagonal.· This stair-step motion might be the cause of the rough edge on the diagonal.·
If your MF70 comes off break, and you are daring enough to run someone else's code on your controller, I have inserted some new code into your criss-cross program that should reduce the stair-step excursions from 0.1" to a single stepper step (effective axis travel of approximately 0.0002").· This finer stair-step motion should be invisible to the naked eye.
I'm also sneaking in 2-axis linear interpolated motion (otherwise discussed as G-Code G01).·
If you are willing, I'd like to see this execute on a real machine.
Notes:
I added my code as conditional compilation.· Select the personality near the top, with the #DEFINE MOVEMENT_TYPE··= INTERPOLATED_MOVE.
Other than the new variables, the new code starts after your program statement DEBUG "Starting first diagonal".
The new code exhausts the BS2's available program·RAM.· I suppose some/all of these new variables could be stuffed into Scratchpad, as you are using a BS2e.
You should review the assumptions I made about your stepper motors being a 1.8 degreee per step type.· The math and adjustments are isolated to the first several lines of the new code.
You will probably want to lenghten the PAUSE 100 near the end of the new code.· This will allow you reaction time in the event of some unexpected problem.
This code is untested by me on any real hardware.· In fact I have only "compiled" the code without error (under the Basic Stamp IDE v2.2).· It is code adapted, however, from my Basic Stamp G-Code Interpreter exploration (http://mcglothin.us/RobotScrapbook/CommunityPcbMill2005/BasicStampGCodeInterpreter/), and I had watched that run by observing the X & Y displacements in the DEBUG window.
When adapting the code, I added additional commentary that I hope will be helpful to understanding the inner workings.
The additional code only does the first diagonal stroke.· It would be interesting to get your impression of the difference between the two diagonal's edge smoothness.
Daniel, i found it a bit hard to follow your code - I am noit an expert programmer.· Do I just load it and run it?· If that is what I should do, then I'll post a photo of the two resultant diagonals.· Will be interesting to see what I get.
But take a look at the PAUSE 100 near the end of the changes; consider changing that to PAUSE 1000.
The longer PAUSE is between each step emitted to the stepper controllers.· This will give you additional reaction time in the event you want to turn the machine off.
Do a dry run (do not lower the Z axis, maybe even replace the tool bit with a toothpick) first.
Once the code is demonstrated to run without problem, restore the PAUSE 100, and·then do·an actual etching.
Daniel
EDIT: My caution is based on real machine experience.· I've heard of, seen, and even caused, some spectacular accidents.
These have the effect of creating (and assigning values to)·three variables.· These variables are only used by the compiler, they are not real variables in the Stamp.· The first two are used as constants, the third is assigned one of the two constants, and is used to determine whether to include certain sections of the source code.
These variables are used at two locations. First, it is used to·allocate Stamp variable space for the code I inserted· if, and only if, MOVEMENT_TYPE does not contain the value ORIGINAL_MOVE.· The Stamp variable allocation stuff is bracked by these lines:
#IF MOVEMENT_TYPE <> ORIGINAL_MOVE #THEN
#ENDIF
You can see this effect by changing the value assigned to MOVEMENT_TYPE.· When it is assigned the value ORIGINAL_MOVE, and you look at the Memory Map, you will see that your program has most of its variable space available.· When it is assigned the value INTERPOLATED_MOVE, the Memory Map shows that all variable space is allocated.· The different Stamp variable allocations are controlled by this simple software switch.
The next use of the conditional compilation variables is where the actual source code in included.· The three lines:
Your orignal code is retained, and my code discarded, when MOVEMENT_TYPE contains the value ORIGINAL_MOVE.· If MOVEMENT_TYPE does not contain the value ORIGINAL_MOVE, then my code is retained and your original code discarded.· The effect of retained or discarded is with respect to what actually gets downloaded to the Stamp; in all cases, both of the code segments are kept in the source code file.
This is a heads-up in case anyone is taking a close look at the modification I made to Sid's MF70 mill code.
Sid & I are in an offline discussion to see where I misunderstood his mechanical setup. I'll post a corrected Stamp 2-axis interpolator if we get one worked out.
I have been reading some of the previous messages in this thread. Seems I have been a little short with some of you. (PJMonty).
If I made this thread less fun for some of you, then I apologize.
Just that its frustrating writing code for a moving target.
Moving on.
I'm almost does with the third rewrite of the G-code parser. This one removes reliance on VCL constructs such as AnsiString and such. Strings are now handled using STL strings. This will make it allot more cross compiler friendly.
Removed the need for a VCL StringList by pre-parsing, then parsing each line as it is read in from the file.
All in all this incarnation of the parser is quite nice and easy to follow.
As long as the code gets faster and better I don't mind re-writes.
This version now correctly parses every line in the OEMBS1 files. Now I am exporting circuits to G-Code and testing them against the parser. And, of course, there are problems reading most of them because of the fluidness of the G-code protocol. So that is keeping me busy.
Anyone have a link to a PDF of the G-code protocol?
Also spend allot of time with the graphic plotter. I am still unable to work on the COM/SX side of the code because that part of the project has not been defined.
The graphic plotter is a bit of a heavy hitter because it is a full 32 bits per pixel system. The plus side of this is lighting fast speed and support for layers and other graphic tricks. As I work with it I am torn between it and a much smaller 4 or 8 bit system. I'm going to spend a week running experiments, then decide what I will use and stick with that.
Questions for the team:
Do we know specifics about the stepper motors yet. Not just parameters but the actual model and price?
In other words, is there a stepper motor that we can buy and test with, then use it for the actual machine?
Can we get an update on the mechanical side of things. Where are we detail/time wise.
Giving that the g-code parser and SX plotter are a pair, does anyone care if Bean and myself develop the protocol?
Exactly how many licks does it take to get to the center of a .......... (over 30 test)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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 said...
Anyone have a link to a PDF of the G-code protocol?
In http://mcglothin.us/RobotScrapbook/CommunityPcbMill2005/IntroductionToGCodes/, I list Gerber Rs-274X Format Users Guide; about half way thru the links section--RS247X is just RS274D extended, RS274D being the formal G-Code specification.· Then·a little lower in the links section, there is the references to the EMC Handbook and the RS274/NGC Interpreter; it is my impression that this is a pretty good coverage of the RS274 G-Codes (but watch out for some extensions).
Otherwise, as RS274 is a standard, you would need to buy a copy from the standards body.· Having seen a version of the actual standard, and it's pricetag, it is my opionion that you are better off with some of the above references.
PLJack said...
Do we know specifics about the stepper motors yet. Not just parameters but the actual model and price?
In other words, is there a stepper motor that we can buy and test with, then use it for the actual machine?
...
Giving that the g-code parser and SX plotter are a pair, does anyone care if Bean and myself develop the protocol?
We need to hear from pjv, but last I understood he was planning for NEMA 23 and 34 frame motors.· Perhaps it is just my desire, but I half recall a suggestion that the motor mounts·might feature·bolt patterns for both.· These sizes make since sense if one is keeping in mind, as Ken Gracey suggested, the Gecko stepper drives as an option.· In any case, motors of these sizes are likely to be able to push around anything that pjv mightdesign, given the target end-product; if not, there is always NEMA 42 frame motors.
As for actual·motors, the are available several places.· I just bought a trio of H23012 dual-axis ones from http://www.camtronics-cnc.com, follow the Products >> Stepper Motors navigation menu.· I'm in the midst of building up a mechanical frame (simulating a 3-axis machine) that will allow me to exercise the motors, axis limit switches, axis home switches, and control circuits.· This weekend, however, berry picking & making jelly, digging potatoes, and a long family bike ride took precedence.
As to the PC-SX protocol, I thought that was what was going to happen.· However, with my recent (ongoing) work with Sid, it seems to me that there are two aspects of protocol that should be considered.· One is the motion command interface [noparse][[/noparse]currently under discussion]·(of which you know my bias); the other is some communication of the mechanical details:· things like phase or step/dir motor interface, leadscrew pitch, stepper motor step-angle, whether the stepper is to be driven in full, half, or·microstepping, whether a brake·needs to be controlled on the axis,·etc.· In either case, there are additional tidbits of useful information that·I would not prefer to see hardcoded in either the PC or the SX; I'll know a little more about·which ones, after Sid and I get his mill cutting smooth diagonals.
(As may be evident in the last paragraph) I'm uncertain as the the exact purpose of the SX component:· is it to be a deterministic pulse generator that tickles a stepper driver/amplifier (like the Gecko G201) or is it a brain embedded in a complete stepper driver/amplifier collection of electronics (and hence is a substitute for·something like the G201).·
Well, it may seem I'm dropping the ball somewhat, but truthfully, progress IS being made, albeit slower than anticipated and slower than desired. In order to get the best positioning spec with the off-the shelf components, a lot of time is being spent at the "front end" making sure we get things just as right as we can, so it can be replicated reliably.
At this point I'm still designing/improving the recirculating slide bearings. I expect my first 4 prototypes of that this week. Once I have those machined, I can try the actual motion of the slide bearing and measure any runout and inconsistency of the extrusions.
The general design concept is quite straight forward, but the details are unending, and until I have a table sliding back and forth, I will not be able to determine whether the major axis needs a double drive mechanism for anti-twisting, or if one will suffice. If two are preferred, then probably the design should still permit the single approach so individuals can choose their own preference, although the "kit" will sport the required number.
When we have confirmed that the motion is smooth and satisfactory, some pictures and preliminary CAD (3D hopefully) renderings will be posted.
So please have patience, I believe the wait to be worth getting it right.
Regarding motors etc., for detail please refer to the numerous previous posts covering these items; a short recap here
Motors for 23 and 34 frames are anticipated.
Full steps of 200 per revolution.
Lead screw pitch 0.2 inches per turn, yielding .001 per full step.
Maximum speed 10,000 steps per second; 10 inches per second.
Two design styles depending on size: fixed table with X moving gantry, and fixed gantry with Y moving table.
Homing mechanism accommodated.
Braking is via a small "hold" current when the axis has stopped.
Here is yesterday's effort - wanted to see if I could make finer traces.· Couple of small glitches due to program error but I'm happy.· Next project - layout an 8-pin DIP and see if I can run isolation paths between the pins.· For reference, the holes in the photo are .035.
As I promised - or threatened - here is my sample pattern for a DIP 8.· Please note that the pads are a lot more uniform than in yesterdays presentation - did a little more fine-tuning.· I'll never be able to run traces between the pads but at least I can run isolation paths. Now I think I can make a passable PC board.
That's all until I get my Z drive going.· Thanks to Russell Ferguson in Lewisville, TX, the stepper and mechanicals are on the way.
Yesterday I posted a picture of my DIP circuit and said I would never be able to run traces between the pads.· That did not mean I wasn't going to try.
So, I tried.
Excelsior!!
The .035 holes gobbled up most of the DIP traces, but there is enough trace left to solder to, and that makes it functional.· And that is what I am after.
Yesterday I posted a picture of my DIP circuit and said I would never be able to run traces between the pads. That did not mean I wasn't going to try.
Bravo!
Newzed said...
The .035 holes gobbled up most of the DIP traces, but there is enough trace left to solder to, and that makes it functional. And that is what I am after.
I see what you mean now. Your right, they are quite functional.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
Well, earlier I said that the design is quite straight forward, but the details are killing me. The first of 4 prototype slide bearings were tested today with disappointing results.....sticky circulation. We believe we have some insight as to the reason, and we'll check that out in the next few days. Then its on to testing the uniformity of the extrusions.
So, regrettably more delays, but we expect to overcome these challenges.
So, regrettably more delays, but we expect to overcome these challenges.
Peter (pjv)
I'm sure you will.
On the software front I have made great progress with the graphics.
The simulator is now so fast I am having a hard time making a SWF movie for you guys.
The parser is coming along as well. Its reading much more complicated Gerber files now.
Question.
Anyone know of a good reference (math) for panning and zooming XY vectors?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
This thread has been awfully quiet the past two weeks.· Has everyone given up, or maybe gone fishing?
Still pressing on with my MF70.· Have the Z axis motorized - now all three axes are computer controlled.· This will never be a CNC machine - I'm not that smart - but we are a little closer.· Wrote a subroutine in bank 3 that will let me drill holes for a DIP socket.· I enter the number of pins on one side, the spacing left-to-right between the pins, i.e., 300, 400 or 600, press any key and away she goes.
Hope this thread comes to life.· Very interested in what's going on.
Things have indeed been a little quiet. On my front, the mechanical development, we have been working on getting the kinks out of the recirculating ball slide bearings, and so far that has been a little elusive. Although I fully expect to solve that.
Next week I'm off on a cruise to Alaska, so that will burn another week. I'm truly sorry for all the time it's taking, but no, I'm definitely not giving up....I have too many of my own needs for this product.
When its done, I'm sure everyone will be pleased with the results; it's just going to be a while........
Same here, Working on a small software project for CPW.
I've spent so much time on this project that I am catching up on some others.
I was also concerned about "project burnout" so I set this one down for a little while.
I'll try to post an update on this project Monday.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
Have you considered using IGUS DryLin or DryLin-T linear bearings? Lower cost and not so sensitive to dirt (i.e. fiberglass dust). Even the "T" series is cost effective from what I remember in getting a quote at a trade show. Also with the round bearings the rod does not need (and as I recall should not) have a super smooth finish, also reducing cost. As they are available with mounting blocks your machining costs to mount them to the extrusion system could also be reduced. I do not have actual experience with them and so cannot comment on their precision, but from what I have seen they could be more than adequate for the average user, perhaps not the user desiring half of a tenth.
Thought some of you might like to see my latest MF70 effort.· The is the PC board for my DS1302 piggyback, and uses an SMD chip.· You can see the two middle fingers of each side in the middle of the board.
The two rows of 12 holes were drilled in one pass, using my DIP drilling routine.· The remaining holes were manually positioned and drilled.
As for the etching, as I drew the etching lines in Express, I copied the direction and travel into a spread sheet.· When I was finished I used the spreadsheet to generate a program that would do all the etching from start to finish, using GOSUBs to call each etching action.· There were three "Press any key" pauses in the program in case I needed to let the spoindle motor cool down, but that proved unnecessary.· I positioned the cutter with my regular program, then loaded the DS1302 program, pressed a key and away she went!· I am very happy with the results - this is the best board I've made yet.· I had an error in my backlash compensation for the Y drive which I corrected.· The cutter traversed between the etch lines at the top and bottom of the board several times but not there is no almost no overcutting or widening of the etch lines.· And please note the uniform spacing between the etch path and the DIP holes.
It's great to have your regular demonstration that a circuit miller is actually possible!
Out of curiosity, how fast does your milling tool travel as you mill these traces? Can you state an exact figure, like 5 seconds per inch, or whatever, or could you estimate its speed?
David, the Y drive moves about 6 or 7 seconds per inch.· The X table is much slower - it takes about 25 or 30 seconds to travel one inch.· The reason the X table is so slow is that it is being driven by a Gecko Microstep controller, wheras the Y table uses a half-step IB463.· The Y table requires 20300 steps per inch, the X table 51560 steps per inch.· One of these days when I can afford it I'm going to replace the Gecko with an IB463 running half-step.· Time is not that important right now - I'm doing what I set out to do - make usable PC boards.
Comments
Those machines spinning sharp things are sometimes larger than·small houses.· In the good ol' days, the CNC data transmissions (typically from paper tape) used 7 data bits and one parity bit per byte.· Also as only certain bit patterns were expected, erroneous patters were detected (it is curious how just a little oil on the paper made it transparent enough to look like additional punched holes).· And finally, a CRC or CHECKSUM was computed on the entire transmission.· Even modern machines tend to be as conservative as the older ones, often following the defacto standard.
Having a per-transmission checksum is prudent.
Likewise, having an ESTOP circuit of sufficient robustness (industrial grade components) is also prudent.
For my mockup, I've worked out a start/stop circuit that encompases most of the features of the modern implementations of ESTOP safety circuits.· Or at least, my circuit would have passed the muster a decade or so ago.· I believe it is reasonably SAFE for ME, you will need to make your own decision.· The circuit should be within reach of any who can strip wire, twist a screwdriver, and check off wire placements against an schematic.
I'll be releasing this circuit in a few days, along with a few other items as I prepare a mechanical mockup for evaluating various machine control schemes/softwares.·
This leads me to this implied·question.
Are you confident that the algorithm is working?· If not, what exactly do you need to establish that confidence?· I'll soon have a 3-axis mechanical mockup that I'll be able to swap an SX52 proto board into to·run code on, if desired.
Daniel
Sid,
From the images, it seems that the diagonals are more jagged than the straight lines.· Is this your impression, too?· If so, then continue on...
On examining the criss-cross code, you seem to be programming a 0.1" [noparse][[/noparse]51 step] movement in the X, then a 0.1 [noparse][[/noparse]21 step] movment in the Y until you have etched the diagonal.· This stair-step motion might be the cause of the rough edge on the diagonal.·
If your MF70 comes off break, and you are daring enough to run someone else's code on your controller, I have inserted some new code into your criss-cross program that should reduce the stair-step excursions from 0.1" to a single stepper step (effective axis travel of approximately 0.0002").· This finer stair-step motion should be invisible to the naked eye.
I'm also sneaking in 2-axis linear interpolated motion (otherwise discussed as G-Code G01).·
If you are willing, I'd like to see this execute on a real machine.
Notes:
If you are not willing, I understand that too.
Daniel
Post Edited (daniel) : 8/3/2005 4:56:36 AM GMT
Sid
I think it would be safe to do so.
But take a look at the PAUSE 100 near the end of the changes; consider changing that to PAUSE 1000.
The longer PAUSE is between each step emitted to the stepper controllers.· This will give you additional reaction time in the event you want to turn the machine off.
Do a dry run (do not lower the Z axis, maybe even replace the tool bit with a toothpick) first.
Once the code is demonstrated to run without problem, restore the PAUSE 100, and·then do·an actual etching.
Daniel
EDIT: My caution is based on real machine experience.· I've heard of, seen, and even caused, some spectacular accidents.
Standby for ignition !!!
Sid
' This code removed....
'++++++++++++++++++++++++++++++++++++++++++++++
f = 1
FOR y = 1 TO 1000
FOR x = 1 TO f*/$3390
PULSOUT stp, 10
NEXT
PAUSE 100
FOR x = 1 TO f*/$144D
PULSOUT stpy, 10
NEXT
PAUSE 100
NEXT
#ELSE
Do you mean 'removed' or 'bypassed'?
Sid
Yes, bypassed is correct.·
However, removed is also correct for the following reason.
I used conditional compilation code.· But you might ask, "What is conditional compilation?"
There are three statements near the top of the program
These have the effect of creating (and assigning values to)·three variables.· These variables are only used by the compiler, they are not real variables in the Stamp.· The first two are used as constants, the third is assigned one of the two constants, and is used to determine whether to include certain sections of the source code.
These variables are used at two locations. First, it is used to·allocate Stamp variable space for the code I inserted· if, and only if, MOVEMENT_TYPE does not contain the value ORIGINAL_MOVE.· The Stamp variable allocation stuff is bracked by these lines:
You can see this effect by changing the value assigned to MOVEMENT_TYPE.· When it is assigned the value ORIGINAL_MOVE, and you look at the Memory Map, you will see that your program has most of its variable space available.· When it is assigned the value INTERPOLATED_MOVE, the Memory Map shows that all variable space is allocated.· The different Stamp variable allocations are controlled by this simple software switch.
The next use of the conditional compilation variables is where the actual source code in included.· The three lines:
Your orignal code is retained, and my code discarded, when MOVEMENT_TYPE contains the value ORIGINAL_MOVE.· If MOVEMENT_TYPE does not contain the value ORIGINAL_MOVE, then my code is retained and your original code discarded.· The effect of retained or discarded is with respect to what actually gets downloaded to the Stamp; in all cases, both of the code segments are kept in the source code file.
Daniel
This is a heads-up in case anyone is taking a close look at the modification I made to Sid's MF70 mill code.
Sid & I are in an offline discussion to see where I misunderstood his mechanical setup. I'll post a corrected Stamp 2-axis interpolator if we get one worked out.
Daniel
I have been reading some of the previous messages in this thread. Seems I have been a little short with some of you. (PJMonty).
If I made this thread less fun for some of you, then I apologize.
Just that its frustrating writing code for a moving target.
Moving on.
I'm almost does with the third rewrite of the G-code parser. This one removes reliance on VCL constructs such as AnsiString and such. Strings are now handled using STL strings. This will make it allot more cross compiler friendly.
Removed the need for a VCL StringList by pre-parsing, then parsing each line as it is read in from the file.
All in all this incarnation of the parser is quite nice and easy to follow.
As long as the code gets faster and better I don't mind re-writes.
This version now correctly parses every line in the OEMBS1 files. Now I am exporting circuits to G-Code and testing them against the parser. And, of course, there are problems reading most of them because of the fluidness of the G-code protocol. So that is keeping me busy.
Anyone have a link to a PDF of the G-code protocol?
Also spend allot of time with the graphic plotter. I am still unable to work on the COM/SX side of the code because that part of the project has not been defined.
The graphic plotter is a bit of a heavy hitter because it is a full 32 bits per pixel system. The plus side of this is lighting fast speed and support for layers and other graphic tricks. As I work with it I am torn between it and a much smaller 4 or 8 bit system. I'm going to spend a week running experiments, then decide what I will use and stick with that.
Questions for the team:
Do we know specifics about the stepper motors yet. Not just parameters but the actual model and price?
In other words, is there a stepper motor that we can buy and test with, then use it for the actual machine?
Can we get an update on the mechanical side of things. Where are we detail/time wise.
Giving that the g-code parser and SX plotter are a pair, does anyone care if Bean and myself develop the protocol?
Exactly how many licks does it take to get to the center of a .......... (over 30 test)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
In http://mcglothin.us/RobotScrapbook/CommunityPcbMill2005/, I also list references to manuals for two of the popular hobbiest CAM/CNC packages.··Look for the Machn manuals and the TurboCNC manual links.
Otherwise, as RS274 is a standard, you would need to buy a copy from the standards body.· Having seen a version of the actual standard, and it's pricetag, it is my opionion that you are better off with some of the above references.
We need to hear from pjv, but last I understood he was planning for NEMA 23 and 34 frame motors.· Perhaps it is just my desire, but I half recall a suggestion that the motor mounts·might feature·bolt patterns for both.· These sizes make since sense if one is keeping in mind, as Ken Gracey suggested, the Gecko stepper drives as an option.· In any case, motors of these sizes are likely to be able to push around anything that pjv mightdesign, given the target end-product; if not, there is always NEMA 42 frame motors.
As for actual·motors, the are available several places.· I just bought a trio of H23012 dual-axis ones from http://www.camtronics-cnc.com, follow the Products >> Stepper Motors navigation menu.· I'm in the midst of building up a mechanical frame (simulating a 3-axis machine) that will allow me to exercise the motors, axis limit switches, axis home switches, and control circuits.· This weekend, however, berry picking & making jelly, digging potatoes, and a long family bike ride took precedence.
As to the PC-SX protocol, I thought that was what was going to happen.· However, with my recent (ongoing) work with Sid, it seems to me that there are two aspects of protocol that should be considered.· One is the motion command interface [noparse][[/noparse]currently under discussion]·(of which you know my bias); the other is some communication of the mechanical details:· things like phase or step/dir motor interface, leadscrew pitch, stepper motor step-angle, whether the stepper is to be driven in full, half, or·microstepping, whether a brake·needs to be controlled on the axis,·etc.· In either case, there are additional tidbits of useful information that·I would not prefer to see hardcoded in either the PC or the SX; I'll know a little more about·which ones, after Sid and I get his mill cutting smooth diagonals.
(As may be evident in the last paragraph) I'm uncertain as the the exact purpose of the SX component:· is it to be a deterministic pulse generator that tickles a stepper driver/amplifier (like the Gecko G201) or is it a brain embedded in a complete stepper driver/amplifier collection of electronics (and hence is a substitute for·something like the G201).·
Just some noises from,
Daniel
Post Edited (daniel) : 8/7/2005 10:00:21 PM GMT
Well, it may seem I'm dropping the ball somewhat, but truthfully, progress IS being made, albeit slower than anticipated and slower than desired. In order to get the best positioning spec with the off-the shelf components, a lot of time is being spent at the "front end" making sure we get things just as right as we can, so it can be replicated reliably.
At this point I'm still designing/improving the recirculating slide bearings. I expect my first 4 prototypes of that this week. Once I have those machined, I can try the actual motion of the slide bearing and measure any runout and inconsistency of the extrusions.
The general design concept is quite straight forward, but the details are unending, and until I have a table sliding back and forth, I will not be able to determine whether the major axis needs a double drive mechanism for anti-twisting, or if one will suffice. If two are preferred, then probably the design should still permit the single approach so individuals can choose their own preference, although the "kit" will sport the required number.
When we have confirmed that the motion is smooth and satisfactory, some pictures and preliminary CAD (3D hopefully) renderings will be posted.
So please have patience, I believe the wait to be worth getting it right.
Regarding motors etc., for detail please refer to the numerous previous posts covering these items; a short recap here
Motors for 23 and 34 frames are anticipated.
Full steps of 200 per revolution.
Lead screw pitch 0.2 inches per turn, yielding .001 per full step.
Maximum speed 10,000 steps per second; 10 inches per second.
Two design styles depending on size: fixed table with X moving gantry, and fixed gantry with Y moving table.
Homing mechanism accommodated.
Braking is via a small "hold" current when the axis has stopped.
Thanks for remaining interested;
Peter (pjv)
Post Edited (pjv) : 8/7/2005 10:01:55 PM GMT
Not a problem. The software and motor control are not ready as well.
Just looking for updates.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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 read that one about every day. It has been very helpful, thanks.
I'm looking for the Rs-274 specs.
I'm sure I can find it later today.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
Post Edited (PLJack) : 8/8/2005 10:19:06 AM GMT
Here is yesterday's effort - wanted to see if I could make finer traces.· Couple of small glitches due to program error but I'm happy.· Next project - layout an 8-pin DIP and see if I can run isolation paths between the pins.· For reference, the holes in the photo are .035.
Sid
Daniel
That's all until I get my Z drive going.· Thanks to Russell Ferguson in Lewisville, TX, the stepper and mechanicals are on the way.
Vive la MF70
Sid
Sid, you rule.
Nice work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
Not a PDF but a good read:
www.artwork.com/gerber/index.htm
See application note links at bottom of page.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
So, I tried.
Excelsior!!
The .035 holes gobbled up most of the DIP traces, but there is enough trace left to solder to, and that makes it functional.· And that is what I am after.
Functionalitis maximus
Long live the MF70 !!!
Sid
Bravo!
I see what you mean now. Your right, they are quite functional.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
Daniel
Post Edited (daniel) : 8/11/2005 11:00:34 AM GMT
Well, earlier I said that the design is quite straight forward, but the details are killing me. The first of 4 prototype slide bearings were tested today with disappointing results.....sticky circulation. We believe we have some insight as to the reason, and we'll check that out in the next few days. Then its on to testing the uniformity of the extrusions.
So, regrettably more delays, but we expect to overcome these challenges.
Please stay tuned.
Peter (pjv)
Post Edited (pjv) : 8/12/2005 3:57:53 AM GMT
I'm sure you will.
On the software front I have made great progress with the graphics.
The simulator is now so fast I am having a hard time making a SWF movie for you guys.
The parser is coming along as well. Its reading much more complicated Gerber files now.
Question.
Anyone know of a good reference (math) for panning and zooming XY vectors?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
Still pressing on with my MF70.· Have the Z axis motorized - now all three axes are computer controlled.· This will never be a CNC machine - I'm not that smart - but we are a little closer.· Wrote a subroutine in bank 3 that will let me drill holes for a DIP socket.· I enter the number of pins on one side, the spacing left-to-right between the pins, i.e., 300, 400 or 600, press any key and away she goes.
Hope this thread comes to life.· Very interested in what's going on.
Sid
Things have indeed been a little quiet. On my front, the mechanical development, we have been working on getting the kinks out of the recirculating ball slide bearings, and so far that has been a little elusive. Although I fully expect to solve that.
Next week I'm off on a cruise to Alaska, so that will burn another week. I'm truly sorry for all the time it's taking, but no, I'm definitely not giving up....I have too many of my own needs for this product.
When its done, I'm sure everyone will be pleased with the results; it's just going to be a while........
Cheers,
Peter (pjv)
I've spent so much time on this project that I am catching up on some others.
I was also concerned about "project burnout" so I set this one down for a little while.
I'll try to post an update on this project Monday.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
Have you considered using IGUS DryLin or DryLin-T linear bearings? Lower cost and not so sensitive to dirt (i.e. fiberglass dust). Even the "T" series is cost effective from what I remember in getting a quote at a trade show. Also with the round bearings the rod does not need (and as I recall should not) have a super smooth finish, also reducing cost. As they are available with mounting blocks your machining costs to mount them to the extrusion system could also be reduced. I do not have actual experience with them and so cannot comment on their precision, but from what I have seen they could be more than adequate for the average user, perhaps not the user desiring half of a tenth.
Rick
The two rows of 12 holes were drilled in one pass, using my DIP drilling routine.· The remaining holes were manually positioned and drilled.
As for the etching, as I drew the etching lines in Express, I copied the direction and travel into a spread sheet.· When I was finished I used the spreadsheet to generate a program that would do all the etching from start to finish, using GOSUBs to call each etching action.· There were three "Press any key" pauses in the program in case I needed to let the spoindle motor cool down, but that proved unnecessary.· I positioned the cutter with my regular program, then loaded the DS1302 program, pressed a key and away she went!· I am very happy with the results - this is the best board I've made yet.· I had an error in my backlash compensation for the Y drive which I corrected.· The cutter traversed between the etch lines at the top and bottom of the board several times but not there is no almost no overcutting or widening of the etch lines.· And please note the uniform spacing between the etch path and the DIP holes.
Onward and upward with the MF70
Sid
It's great to have your regular demonstration that a circuit miller is actually possible!
Out of curiosity, how fast does your milling tool travel as you mill these traces? Can you state an exact figure, like 5 seconds per inch, or whatever, or could you estimate its speed?
thanks,
David
Sid