A very busy weekend, so only had a chance to look at your code today, and have not tried it on any real stepper hardware.
I realize I'm SX/B challenged, so I don't pretend to fully be able to understand what the code is doing, but I get the the gist of it.
To be sure I'm on the right track though, please confirm my understanding that the X and Y motions appear to NOT be happening simultaneaously? This would be a problem for any angled or more complex move.
Unless I'm mis understanding things, the X, Y (and preferably also the Z) axes must operate simultaneously, including simultaneous and linked accelerations, and I can't read your code to be doing that.
Also, the next motion directives must be loaded and buffered while the current motion is being executed so as not to have a stall in the tool motion while it transistions from one path to another.
No, the rotary sense switch is only tripped for one revolution near the end of the screw travel. Without going into detail, this was my intent with the words "appropriately activated switch".
PJMonty said...
With regard to what language the SX will parse:
I've read both PJV's post and yours.
My initial idea behind CM-Code is that we are not locked in to G-Codes.
What if someone wanted to use the mill for something other than a mill.
By having the PC tell the SX what to do the sky is limit.
I do take your point though.
As for re-inventing the wheel, I would have to disagree. Not so much with you but with that phrase.
I don't see the point of getting out of bed just to ride an old wheel.
Your way has merit and would make my job allot easier.
To be honest I just want it to work and I will do whatever I need to in order for that to happen.
During this exercise of writing the software I have already decided that I will most likely write software for both sides (PC/SX) when the CM is up and running and the project is stable..
All I know is we need to stop jerking the programmers around.
Is Bean parsing G-Codes or not. In any case we still need intercommunication between the PC and SX.
What does that look like? What should he be writing?
I place all the blame for this state on this 300+ message thread.
There should be an area of agreed upon tasks.
Each task should have its own thread.
As for me, I'm writing a G-Code parser in any case.
I have not done any work on the COM side of the software because I dont know what to send.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
Newzed said...
This is probably the final presentation in the MF70 trilogy.
Sid.
I will second the "great job".
You say it's a start but you are way ahead of this project.
Thanks for the encouragement.
BTW,
On the bottom left of the board there seems to be an anomaly. Kind of like horizontal lines.
Its that just the picture or is there a story behind that.?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
Newzed said...
This is probably the final presentation in the MF70 trilogy.
Sid.
I will second the "great job".
You say it's a start but you are way ahead of this project.
Thanks for the encouragement.
BTW,
On the bottom left of the board there seems to be an anomaly. Kind of like horizontal lines.
Its that just the picture or is there a story behind that.?
I was hoping no one would notice that.· I had a small error in my program and hit the Panic Stop when I saw it.· Since I didn't want to waste the copper, I just reset everything and started over.
·
You chaps are really providing my encouragement.· I would never have started this project if it hadn't been for this thread.· Can't wait to get my Z axis working.
In order to get some order to the table motion tasks to be done, let me put forward my perspective on that....all open of course to improvement with better or simpler ideas.
MY PERSONAL belief is that to be truly useful, the motion of the table (or toolpath) must be continuous; that is smoothly through all co-ordinate sets in the list to be "traced". To keep the work more manageable, for a first cut I'm happy with two axis X,Y interpolation, and only straight lines at that. Provided of course that arcs and circles to be added at a later date be not excluded.
So if the toolpath may be X only, or Y only or angled at some combination of X and Y, the velocity vector of this angled path should be a constant, set by some (G Code?) parameter. This velocity selection should remain set until changed by another velocity selection.
In order for the steppers to give maximum high speed performance, each will need to be accelerated to the required speed to make the angled vector velocity become the desired value. For non-trivial lines (that is for non-vertical and non-horizontal lines) the acceleration must be a constant for the resulting vector, implying different accelerations for the two axes when angled lines are not 45 degrees. In order to prevent "wiggly" paths, (remember the target is for 0.002/.003 position accuracy at all times) the two accelerations must be linked to each other.
The SX controller also needs to set three or four motor drive voltages for each axis, high for accelerate/decelerate ramping; mid for constant velocity; low for hold; and perhaps off. Mabe even axis current monitoring.
Also for each axis the SX needs to sense two travel end limit switches and one home switch.
An emergency stop is also a necessity.
Other actions such as spindle direction and speed control, may be need to be added as desired.
And naturally communications from a PC to be fed sets of coordinates and other parameters as required to cause the desired sequence of motions and actions.
Now, for a properly (professional) system all these funcions need to occur continuously, and all "at the same time". This might be too big a task for SX/B as "pauses" cannot be tolerated.
This begs the question, should a "first level" of the SX software NOT be bound by my perception of "continuous motion" requirement, in which case a lot of the real-time requirements are relaxed, of course together with the performance not being .002/.003 positioning, eventhough the table mechanical is intended to achieve that spec. At a later date more competent software can up the performance of the whole system, and only those who have the need can upgrade as they wish.
So, perhaps my previous posts and expectations about software performance were a bit out of line for the average hobbyist's requirements; I was looking to produce a machine approaching professional specifications;.........that is what my own needs are.
Please pass on your thoughts to help set the direction for the programmers.
PLJack said...
All I know is we need to stop jerking the programmers around.
Is Bean parsing G-Codes or not. In any case we still need intercommunication between the PC and SX.
What does that look like? What should he be writing?
I place all the blame for this state on this 300+ message thread.
There should be an area of agreed upon tasks.
Each task should have its own thread.
Jack, · I couldn't have said it better. I'm waiting to see what shakes-out because I'm tired of the "back-and-forth". · I don't mind writing the code, but my time is precious and I won't waste it like this.
· Sid, what kind of protocol are you using ?
· I agree completely with the forum too, this is ridiculous. We'll never get agreement on anything like this...
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
Peter (pjv),
As I see it when moving with the tool up (not cutting) we are bound by the speed of the stepper motor and the friction and interia of the table. But when cutting we are bound by the speed that the bit can cut (which I assume will be much slower than the "not cutting" speed). My point is...Do we need accel/decel for cutting speed ? If we do the bit will not be cutting at a constant rate. Or am I just making this more complecated that is really is ?
The last version of the SX software I wrote just moved the major axis at the feedrate and the minor axis moved "as needed".
But I see what you mean.. As the feedrate is NOT a limit of the stepper, but is a rate for bit travel speed. So this would need to be adjusted for different angles. So one motor will have travel at feedrate*sin(angle) and the other will have to travel at feedrate*cos(angle).
Am I correct or am I all wet ?
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
Bean, I'm using the only thing I could come up with.· The MF70 is controlled by a BS2E.· The program tells it to go left, right, in or out and how far.· Here is a snippet of code which tell the BS2E to send the X table 1.000 to the left:
f = 1000
HIGH dir················· 'going left 1.000HIGH led
y = 1····················· 1 is left, 2 is right
FOR x = 1 TO f*/$3390
PULSOUT stp, 10
NEXT
posx = posx + f
PAUSE dly
I had to work out the */ operator.· It gives the the precise number of steps required to move the table .100, which is about 2.45 revolutions of the X axis leadscrew.· I have two different controllers on the X and Y axes, so I had to come up with different */ operators.
Sid, are you programming the BS2E directly to create the board ? Or does a PC give the controllers instructions ? If you use the PC what software do you use ?
I can't believe how far you have come in a short amount of time. Congratulations...
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
Bean, I program the BS2E with all the instructions necessary to create the board.· I use an LCD to simulate the debug screen and a 3x4 keypad with a 16F628 to input data to the Stamp.· The PC is in the computer room here, the·MF70 is out in the shop.· I use a Stache to upload programs revisions to the BS2E.· On the keypad, the 628 detects when a button goes low.· It then serouts the appropriate decimal - or decimals - to the Stamp.
You are correct. The feed rate is the speed the TOOL (path) travels at. And the tricky part is the need for linked accelerations
Also, as the table was meant to be a general purpose relatively precision machine, in my opinion traversing and inperpolation feed rates should not be assumed to be slow. For example, among other things, I expect to be winding coils with the unit by having the table trace out a circular pattern around a bobbin, feeing the wire out, and then automatically "terminating" the wire by circularly wrapping wire around wirewrap pins.
I also will mount a vacuum desoldering iron to the Z axis, and use it to desolder chips in pre-programmed patterns.
Furthermore painting with a small spray gun
Depositing glue for surface mount components is another...... it just goes on.
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.
Not necessarily true. Re-read my post and you'll see that I covered this very issue. I suggested that you translate (or "compile") all high level G-Code instructions into an agreed upon subset of G-code instructions. If you want to convert arcs to a series of straight lines, it won't affect the ability of the SX to keep up regardless of whether the PC outputs G-Code or CM-Code.
As for the SX "keeping up", I wouldn't be too worried about a 50 MIPS machine being able to output high speed pulses while also parsing G-code or CM-Code. Back in 1999 I wrote an SX28 based two axis pulse generator for controlling stepper motors with the ability to specify any speed from 30 hz to 250 khz. The PC could specify the speed using integer values from 0 (fully off) to 16384 (250 khz). If all you want is to have a top output rate of 10 khz, that same code would do 8 channels without any problems.
PLJack said...
My initial idea behind CM-Code is that we are not locked in to G-Codes.
What if someone wanted to use the mill for something other than a mill.
By having the PC tell the SX what to do the sky is limit.
The sky is the limit whether it's CM-Code or G-Code. Suppose someone does want to use the mill for something other than a mill - are you suggesting that using CM-Code is going to free them to do whatever they want whereas G-Code will prevent them from doing it? Given the shapes that are created on CNC machines these days, it seems that there probably isn't any motion that can't be expressed in G-Code. If you want to use the SX chip to move robots, that motion could be expressed in G-Code just as well as it could in CM-Code.
Here's G-Code for moving X to 10 and Y to 10 at the current specified feedrate:
G0 X10 Y10
Here's the CM-Code for doing the same (although this requires constantly setting the feedrate with each command):
!M 10, 0, 10, 0, 0, 0, 3, checksum
They both get you to position 10, 10, and honestly the G-Code looks a lot simpler.
The point I'm making is that G-code can express any move you want, so why come up with a new language/protocol to express the exact same things that G-Code does?
Finally, you mentioned that you didn't want to get out of bed to ride an old wheel. I hate to even bring this up, but creating a new wheel to ride just sounds pretty much like saying you want to create a new wheel because you don't like the old one, which in turn sounds like re-inventing to me. I'm not trying to pick on you, I'm just telling you what it sounds like to me.
Anyway, all of this is up to you guys anyway. It's your project and that's cool. If you want to create a new language protocol for expressing motion vectors, then go for it.
Not a rebuttal here but just some clarification...
I fully believe the SX is capable of doing what is needed.
I, too, well understand the capability of 50 Mips. What I said was that I feared SX/B might not be up to the job; principally because I believe it's not multi-threaded, so timings tend to be handled with pauses; an unworkable situation if relatively high speed multiple functions are required. At slower speeds?..by all means.
So I expect its a matter of trying it, and judging the preformance. Different users will have different needs.·My personal requirement·is for relatively high, commercial,·performance, and hence my whining about speeds.
I too would have a preference for standard G Codes, but Jack and Bean should be free to use those tools and methods they·are most comfortable with, and if that means re-inventing, then so be it. Anyone is free to add their own flavor to the extent of their available time, commitment and talent.
I would like to hear back from others as to the SX tasks the way I outlined them; if more functionality is required, then those programming need a clear definition of those tasks.
Would you be willing to etch an experiment, and post the results (photo of etch plus relevant BS2 code).
If possible, I'd like to see your square spiral rotated 45 degrees (that is, have the straight lines be a compound X Y movement). It doesn't even have to be a spiral, just a diagonal line would suffice.
If the diagnonal lines have 'jagged' edges, and if you have the capability of measuring the steps, it would be interesting to see what the magnitude of the steps are. If you don't have the measuring tools, perhaps you could do a close up photo with a reference distance indicated somewhere (perhaps a straight 0.01"· line on the X axis, and the same on the Y axis, and a single 'dot' where the tool-tip is simply plunged without X or Y motion).
I'm guessing that, on the straight single-axis travel, you are achieving the 0.001" (or 0.0005")·resolution you casually mention in your source code fragment back on your 7/4/2005 7:12 AM message. I'm wondering if you get close to that on the diagonals.
Daniel
Edit: back on 7/4/2005 7:12 AM, Sid stated an ability to nudge the Y-axis by 0.0005".· Do you have similar resolution on the X-Axis now?·
pjv said...
...SX/B might not be up to the job; principally because I believe it's not multi-threaded, so timings tend to be handled with pauses...
Perhaps I wrong, but I seems to me that the SX/B INTERRUPT command gives the programmer access to all of the virtual peripheral (VP)·tricks, including multi-threading the interrupt.··Doesn't this problem resolve to the following overlapped VPs:
serial communication to the PC
parsing the PC's instructions
solving ahead the next (several)·motion command(s)
running stepper motors on a regular pulse rate to accomplish the current motion command
monitoring the limit switches and estop inputs
It seems to me that homing is a dedicated, setup,·machine function, not normally performed in the context of any automatic operation.
If so, can't work proceed along the VP tasks that we have relative agreement on?
It is the fact that the Basic Stamp does not have this VP capability that I see as it's fundemental limitation to this application.
Daniel
Edit:· I do understand that SX/B's SERIN/SEROUT will have to be bit-banged instead.
Daniel,
I plan to have the SX/B code use interrupts to send/recv serial data and to move the servos.
I just wanted to get the program working first.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
Danial, I have just finished a little program that draws a square 1.000
x 1.000, then draws two diagonals inside the square, which I was going to do this morning.· Would that do?
If not, could you send me a sketch of what you would like to see.
Newzed said...
Danial, I have just finished a little program that draws a square 1.000
x 1.000, then draws two diagonals inside the square, which I was going to do this morning.· Would that do?
Sid,
Exactly what I had in mind.· If you would move the drill tip to an isolated area and plunge it (Z-axis only) into the material to the normqal cutting depth.
I'm looking to see how the BS2 handles the "interpolated" motions in X & Y with respect to smooth edges.·
As I profess to be SX/B inept, my understanding of what it can or cannot do is not complete.
And yes, the home function is independent of other move functions, however, as you pointed out Daniel, monitoring the switches, doing the comms and all the other functions still need to happen simultaneously.
And all that hopefully at a speed such that 10,000 steps (10 inches) per second can still be reliably achieved with the target precision.
Daniel, here is my first effort at a diagonal.· As you can see, the angle is about 20 degrees instead of 45.· Either my calculations were wrong or if have a procdural error in my program.· I'll review, correct and try again.
Not a bad angle cut, really - just not on target.· The little dot at upper center is where I plunged the cutter to about the same depth as the square and angle paths.
Daniel, here is my latest effort - very dumb error in my program.· Left out the $ modifier in one of my */ routines.· Everything seems to be working fine now.··Don't think·there anything else I could post - I've about reached the limit of my capabilities until I get the Z axis going.
Daniel, I believe you said you wanted the code the for the criss-cross pattern.· It is attached.
You will note the large differences in the */ operators for the X and Y drives.· The X drive is controlled by a Gecko microstep controller.· The Y drive is controlled by an IB463 controller, set for half-step.· In addition, the Y stepper has a 15-tooth pulley, the Y drive a 30 tooth pulley.· I needed a small power advantage for the Y drive since it was carrying the weight of the X table.· The X table is direct drive.
Just so you'll know, it took me hours and hours to figure out the exact modifiers for the */ operators.· My goal was to enter the travel I wanted, say 100 (Mils) and have the table move exactly that distance.· One rev of any drive moves the table .0393.· 100 mils takes approximately 2.45 revs.
It's all done now and·I'm quite pleased with how things turned out.· Can't wait to get my Z drive going!
Comments
Great job.
Daniel
A very busy weekend, so only had a chance to look at your code today, and have not tried it on any real stepper hardware.
I realize I'm SX/B challenged, so I don't pretend to fully be able to understand what the code is doing, but I get the the gist of it.
To be sure I'm on the right track though, please confirm my understanding that the X and Y motions appear to NOT be happening simultaneaously? This would be a problem for any angled or more complex move.
Unless I'm mis understanding things, the X, Y (and preferably also the Z) axes must operate simultaneously, including simultaneous and linked accelerations, and I can't read your code to be doing that.
Also, the next motion directives must be loaded and buffered while the current motion is being executed so as not to have a stall in the tool motion while it transistions from one path to another.
Help!!
Peter (pjv)
No, the rotary sense switch is only tripped for one revolution near the end of the screw travel. Without going into detail, this was my intent with the words "appropriately activated switch".
Cheers,
Peter (pjv)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"what's cheese to a mouse is a snack to a rat"
I've read both PJV's post and yours.
My initial idea behind CM-Code is that we are not locked in to G-Codes.
What if someone wanted to use the mill for something other than a mill.
By having the PC tell the SX what to do the sky is limit.
I do take your point though.
As for re-inventing the wheel, I would have to disagree. Not so much with you but with that phrase.
I don't see the point of getting out of bed just to ride an old wheel.
Your way has merit and would make my job allot easier.
To be honest I just want it to work and I will do whatever I need to in order for that to happen.
During this exercise of writing the software I have already decided that I will most likely write software for both sides (PC/SX) when the CM is up and running and the project is stable..
All I know is we need to stop jerking the programmers around.
Is Bean parsing G-Codes or not. In any case we still need intercommunication between the PC and SX.
What does that look like? What should he be writing?
I place all the blame for this state on this 300+ message thread.
There should be an area of agreed upon tasks.
Each task should have its own thread.
As for me, I'm writing a G-Code parser in any case.
I have not done any work on the COM side of the software because I dont know what to send.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
Sid.
I will second the "great job".
You say it's a start but you are way ahead of this project.
Thanks for the encouragement.
BTW,
On the bottom left of the board there seems to be an anomaly. Kind of like horizontal lines.
Its that just the picture or is there a story behind that.?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
Thanks Thom.
A demo seems superior to writing it all down
I will release new ones as developments happen.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.
Sid.
I will second the "great job".
You say it's a start but you are way ahead of this project.
Thanks for the encouragement.
BTW,
On the bottom left of the board there seems to be an anomaly. Kind of like horizontal lines.
Its that just the picture or is there a story behind that.?
In order to get some order to the table motion tasks to be done, let me put forward my perspective on that....all open of course to improvement with better or simpler ideas.
MY PERSONAL belief is that to be truly useful, the motion of the table (or toolpath) must be continuous; that is smoothly through all co-ordinate sets in the list to be "traced". To keep the work more manageable, for a first cut I'm happy with two axis X,Y interpolation, and only straight lines at that. Provided of course that arcs and circles to be added at a later date be not excluded.
So if the toolpath may be X only, or Y only or angled at some combination of X and Y, the velocity vector of this angled path should be a constant, set by some (G Code?) parameter. This velocity selection should remain set until changed by another velocity selection.
In order for the steppers to give maximum high speed performance, each will need to be accelerated to the required speed to make the angled vector velocity become the desired value. For non-trivial lines (that is for non-vertical and non-horizontal lines) the acceleration must be a constant for the resulting vector, implying different accelerations for the two axes when angled lines are not 45 degrees. In order to prevent "wiggly" paths, (remember the target is for 0.002/.003 position accuracy at all times) the two accelerations must be linked to each other.
The SX controller also needs to set three or four motor drive voltages for each axis, high for accelerate/decelerate ramping; mid for constant velocity; low for hold; and perhaps off. Mabe even axis current monitoring.
Also for each axis the SX needs to sense two travel end limit switches and one home switch.
An emergency stop is also a necessity.
Other actions such as spindle direction and speed control, may be need to be added as desired.
And naturally communications from a PC to be fed sets of coordinates and other parameters as required to cause the desired sequence of motions and actions.
Now, for a properly (professional) system all these funcions need to occur continuously, and all "at the same time". This might be too big a task for SX/B as "pauses" cannot be tolerated.
This begs the question, should a "first level" of the SX software NOT be bound by my perception of "continuous motion" requirement, in which case a lot of the real-time requirements are relaxed, of course together with the performance not being .002/.003 positioning, eventhough the table mechanical is intended to achieve that spec. At a later date more competent software can up the performance of the whole system, and only those who have the need can upgrade as they wish.
So, perhaps my previous posts and expectations about software performance were a bit out of line for the average hobbyist's requirements; I was looking to produce a machine approaching professional specifications;.........that is what my own needs are.
Please pass on your thoughts to help set the direction for the programmers.
Cheers,
Peter (pjv)
Post Edited (pjv) : 8/1/2005 11:24:50 PM GMT
· I couldn't have said it better. I'm waiting to see what shakes-out because I'm tired of the "back-and-forth".
· I don't mind writing the code, but my time is precious and I won't waste it like this.
· Sid, what kind of protocol are you using ?
· I agree completely with the forum too, this is ridiculous. We'll never get agreement on anything like this...
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)) : 8/1/2005 11:29:00 PM GMT
As I see it when moving with the tool up (not cutting) we are bound by the speed of the stepper motor and the friction and interia of the table. But when cutting we are bound by the speed that the bit can cut (which I assume will be much slower than the "not cutting" speed). My point is...Do we need accel/decel for cutting speed ? If we do the bit will not be cutting at a constant rate. Or am I just making this more complecated that is really is ?
The last version of the SX software I wrote just moved the major axis at the feedrate and the minor axis moved "as needed".
But I see what you mean.. As the feedrate is NOT a limit of the stepper, but is a rate for bit travel speed. So this would need to be adjusted for different angles. So one motor will have travel at feedrate*sin(angle) and the other will have to travel at feedrate*cos(angle).
Am I correct or am I all wet ?
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"
·
f = 1000
HIGH dir················· 'going left 1.000HIGH led
y = 1····················· 1 is left, 2 is right
FOR x = 1 TO f*/$3390
PULSOUT stp, 10
NEXT
posx = posx + f
PAUSE dly
I had to work out the */ operator.· It gives the the precise number of steps required to move the table .100, which is about 2.45 revolutions of the X axis leadscrew.· I have two different controllers on the X and Y axes, so I had to come up with different */ operators.
Is there anything else I can tell you?
Sid
I can't believe how far you have come in a short amount of time. Congratulations...
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"
·
Sid
You are correct. The feed rate is the speed the TOOL (path) travels at. And the tricky part is the need for linked accelerations
Also, as the table was meant to be a general purpose relatively precision machine, in my opinion traversing and inperpolation feed rates should not be assumed to be slow. For example, among other things, I expect to be winding coils with the unit by having the table trace out a circular pattern around a bobbin, feeing the wire out, and then automatically "terminating" the wire by circularly wrapping wire around wirewrap pins.
I also will mount a vacuum desoldering iron to the Z axis, and use it to desolder chips in pre-programmed patterns.
Furthermore painting with a small spray gun
Depositing glue for surface mount components is another...... it just goes on.
Hence the faster the more versatile.
Cheers,
Peter (pjv)
Are you aware of the G101 (formerly G2002) project finishing up over at the Yahoo group geckodrives?
If not, you might want to take a peek at it to while the hours away, as it seems to have similar end-goals as the SX component being discussed here.·
As of end-of-July, the G2002 files were deleted, as the project has evolved into the·G101; I can provide these to you if you would be interested.
Daniel
Not necessarily true. Re-read my post and you'll see that I covered this very issue. I suggested that you translate (or "compile") all high level G-Code instructions into an agreed upon subset of G-code instructions. If you want to convert arcs to a series of straight lines, it won't affect the ability of the SX to keep up regardless of whether the PC outputs G-Code or CM-Code.
As for the SX "keeping up", I wouldn't be too worried about a 50 MIPS machine being able to output high speed pulses while also parsing G-code or CM-Code. Back in 1999 I wrote an SX28 based two axis pulse generator for controlling stepper motors with the ability to specify any speed from 30 hz to 250 khz. The PC could specify the speed using integer values from 0 (fully off) to 16384 (250 khz). If all you want is to have a top output rate of 10 khz, that same code would do 8 channels without any problems.
The sky is the limit whether it's CM-Code or G-Code. Suppose someone does want to use the mill for something other than a mill - are you suggesting that using CM-Code is going to free them to do whatever they want whereas G-Code will prevent them from doing it? Given the shapes that are created on CNC machines these days, it seems that there probably isn't any motion that can't be expressed in G-Code. If you want to use the SX chip to move robots, that motion could be expressed in G-Code just as well as it could in CM-Code.
Here's G-Code for moving X to 10 and Y to 10 at the current specified feedrate:
G0 X10 Y10
Here's the CM-Code for doing the same (although this requires constantly setting the feedrate with each command):
!M 10, 0, 10, 0, 0, 0, 3, checksum
They both get you to position 10, 10, and honestly the G-Code looks a lot simpler.
The point I'm making is that G-code can express any move you want, so why come up with a new language/protocol to express the exact same things that G-Code does?
Finally, you mentioned that you didn't want to get out of bed to ride an old wheel. I hate to even bring this up, but creating a new wheel to ride just sounds pretty much like saying you want to create a new wheel because you don't like the old one, which in turn sounds like re-inventing to me. I'm not trying to pick on you, I'm just telling you what it sounds like to me.
Anyway, all of this is up to you guys anyway. It's your project and that's cool. If you want to create a new language protocol for expressing motion vectors, then go for it.
Thanks, PeterM
Not a rebuttal here but just some clarification...
I fully believe the SX is capable of doing what is needed.
I, too, well understand the capability of 50 Mips. What I said was that I feared SX/B might not be up to the job; principally because I believe it's not multi-threaded, so timings tend to be handled with pauses; an unworkable situation if relatively high speed multiple functions are required. At slower speeds?..by all means.
So I expect its a matter of trying it, and judging the preformance. Different users will have different needs.·My personal requirement·is for relatively high, commercial,·performance, and hence my whining about speeds.
I too would have a preference for standard G Codes, but Jack and Bean should be free to use those tools and methods they·are most comfortable with, and if that means re-inventing, then so be it. Anyone is free to add their own flavor to the extent of their available time, commitment and talent.
I would like to hear back from others as to the SX tasks the way I outlined them; if more functionality is required, then those programming need a clear definition of those tasks.
Cheers,
Peter (pjv)
Post Edited (pjv) : 8/2/2005 4:32:58 AM GMT
Would you be willing to etch an experiment, and post the results (photo of etch plus relevant BS2 code).
If possible, I'd like to see your square spiral rotated 45 degrees (that is, have the straight lines be a compound X Y movement). It doesn't even have to be a spiral, just a diagonal line would suffice.
If the diagnonal lines have 'jagged' edges, and if you have the capability of measuring the steps, it would be interesting to see what the magnitude of the steps are. If you don't have the measuring tools, perhaps you could do a close up photo with a reference distance indicated somewhere (perhaps a straight 0.01"· line on the X axis, and the same on the Y axis, and a single 'dot' where the tool-tip is simply plunged without X or Y motion).
I'm guessing that, on the straight single-axis travel, you are achieving the 0.001" (or 0.0005")·resolution you casually mention in your source code fragment back on your 7/4/2005 7:12 AM message. I'm wondering if you get close to that on the diagonals.
Daniel
Edit: back on 7/4/2005 7:12 AM, Sid stated an ability to nudge the Y-axis by 0.0005".· Do you have similar resolution on the X-Axis now?·
Post Edited (daniel) : 8/2/2005 5:33:07 AM GMT
It seems to me that homing is a dedicated, setup,·machine function, not normally performed in the context of any automatic operation.
If so, can't work proceed along the VP tasks that we have relative agreement on?
It is the fact that the Basic Stamp does not have this VP capability that I see as it's fundemental limitation to this application.
Daniel
Edit:· I do understand that SX/B's SERIN/SEROUT will have to be bit-banged instead.
Post Edited (daniel) : 8/2/2005 6:49:41 AM GMT
I plan to have the SX/B code use interrupts to send/recv serial data and to move the servos.
I just wanted to get the program working first.
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"
·
x 1.000, then draws two diagonals inside the square, which I was going to do this morning.· Would that do?
If not, could you send me a sketch of what you would like to see.
Sid
Exactly what I had in mind.· If you would move the drill tip to an isolated area and plunge it (Z-axis only) into the material to the normqal cutting depth.
I'm looking to see how the BS2 handles the "interpolated" motions in X & Y with respect to smooth edges.·
Daniel
See, there you go!
As I profess to be SX/B inept, my understanding of what it can or cannot do is not complete.
And yes, the home function is independent of other move functions, however, as you pointed out Daniel, monitoring the switches, doing the comms and all the other functions still need to happen simultaneously.
And all that hopefully at a speed such that 10,000 steps (10 inches) per second can still be reliably achieved with the target precision.
Cheers,
Peter (pjv)
Not a bad angle cut, really - just not on target.· The little dot at upper center is where I plunged the cutter to about the same depth as the square and angle paths.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"what's cheese to a mouse is a snack to a rat"
The MF70 will now take a small break
Sid
You will note the large differences in the */ operators for the X and Y drives.· The X drive is controlled by a Gecko microstep controller.· The Y drive is controlled by an IB463 controller, set for half-step.· In addition, the Y stepper has a 15-tooth pulley, the Y drive a 30 tooth pulley.· I needed a small power advantage for the Y drive since it was carrying the weight of the X table.· The X table is direct drive.
Just so you'll know, it took me hours and hours to figure out the exact modifiers for the */ operators.· My goal was to enter the travel I wanted, say 100 (Mils) and have the table move exactly that distance.· One rev of any drive moves the table .0393.· 100 mils takes approximately 2.45 revs.
It's all done now and·I'm quite pleased with how things turned out.· Can't wait to get my Z drive going!
Sid
Your not honestly suggesting that we send commands to a machine spinning sharp things without a checksum are you?
I have no idea what that is. What does the "!M" do?
x10 y10 would be
Speed multiplier = 0(last) & Speed linear = 1 = 00000001 = char SOH (unprintable)
X and Y at 10 = char LF (unprintable)
So we would send
SB X.0 X.1 Y.0 Y.1
| | | | |
XAcharAchar0Achar1Achar0Achar1
X121010
That is six bytes less the checksum. Gcode example is 8 less the white spaces and checksum.
That is a valid point. It could always be removed from the "CMcode"
My protocol example is just that. An example.
It probably still looks simpler..
It's bit bang machine code so it always looks weird in print. Not that my example is printable.
I might not have made myself clear (not news) but I'm willing to use anything we can all agree on.
I think we can agree to disagree on the "old wheel" deal. Innovation is never practical.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - 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.