Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: audiomaker on August 13, 2007, 07:17:08 PM
-
Hi Everyone,
My name is Sean and I am the moderator of the Deckel forum over at Practical Machinist.
After many years of talking about it, it looks like the "Deckelites" may finally be willing to attempt a PC conversion of a Deckel CNC milling machine as a group.
While I am a pre-Mach user/owner of Art's software, it has been years since I have been in this forum as at the time, Art's software was quite "young". I did manage a Bridgeport Boss retrofit using the beta of Mach 1, but the Deckel was out of reach at that time.
Today, as Mach has evolved, and more interest in converting a Deckel NC has been introduced, we are now very interested in moving on with a retrofit.
The Deckel NC is a very special machine, of the highest quality, and a very friendly conversational called a "Dialog", which can still hold it's own 20 years later. This control excels at shop floor programming and the logical subsitution of buttons/modes for what would otherwise be a "manual" milling operation using handwheels.
In any case, if you could offer and help, or would just like to follow along, that thread can be found here:
http://www.practicalmachinist.com/cgi-bin/ubbcgi/ultimatebb.cgi/topic/6/2104.html?
We'll probably be directing most tech' questions to this topic here on the Mach forum, but will have more machine specific issues at the Deckel forum.
It's good to be here again, and thanks for having a look!
Sean
-
Here is an example of the machine we are hoping to retrofit.
It has glass scales for feedback, AC servo's, a gearbox for speeds...etc.
(http://img.photobucket.com/albums/v500/twomarbles/3nc/_D2H0089.jpg)
-
Very nice machine. Looks like quite a challenge, but will be one cool tool when done..
Art
-
After reading your forum I can see that you have been a little slow at finding that there are ways to make Mach3 a closed loop control :) There are a few ways that this can be done and I would be happy to tell you more about the pro's and con's of each system... There is the Galil card (I am not telling you to get one by the way) that is a good system to run a +-10V amp... I have done a conversion with this and it works well ONLY if the accel of each axis is about the same. Why is this??? Well it all has to do with how galil chains the moves... I would like to change the galil to use an other mode but I don't think we can move data to the buffer as fast as we need to in that mode. The other way is to do what Hood told you and use a Pixi... This is one way that it can be done and is the lowest cost solution... There is an encoder board from Ron Rogers that works well... I made the code for the plugin and I can tell you that it works :) The Pluging is watching the encoders and tracking the following error of the axis. You could say "IT is not right because it is not telling the axis to correct the error"... To that I say WRONG! The servo is driven by the Pixe that has a PID loop.. THIS is where the error is taken out NOT in the computer! the computer will track the error and IF you get over on following error it will fault out. Yes this is how a Fanuc or any other works... I could add code that could look at the following error and slow the feed to try to limit the error that it is getting... This is not a big deal and can all be done with 2 P ports... So why would you use P Ports if you could have something so grand as a Galil! For 1400.00 I got a 6 axis one here for testing! The P port is going to be far less and there is going to be a NEW USB board that can run your machine at up to 4MHz pulse rate! Now you may be saying .. I want the standard!!!! +/-10V uuummmm... Not any more :( The new way is digital drives and I have also worked on bus systems that only send data! So for me I would take the new USB board and a few Pixies to get the best closed loop that I can for the money... For the people that are hard core and need to have it all one one board because it makes them feel better there is the Galil BUT you need to know that there is a limitation of the accel needing to be the same AND that I have not coded in the probing :( One thing that it will do VERY well is homing to an index pulse :) If there are people out there that think they can do better... I have the plugin code and if you think you can handle the code I would be willing to work with you... You need to have VS2003..
I hope that helps, I just wanted you to know what we can do now and that there are ways that don't have to cost you :)
ALso there is this board that I just got in the mail:
http://www.kelinginc.net/CNCSoftware.html
I have not started the code for this board but it looks like it is going to be good. It is less money then the Galil and looks like it will not have the accel problem
Well I have to get back to work :)
Brian
-
Is there a way to get rid of the annoying underlining of posts? Every word you folks have written in your threads is underlined for some reason??? Wierd.
OK, Brian, I have a quick question for you. Can you point me to this board by Ron Rogers. I'd like to read more about this and to better understand how this integrates in with the control. Specifically, you mentioned that a plugin you wrote for the card provides positional information back to the control. What is the control doing with this. My understanding is that because Mach is open-loop, it has no capacity to use this type of information.
The next question I have is related to your comment about how Fanuc and other machines work. I am baffled because you have stated that they work in an identical fashion as the open-loop Mach. But those systems do not have pixie interfaces in them. The encoder feedback is fed directly into the control and the PID is performed within the control. If your contention is that the internals of the control are doing the same thing as the Pixie, then I would agree with that. One way or the other a PID has to be performed on a servo based system. So long as the following error can be accurately monitored and error trapped, I personally don't care too much about where this is performed. Of course, having it inside the control does give one a bit more flexibility in configuration.
Finally, I am confused about the comment regarding the digital drives. I have heard a myriad of different comments regarding this. Some state that steppers are coming back into vogue. Others claim that the manner in which the control indicates the desired position is changing, specifically to a digital format. I guess that I really don't care one way or the other. I would agree that the digital invocation of position is probably becoming much more popular, but servos still seem to rule the roost over steppers... I'm curious about your thoughts on that though.
I'd love to hear your comments on these... I am one of the (more vocal) members in the thread that Sean was describing before. For the record, I think Mach is a great product. I am less thrilled about making anything on a Windoze platform though. I just don't trust that. For that reason, I am actually more of an advocate for doing this project in EMC than Mach. However, I have also readily acknowledged that doing the project in Mach would be faster and hence that is attractive. In the long run, however, I think I would ultimately move it to EMC for the previously described reasons. The (ultimate) donation to Mach would be easily given as I think the application should be supported. :)
I guess that is about it.... If you can provide links to any useful tools/accessories/interface boards/etc, that would be great....
Oh, one last thing.... I spend my days in VS2005... I am assuming that this is OK too? Sometimes the upgrade path between 2003 and 2005 is a little "murky", so I thought I should ask....
Alan
P.S. Just for kicks, I am currently looking into Mono to see if I could use .Net for EMC.... That should be "interesting" :)
-
<chuckle> Sean has taken a picture of my machine.... He has been storing it a year and I'm getting a good laugh because he now voluteering it as a guniea pig <LOL>. I say this, of course, with a good dose of humor because it doesn't bother me in the least (and I suppose there is tacit approval anyhow).
Alan
-
Found the Roger board and I'm happy with that.... I do have a concern about the fact that it is a parallel device though. To devote one of the two printer ports (hmmm, can't remember the I/O map on the PC... is it 2 ports or 4...) to the Rogers seems risky.
What type of implicit support is there in Mach for eithernet or USB based devices? Do you need to write all of that yourself?
I am liking what I am seeing but I am still very uncomfortable with the Windows platform... I would love some compelling arguments for why I should *not* be worried about it.
Alan
-
Alan
My servo drives (Giddings and Lewis DSA) are digital drives and take various inputs such as analogue, step direction, follower input etc. from your staement above, if I read right, it seem you think just because you use digital signals you must use steppers, I can tell you that is NOT the case.
The underlining I found very annoying at first and to be honest I still find it mildly irritating. It is there because all the text is being used as a hyperlink to the videos page, and that is the reason I find it most annoying, I have a tendancy to occasionally click my mouse when not meaning to and every time I do that I get transported to U Tube :D
Hood
-
Alan, also with regards to Rons board, you can still used the unused I/O on it as normal if I remember correctly, been a while since I had one. As far as the parallel port is concerned then its 2 max. This issue however will be getting addressed with the USB board brian mentioned. From what I have seen written so far it will be capable of taking the paralell port cables from your existing system, also it will have much more I/O than the parallel ports have. Heres the post on that board http://www.artsoftcontrols.com/forum/index.php?topic=3862.msg28602#msg28602
Hood
-
Hood,
Not at all... I think you misunderstood my meaning... Digital interfaces for servos are not unusual, although I do not profess to be an expert in that area (my CNC machines are either pure stepper or 1 to +/-10VDC servo amp based. I do know that there are digital servo systems out there... They have historically just outside my price range and/or need.
The comment I was making was that digital amps for servos need not be limited to step/direction.
Alan
P.S. Am I the only one that has underlining of all the poster's thread text in this forum? It is *really* annoying! Argh! I've got to see if there is a setting on my profile. Separating the lines is tough on my computer.
-
Alan, addressed the underlining issue above, think it was Benny that changed it and dont think its a profile issue.
As for the cost issue, I am in the same boat as you, ie cant afford or dont want to afford. I got my lathe without drives so did a lot of experimenting and ended up with 88lb/in AC Servos and digital drives. I got them from eBay and are probably about 10yrs old. They are Giddings and lewis or Allen Bradley or Electrocraft (all the same but with different badges ;) ) In the UK Allen Bradley doesnt seem to sell well so there are bargains to be picked up on eBay and quite often you will see new ones for not a lot of money, although I always seem to be too late for them ;)
Hood
-
There are no underlines on my Mac...but I don't know if that helps. Seems the HTML would be the same.
-
Hello,
Digital servo amps are GREAT :) You can do cool things like use Fiber optics... Yes that has been done in the past! There is an Unbuffered encoder line that comes out of the drive and this is used to monitor he following error of the drive... So in the end a good servo system should monitor the error of the machine and fault if there is anything that goes wrong. Now about steppers.... well they have there place and I like to have encoders on the steppers that I run :) I am not a big fan of lost position! If you were to see the mill that I have here for testing you would say "Why the HECK to have motors like THAT!" ... I run AC brushless servo motors on my test mill here.... I can rapid my knee mill at 500 IPM and has 1.3 Hp per axis (I love that thing) But just the motors and drives cost me 5000.00 ! On the small bench top test mill that I have is all stepper and it works but at 100IPM it is nice :( But the price for the machine and drive box with motors was only 2500! That is a deal... On a machine like the one that you have I would not use anything but servos because I would want to have the fast movement and so on.
As for the windows and linux thing... that is all up to you... EMC is great software and I will never take that from them BUT the fact that you have to know linux is a bit more then most can take. The Linux windows thing is like saying that my car is better then yours... I don't see the point... I have a friend that may turn off his lathe 4 times a year with Mach and win 2000. He has only mach3 and notepad on the computer. I know linux would work just as well as that if it only had that little bit of software running on it :) But then there are people on the other end like me ... I have Skype running (talking to people allover the world) as well as my E-mail and a few web pages open at the same time I am cutting a part on my laptop... This is not the best thing to do but I have never crashed out when doing it :) So the more you do the risk you have and I think that is the same for Linux and windows.
Hope all that helps
Brian
PS what the heck is up with the underlineing! (ON a linux server!!!)
-
as a complete thread derail, I only see the underlining happen in IE7 - in Firefox everything appears correctly, and i haven't tried IE6 yet..
that is all, i now return you to your normally scheduled thread...
scott
(edit: I found out what the problem is, I hope to work with Benny and have it fixed soon...)
-
I must have missed your post, Hood, on the underlining thing.... Sorry. I'll go back and look later in the day.
You all have very compelling arguments. I don't know that I will ever be comfortable with Windows running a substantial machine, but I do see that Mach has some big advantages too. As the hardware variation is getting smaller all the time, my inclination is to do a two pronged approach... Develop a Mach solution first. Even if this works great, I will probably look at an EMC afterwards (but hey, this is a hobby, so that could be a long ways away!). If I do the software correctly, it should be fairly transportable.
There are several reasons why I am taking this position. First, my previously mentioned concerns of Windows. Second, I program professionally and have always felt a bit of a "hole" in my Linux... An EMC integration will help force a filling of that hole. Kind of killing 2 birds, type of thing.
Next stop is to download the demo of Mach again, and do more research on the app, itegration to it, emulator functionality, etc, etc.
I would like to express my sincere thanks to you all... It is a pleasure talking with you. I love learning and am willing to acknowledge that there is a great deal I do not know. Your patience and comments are veyr much appreciated.
Regards,
Alan
-
I have a question that keeps nagging me regarding the open loop concept. The control outputs steps to a Pixie (for instance) that then transforms this to analog for a pseudo-closed loop. That is great for monitoring errors, but the part I do not get is how chaining is done reliably, aka look-ahead.
As an example take an external right angle... Unless you are at the terminus of the first line, you don't want to start the second. If you did, you'd end up with a fillet, which obviously is not good. By the same token, if the control assumes it takes 1 minute to go to the terminus of line 1 and it only takes 45 seconds, then there is a 15 second dwell time; needless to say, that is not good either.
The real pickle is that the time for the cut of the line can vary a bit as a result of loading, so I am at a loss to figure out how any open loop system can reliably make something as simple as a right angle *without* dwell marks resulting from an artificially long delay between successive commands. If someone can explain that to me, I think it will go a long way to making me feel more comfortable wiith the whole approach taken with Mach. I must be missing some fundamental, and simple, piece of the puzzle.
[on edit] In thinking about this more, I am coming to the belief that this is all about tuning... Obviously there is an acceleration and deceleration programmed into the control. I am assuming that the control assumes the servo is "caught up" when the control ceases to output additonal pulses. This makes sense, I suppose, if the tuning is such that the servo isn't trying to catch up. So.... Is that the piece of the puzzle I was missing?
Alan
P.S. Lines went away magically.... Ahhhh :)
-
Alan said -> The real pickle is that the time for the cut of the line can vary a bit as a result of loading,
Well, sort of, but no. In an 'open loop' (for our purposes a stepper system), the stepper is pulsed at a rate in accordance with the velocity commanded by the program. Until you reach the point of overloading the stepper its velocity will be synchronous to the command pulses, that's how they work (one pulse = a fixed angular displacement). The control (Mach III) knows how far it is from point A to Point B, and how many steps it will take to get there, the time taken will always be the same, based on your programmed feed rate. Open loop stepper systems are always detuned to ensure that there is adequate torque for any expected situation.
With an open loop motor system, varying load will increase/decrease travel time. Closed loop systems, be they steppers or servos, do have feedback. In the case of (servo) motors the feedback is essential, otherwise the control would have no idea how far/fast the motor had traveled. (A servo after all is just a motor with feedback.) With this feedback (encoders and/or resolvers) the (servo) control can constantly monitor the angular velocity and rotation of the motor and tweak the commanded voltage to the servo drive to keep it motor going the correct velocity and/or distance. The commanded velocity is still a function of the feed rate set in your program and at a given feed rate, the time from Point A to Point B will always be the same, despite load. If the drive is not capable of the required speed/torque then the (servo or stepper) control will raise an error as the commanded and actual position will be too far apart.
Brian Said -> For the people that are hard core and need to have it all one one board because it makes them feel better there is the Galil BUT you need to know that there is a limitation of the accel needing to be the same AND that I have not coded in the probing Sad One thing that it will do VERY well is homing to an index pulse Smiley If there are people out there that think they can do better... I have the plugin code and if you think you can handle the code I would be willing to work with you... You need to have VS2003..
The other consideration is the total number and type of I/O needed in the system and the resulting cost/complexity of the possible ways of getting the required I/O. In the case of the Bridegport VMC I'm converting, the cost difference between going with a G-Rex or one/two LPT's with a PLC to handle the rest of the I/O was only around $500. The system complexity is significantly lower though.
-
Hi Jeff,
I had just added some more information to my post and when I refreshed I saw yours. It seems like my assumptions are correct. This really gets down to a tuing thing. The assumption is made that, due to tuning, when Mach3 terminates sending pulses, the servo motor can stop rotation (and be within the tolerance of the following error). If additional rotation is required, then I believe my original concern is still valid. If Mach starts pulsing the second axis, then the result will be a kind of chamfer, not a theoretically sharp point.
Alan
-
"" I am assuming that the control assumes the servo is "caught up" when the control ceases to output additonal pulses."""
Alan, I don't think the control "knows" much of anything about the servo loop except that it has or has not reported an error.
If the loop is doing it's job, it cannot continue if it hasn't positionally responded correctly to the step input, so the axis will "have" to be in position for that next set of streaming steps or the loop would have already faulted out. It can't just take the next series of steps and "forget" it didn't make position on the first stream.
If the servo is "catching up" by applying more power at the moment the change of direction comes, I have to presume (this is over my head), that the drive has a buffer and the servo will continue to catch up...or fail.
It will continue to attempt to make the first position, not just "give up" and start taking new steps.
I think it is fractions of a second we are talking about here. The drive will fault before that buffer is overfilled and steps lost.
Sean
-
With Mach, servos and Pixies (or other S/D to analog converters). The Pixie translates each step (pulse) from Mach into a distance that the servo should move (the relationship has to do with #of encoder lines and the gearing of the drive). So when Mach is done driving an axis the axis is done moving, period. If the servo can't keep up a following error is generated (that can/should shut Mach down). The drive and Mach are always in sync, else and error is generated. Remember servos don't freewheel, when they are powered are held in position unless commanded to move from that position.
The situation you are talking about (rounded corners) has more to do with physics. Since the table has mass it cannot immediately stop/start. It accelerates from one point and decelerates as it gets to the next point. If you want a nice sharp corner then turn of CV mode (run in exact stop) in Mach and it will come to a dead stop at each corner before proceeding. With CV mode some rounding will occur but you get a faster and smoother operation of the machine. ALL machines /controls do this.
-
Hi Jeff,
You hit the head of the nail in your response.... OK, that is what I was looking for.
Thanks for confirming my thoughts.
--Alan
-
Alan,
Sorry may past few posts were bad :) I have been working way too much and was off fixing a servo system on a Lathe for a local shop... Now with a little bit more rest I should do a bit better job! ;)
I can see that there is talk about putting out step pulses to "catch up" if the system is not in position. This can not be :( You are sending commands to the Drive telling it that it needs to be at X position and you get a report back that it is only at x-.2. If this is true the PID loop is bad on the drive (we are talking about a servo system in this example) It needs to have a bit more “I” to move the motor into position over time. By telling the Drive to move an other .2 units you are in fact telling the drive and it should be a position X+.2 .This is not the position that you would like to have the motor... The PID loop is still trying to move into position and could jump ahead to the X+.2 position … This would be NO good! You could have two loops working against each other and that would be no fun ;( On the other hand I do think that you should know where the motors are all the time :) .
As for the Linux thing.. If you like it go for it! I had a linux box back in the day and was thinking that I should do it again when I have time… In life if we can't have a good time with what we are doing and learn a bit... It is time to change jobs!