How practical is it to build control software

[Switcher]

Something I've been looking into is "Microsoft Robotics Studio" ( http://msdn.microsoft.com/robotics/ ).

I know is says robotics, hey a servo is a servo.

You can watch an itroduction video here: http://channel9.msdn.com/ShowPost.aspx?PostID=206606 check out the bluetooth gamepad.

So far all I've seen are toys that they have worked on, I keep hearing about industrial robots, but havn't seen any examples yet.

This has only been out less than a year, & very hard to find any sites other than MSDN to see working examples, code, machines, etc...

I'm very, very interested in the industrial side of this, & hope things pick up a bit faster, we'll see.

Oh by the way everything you need to program is free...



.

[Switcher]

In Mach3 you can write your own plugins "Mach3SDK" http://www.machsupport.com/Mach3SDK/Mach3SDK.html


.

[Chris64]

Just to clear this up...I don't like the look of the default mach but that's not really my concern (although I'm impressed with the skin feature). I do think that I'm a little prejudice against a program where they don't take the time to make it well layed out by the third version...again, a pet peeve.

Really I'm interested in utilizing the Grex controller. I talked to the guys at Gecko and it doesn't sound like Mach supports the Grex yet. So my choices here are pretty limited...wait for mach or build it myself.

[CarbideBob]

Originally Posted by Al_The_Man Out of interest, what or how much do you down-load to the Galil at one time? I have played around with different interfaces to these cards, I wish I had the time to get more invloved, what Galil commands did you use to sync the spindle for the rigid tap, I am experimenting with the threading for a lathe, so it should be the same principle. I understand if you want to keep this to your self. Al.

Al
I have 1 task running in the galil card that is basically a watchdog program that is monitoring the motors for overloads, checking the safety switches, etc. This task shuts everything down when something goes wrong or of course when MS-windows decides to die while the motors are jogging at 900 ipm. The motion commands are sent to the card as the program executes line by line much as you would type them in from the terminal. Continuous contours are a little more complicated but basically you just sent a whole string of VP and CR commands and then tell it to go. I use the GR command for rigid tapping. I put an encoder on the spindle and gear the Z axis servo to it. Now when you turn the spindle the z axis moves up or down following your screw pitch. Note that this is a vertical machining center and I have a 1500 lb head pulling down on my leadscrew so there is no backlash to worry about. This would work for threading on a lathe in one direction but you couldn't do rigid tapping due to backlash/axis reversal errors when you try to pull the tap out. Glad to share this info, any questions don't hesitate to ask.

[Dennis Bohlke]

I think it’s practical if you can spend a few thousand hours working on the software before you get a usable program. It would seem to be more practical to purchase a ready-made program.

I think focusing on a specific machine or type of machine would be beneficial to shortening the development time.

I have also been eyeing the Grex. I think there are some possibilities with it, but there are some issues of great concern as well with it. It has been close to completion for about four years. In my estimation the core objectives of the original project manifesto have actually been met. I see a lot of script on the failure to sync a spindle motor for threading but that is actually mission creep.

The thing about motion control software is that the motion is really a big deal. It is not a trivial problem unless you are only going to concern your self with a program that just generates g-code files.

I did take on the task of building a motion control software program. It’s been over a decade of programming bliss. I resolved to forgo the g-code part and made a direct CAD interface to the machine.

It’s hard to say if it was practical to do it, but it certainly has been beneficial to me and the users of my program.

I think there is an expanding market for machine control software. I think the Machx programs are actually doing a pretty good job of plowing the field for more sophisticated approaches to machine control.

Art has said he currently has a registered client base of 7000. So that should give you a feel for the size of the market. If you are only going to build a program for one machine it is totally not practical.

Dennis
www.super-tech.com

[Chris64]

Dennis, I'm not really sure what my plan is, but I like to try and look at things from a different angle. My thought was actually building something like you said where it is a straight CAD program to controller. It's market (if any) would be 3-4 axis CNC mills. Mostly conversions which is a huge market. Really I just wanted it for me (but if it's marketable...why not).

I was thinking of using a method of starting the drawing with the shape of the stock (maybe a DirectX ".X" object). Then draw or import tool paths so the program can design the cleanout and finishing paths. The idea is that it would create a 3d object with each stage so that the new "stock" object would be the finished object from the previous process. This may be common in some software but I haven't seen it. I think this method would really assist with 4th axis design too.

Ultimately I figure there's no getting around the simplicity of using 3d objects for the final shape. There's so many powerful 3d design programs. This is my major problem right now with my early 80's controller with 1k ram. Making a nice square pocket just doesn't blow anyones socks off...and you can forget about trying to put in a company logo.

Plus I'd like to build a controller that isn't as big as the mill itself.

[Chris64]

Originally Posted by CarbideBob How about block lookahead and backlash compensation?

Can you explain this a little to me? The lookahead part.

Backlash compensation isn't as a huge concern to me right now for a couple reasons. One is that it seems to me like it's just tool path logic, each time you change directions on any axis, move a little extra. The second is that my machine right now doesn't appear to have any slop...I'm sure there's some there (is it possible to have no slop?) but it's very minimal (move right and left .001 without slop) and I have no compensation values currently entered in.

I am concerned about what I don't know about...if that makes sense. I made a 3 axis stepper control a long time ago through the 12 digital outputs from the parallel port. I didn't have to put any thought into accounting motor direction with that set up. I could go forward or backward on a whim without any problem. I did have a problem with my controller generating a ton of heat...but that's another story.

With my servos I do notice that when I'm using rapid movement that the servos seem to speed up and slow down stages. I don't notice that on normal motions.

[Dennis Bohlke]

Chris, I just thought I’d give you the benefit of my experience. When I started out I thought it would be a couple of thousand hours of programming, but I was way off. But that was before the fantastic visual programming tools were available.

I have seen a demo of VisualMill that does exactly what you describe with the 3D cut simulation.
http://www.mecsoft.com/Mec/Products/products.shtml

If you can build a program that will start with a raw block of stock material and simulate the tool cutting action with a rendered graphical 3D display, you got talent. By all means do it. It is a piece in the puzzle, and the puzzle is not complete with out all the pieces.

From my point of view if you open source your work, it has no value. If you maintain your intellectual property rights, I would be interested in implementing them. I have the framework of drawing to cutting in real time with on screen animation, 2D or 3D. As with most things it could be improved upon.

It would seem to be an awful lot of work to go through though, just because you are upset over a few sloppy screen displays in the Machx programs. As previously suggested it is much more practical to re-skin the Mach3 program. Few appreciate the miracle of the Machx motion control algorithms, the magic of that aspect gives Art a lot of latitude in display design.

If you can keep in mind that the screen and the keyboard are the sole user interface to the machine you can fit the machine motor controller into a shoebox.

I have a YouTube video at:
http://www.youtube.com/watch?v=L1-mF14GYhU
I am working on some tutorials at:
http://www.super-tech.com/root/itm.a...amxp-tutorials
They should give you some idea what kind of interface I am talking about. My human to machine interface is completely unique, as far as I can tell. I was thinking CAD, not control panel, so my approach to the problem was from a completely different angle.

Whether something is practical is always going to be subject to debate. One thing to consider is your return on investment, which can be measured in many ways.

Backlash is usually the mechanical slop between the lead screw and the nut. To compensate the axis motor has to reverse directions with out counting the steps as moved distance.

Look ahead is where the trajectory planner looks beyond the current segment of movement and adjusts motor motions accordingly. It is a waste of time to slow down for a minor deflection in angle when moving from one segment of movement to the next. Without look ahead the motion motors must slow down and start up for each segment of motion.

Dennis
www.super-tech.com

[Chris64]

Dennis, thanks for the info. I read through Grex docs most of the night...I'm going to try and order one today. It appears to have an option where you can specify true path or calculated path. As you said, in the event you're doing minor changes to the path you can use the calculated. If you're doing a right angle you would use true path. I'm very impressed with it. It appears to be (almost) as easy as telling it to go to XYZ coordinates. Some of the speed controls are explained a little weird but I think I get the basic idea of it. I'm curious about how I would interupt it's path mid stream but that's another story.

I'm looking into the 3d graphic part to see how practical it is. Re-writing dynamic vertices based on collision of two objects sounds like a headache.

And again...it's not the look of Mach that I don't like. I think I'd like to consider a different way of Cad->cam->Cut (you should appreciate that). Right now I'm graph paper to notepad to hyperterminal. I understand most the scope of what I'm considering...it's the unknowns that I'm worried about (hence this thread).