Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: spencyg on January 01, 2013, 09:07:20 PM
-
Good evening,
I've just finished a control retrofit on an old Crusader Anilam CNC lathe. It has turned out very nice and I'm almost finished working through the bugs. My experience with Mach Turn is very limited and it appears to be far more buggy than Mill has been in years. This evening I was doing a bit of testing with G95 and IPR feed rates. It seemed to be working fine (I have a spindle index pulse which seems to be working with good stability) and then my VFD cut out due to an unrelated issue. I would assume that as the spindle index slowed to a stop as a result of the faulted VFD, the feed rate would also go to 0. This isn't what happened. The feed rate continued along happy as usual, both through the completion of that particular move, and then right on through to the end of the program (I was cutting air, so I let it continue running with the spindle stopped). I find this rather disturbing. Is the IPR just based on the programmed "S1500" and not looking at the index pulse? I haven't messed around with CSS yet, but if this thing isn't reading the actual index pulse than I suspect it won't work as I had hoped. I'm interested to know whether this is a problem others have experiences or whether maybe I'm doing something wrong....?? I do have the "Use Spindle Feedback in Sync Modes" checked.
Thanks
SG
-
If you have Use Spindle Feedback in Sync mode chosen (Ports and Pins, Spindle Setup) then every time you command a feedrate Mach will look at the spindles RPM and feed accordingly. If you change RPM between feed calls then Mach will not change the feedrate and that is what has happened to you.
For situations like you had there should be a fault signal from your VFD to Mach to tell Mach to E-Stop. There may or may not be a fault signal output from your VFD for that but I would think there would be. I had a macropump that would look at commanded RPM and actual RPM and if different by, I think, 10% then it would fault Mach, unfortunately at the time it would only work if I disabled modbus and as I needed that for the turret I couldnt. Now I have a servo on the spindle so I can set up the fault signal to tell Mach if the spindle has faulted so I dont need the macropump.
Adding to the feed question if you had the feed call on each line of code then the next line of code would not have fed at the normal speed, however it probably still would have fed along at a creep.
I hope the latter will be fixed in Mach4, we will see.
Regarding CSS, it doesnt work correctly I am afraid and never will in Mach3 when using G95. Mach Rev4 will , I am assured, fix this, again we will see.
Its been a while but if I recall what happens in Mach 3 is the feedrate will start out correct but as the spindle increases the feedrate will stay constant with respect to time but slow with respect to per rev and vice versa.
Hood
-
Interesting. So when threading it is also just looking at the speed at the beginning of the cycle or is it looking at it with a higher sampling rate? I was playing around with threading last night as well and during a 10 pass threading cycle I noticed the Z axis was stuttering from time to time. I was once again cutting air but I'm certain these hessitating moves would have trashed the thread. The Z axis doesn't demonstrate this behavior any other time. I have noticed that my index readout on the screen periodically blips to a much higher RPM reading, and then quickly returns. I suspect I have noise somewhere but also need to make sure the slots in my disc are wide enough. Debounce doesn't seem to help the issue in any significant way. If what you're saying is true than maybe I have something else going on because once the threading starts a blip on the RPM readout shouldn't have any effect on feed rate.
It is remarkable how different Turn is from Mill given that they are technically the same program. I feel like a newbie even though I've been using Mach Mill for nearly a decade.
-
Threading is different, it is done in the driver and feedrate is altered with respect to the spindle speed. The more steady your spindle is the better your threading will work but it will follow increases or decreases of spindle speed, within reason.
Index Debounce is the one for the Index signal but I have found zero to be what I needed, increasing has made things worse and going above 10 made it totally unreadable. A good clean signal is required so make sure your index cable is shielded and properly grounded, especially if it is 5v.
Hood
-
Regards the differences, yes there is a big difference but I think the major difference is the Turn screen. I dont like it, never have and also have never used it, I just altered my mill screenset for my lathes.
Hood
-
Good info Hood. I'm using a CNC4PC C3 index pulse board with a H21A2 phototransistor and a slotted disc. I've done the slot calcs and I'm at around 600us pulse width at 3000rpm. The sensor comes with a 6' lead already soldered on which is touted as being shielded, but it isn't. I need to swap it out for a shielded wire and ground it to the star point. The sensor wire is running right next to a bunch of power wires between 12V and 200V, so this is an issue. Thanks
SG
-
I seemed to have fixed the issue last night. I ended up rewiring the optic sensor with shielded cable to the C3 board which actually made the problem worse. I then rerouted the data cable which was running in the same cable way as the spindle VFD output (I know....stupid) and with some debounce I was able to get a very steady RPM signal in the DRO. I monitored the spindle running for half an hour or so without a single spike in RPM, and the threading cycle which was hessitating now cycles smoothly. I'm hoping to actually do some cuts on metal tonight to confirm, but I suspect I'm all good. Once again, improper machine wiring protocol to blame.
SG
-
Good you got it, hopefully threading will work well when you actually get to cut some metal :)
Hood
-
I'm STILL messing with my index pulse on this lathe conversion of mine. Per some recommendations off this board I converted the signal from the C3 into differential to the BoB due to some potential noise issues. I painted the index wheel flat black to avoid any optical errors. Mach is configured to allow syncing and has spindle speed averaging. The RPM readout seems to be very stable and doesn't hop around at all. I tried to thread for the first time tonight. The test piece was delrin and I was attempting to cut a RH 1x8 UNC thread 2" long. The first 3/4" or so of thread looks great, but then it looks like maybe one of the index pulses got dropped and the rest of the pitch is shifted over 1/2 of the thread pitch. It seems to correct at the beginning of each new cut since literally the first 3/4" or so looks perfect. It seems to be exactly half the pitch so a dropped index signal makes sense except for the fact that I've got averaging checked. It seems like the first few passes are great, but into the 3rd or 4th pass the thing starts buggering up. It has consistently done it 3 times now. I have noticed that I am getting a very consistent pulse out of the index LED on the C3 board and on the input in the BoB LED, but often times when I'm rotating by hand the LED on the diagnostic screen misses pulses here and there. I suspect there is something going on related to this but at this point I don't know where to look. I'm really desperate to get this machine threading due to a job I need to get out of here ASAP.
AAAAHHHHH!@#!@$!
-
Correction: The Index LED in the mach diagnostic screen is sporadically being triggered. The LED's on the boards appear to trigger very consistently but the Mach LED is getting maybe 1 in 10 when the spindle in running @ 500 RPM. I've tried all sorts of debounce settings but I don't think that would have any effect on this anyway.
So, index signal getting to the BoB but inconsistently being reported to Mach through the ESS. The RPM readout on Mach is getting its info from somwhere, but if the LED needs to be very consistent for threading to work than this is my issue.
-
The LED in Mach is of no concern, the refresh rate of the grapgics will be causing that.
What to suggest I dont know, I seem to see more people that have problems use the C3 but that may just be coincidence seeing as likely there are a lot sold.
The ESS should do excellent threading so I am suspecting it is the signal.
What version of Mach do you have? Also is it a licensed version of Mach as Demo (and Pirate ones) dont do threading.
Hood
-
Threading is different, it is done in the driver and feedrate is altered with respect to the spindle speed. The more steady your spindle is the better your threading will work but it will follow increases or decreases of spindle speed, within reason.
fwiiw, I do a lot of threading and find it quite reliable.
Cheers
-
Hello all,
I'm new to the CNC world and in the process of building a machine with a 2.2kw, water cooled motor and VFD. My background is a controls and VFD drive engineer. Some of the problem posted by spencyg could be related to interference from improperly grounded or no shielded motor t-lead cable. I see this situation all the time with customers. Improperly or no grounding can cause havoc with electronics caused by VFD output inductive noise.
Using a VFD requires shielded motor cable which is specially designed for this application. Igus, Belden and several other to name a few make shielded flexible t-lead. All shielded cables must be grounded to a central point and only on one end. Never daisy chain ground connections from one device to another - use individual ground runs back to a central point.
Do not ground the shield at both ends of the cables, this creates a secondary path for voltage ground looping through the equipment frame work. And always avoid running motor lead (AC) cable next to and parallel to low voltage (DC) signal cables.
Hope this helps...
-
Thanks for.the, comments all. I would agree with potential noise from the vfd but i have taken special care to isolate thee vfd and index leads. The motor power wires are not grounded however so I suppose I could look into this. What other options should I look into for an alternate to the C3 board? What is the most robust index.pulse solution out there? I'm not abig circuit board soldering guy so a canned solution would be preferable. In the mean time I'll see what options I got on the motor shielding front. Thanks all.
-
I always got good results from an Optek OPB 916B or 917B
The only other thing you need with that is a resistor to limit the current to the optos LED, I used 220 Ohm when using a 5v supply.
Hood
-
I thought about the refresh of graphics now allowing the LED to keep up. This would make sense to me if I was dropping visual index pulses @ 1000+ RPM but even when turning it by hand at maybe 40 RPM I lose LED pulses on the diagnostics page. I'll get the "tick tick tick blank tick blank tick tick tick". At 500RPM I can see the LED's on the C3 and C32 flickering at approx. 8-9hz...clearly visible. The Mach LED's should be able to display consistently at these low frequencies but they are not. I'm headed out now to check out the circuit with the scope and will report back.
-
There are quite a few dfferent things at play, first is the refresh rate of the screen then the update rate of Mach, Plugin update as well so a missing LED is nothing to be concerned about.
Using the scope is a good idea, it may show something up.
Hood
-
http://www.youtube.com/watch?v=eCZo9f5JKRg
Have a look at this folks and let me know what you think. My only thought is the timing pulse disc might need some tweaking on the slot timing.
-
Use a one slot disc and set the ratio in spindle pulleys.
Hood
-
Oh and regarding the LED, Machs refresh at the moment (Mach3) is 10Hz your rpm means your index is roughly 13Hz so intermittent LED is to be expected.
When using an external controller the pulse will be seen no problem by it. When using the parallel port the driver will see the pulse no problem (as long as its wide enough) But the screen LED in either case will not show the LED correctly.
Hood
-
I am actually wondering if the spindle pulleys ratio will be observed in the ESS plugin and that may be why there is a prescale in the Plugin itself.
Ask Greg if that is what the Index Prescale is for in the Plugin, ie set to 2 for a single slot rotating at half spindle speed.
Hood
-
Its actually backwards from that. The spindle rotates twice for every 1 disc rotation. I thought about tuning it back in the ESS dialogue but then I'd have half the threading resolution and I already consider 1 tick per revolution to be barely adequate. The slots in the disc are hand ground. I'm going to throw it in the mill and cut two precise slots to get rid of that differential you saw in the scope on the video. Do you feel like that is the core problem here?
-
It certainly wont help.
Hood
-
OK. I milled two precise slots with the CNC mill and eliminated the shift in the signal between slot 1 and 2. I turned the index debounce to 0. As a result the threading cycle seems to be working significantly better. It seems to want to cut an 11 pitch thread instead of an 8 pitch thread but I think I need to go back and revisit the Z axis steps per inch calibration since it seems to have also cut another surface on the component at 5.95" when it should have cut it to 6.00". I also need to go back and read the threading manual again. I'll report back once I have these last few bugs straightened out.
Thanks for the help.
-
SOLVED:
I was able to turn some very nice threads last night after figuring out the last of my issues. As I mentioned above the error between the two slots in my timing disc was the source of the inconsistent pitch issue. I suspect this particular problem was rather unique to my system since my index wheel rotates at exactly 1/2 the speed of the spindle. I have two slots on the disc so that my timing index still reflects a 1:1 ratio. Most people would have one slot because they are running the disc at the same speed as the spindle.
The problem with the pitch being wrong was also related to ratios. At first I thought maybe my Z axis calibration was wrong but it was spot on. In my pulley setup screen I had modified my pulley ratio to make the VFD and the RPM readout match. This was WRONG. The pulley ratio will reflect the ratio between the index signal and true spindle speed. I could have used this to keep just 1 slot on the disc with a 0.5:1 ratio, but instead I had the ratio set to 1.5:1. I only realized this error when it occured to me that the pitch I wanted was exactly 2/3rds of what I was actually cutting. Well, guess what 1/1.5 is? ) 0.667. When I changed my pulley ratio to 1:1 it cut a perfect 8tpi thread.
Since I changed the ratio on the pulley the VFD and the RPM readout were now significantly off. I fiddled with the rather miserable automatic spindle calibration function in Mach3 for an hour before I got the numbers somewhat close. They still are not the same (500rpm setting reads 460, 600rpm setting reads 600, 1300rpm setting reads 1100) but at this point I don't care much.
-
How are you controlling the VFD?
Hood
-
The VFD is being controlled through the C32 breakoutboard via analog 0-10V PWM. Using the auto spindle calibration feature in Mach did work, it just isn't as accurate as I'd like. I can manually tweak the voltage signal on the BoB to tune in a particular setting, but if I get 500rpm right on, 1000rpm is compromised. It seems like the auto calibrate routine should work better than it does...
-
Ok, have b=never used an CNC4PC stuff so not sure whether its PWM or not but have you seen the info Greg posted for the SmoothStepper and spindle control, I would imagine its the same for the ESS.
http://www.machsupport.com/forum/index.php/topic,9523.msg58400.html#msg58400
Hood
-
Been there done that. The spindle motor tuning tab doesn't seem to have any effect on the relationship between the 0-10V output and the RPM actually commanded. I wish there was a way to manually set the modification values which the auto spindle tune is coming up with.
-
Is it a VFD thing or a C32 thing, ie if you command your top speed is the voltage 10v and if you command half speed is it 5v?
I have only used 2 methods of spindle control, one is step/dir capable servo drives and the other is step/dir via Peter Homanns controller to an analogue servo drive. With either of them it has been a simple setup, no messing around with spindle cal, just set the numbers and go.
If however the voltages are correctly being output and it is the VFD then I can see why you may need some form of calibration.
Hood
-
Full speed as defined in the pulley ratios tab by the maximum RPM outputs a 10V signal and half speed represents a 5V signal. Likewise, when 5V goes into the VFD I'm getting 30hz out, 10V = 60hz. The pisser is that the motor isn't connected to the spindle w/ a 1:1 gear ratio. This is why I originally thought setting the pulley ratio would be ok, but that effects the index pulse ratio and thus throws off my IPR calculation. Brian obviously acknowledged this issue since there is the auto spindle calibration function.
-
The calibration would be long before Brians time, would have been Art.
Remember Art posting something about deleting the linearity.dat and starting again but not really sure on the specifics as I didnt really pay attention.
Did you try messing with the speed in spindle pulleys but leaving the ratio alone?
Hood
-
I did. The minimum and maximum seem to define the 0-10V relationship with the S word in the Gcode and within the screen input DRO. Beyond that they don't have any effect.
-
What is the ratio for spindle to motor?
Hood
-
I'm not sure exactly but it seems to be about 1.5:1 or so. The timing index to spindle is 1:1 and I have confirmed that only 1:1 should be entered in the pulley ratio box.
-
Yes the pulley ratio iis for the index so you need to leave at 1 if your index is not on the motor. If it had been on the motor then you would enter a ratio in that case.
I helped a friend set up his Avon lathe a while back, it was using a CSMIO controller which outputs 0-10v for the spindle. What we did was settle on what the top speed he wanted, 2000rpm. We then set that in spindle pulleys and then commanded S2000 and read what the spindle was actually doing. We then worked out the rough ratio of true to commanded and altered the Max Hz in the VFD to achieve the correct spindle speed, seems to work well.
Hood
-
That was the route I was going to try tonight. 2000 RPM is my desired maximum spindle speed within Mach and is what I have for a maximum speed in the pulley dialogue. S2000 gives me 10V out, so I think your method of tweaking the maximum Hz output in the VFD to make a true 2000 RPM @ the spindle is a good premise. I now have these auto tune parameters driving a strange adjustment curve which could cause issues. You mentioned the linearity.dat file....if I find that and delete it should I be back to a linear curve in my PWM output?
-
Yes you will need to delete the linearity.cat, you should find it in the macro folder of the profile you are using.
Hood
-
ual;l; I got the spindle close enough to be called "good for now". Changes to the spindle motor tuning in terms of steps/rev, max velocity and acceleration have 0 effect on the PWM pulse as best I could tell. I ended up setting steps/unit to 60 and then maxing everything else. With my particular VFD (Durapulse) there was a series of analog gain settings which define a linear relationship between control voltage in and the resulting motor frequency output in Hz. Once I got this dialed in to my particular settings I used the spindle autotune calibration routine within Mach to tune the actual voltage output from the C32 to the VFD to provide as linear a response as possible. I really like the concept of the auto tune, and even the initial autotune sequence. What I don't like is that I can't manually adjust particular control points after the control offsets have been established. What would be awesome (Brian and Mach4....are you listening?? :) ) is if you could interact with the resultant offset graph after the initial tuning run my just pulling on control points with the mouse. The control voltage output from my system is not linear so a modifier every 10rpm or so is necessary to keep the resultant voltage linear. It would also be cool if you could define the delta between each control point, so if you needed finer control you could have control points every 5 RPM while somebody who doesn't need it that precise could have control points every 50 rpm.
Anyway, for the most part when I key in an RPM, it gets to within 20rpm of the setting which is good enough for now. The only blip I still get is between 1700-1850. If I key in 1650 the rpm goes to 1650. If I key in 1700 the rpm goes to 1820. 1840 gets me 1890, and then 1900 gets me 1930. 2000 gets me 2000. Up to 1650 I get within 20 or so of the set rpm. If I could have access to the control points I could manually modify the particular range of interest, or better yet, have the auto tune actually get the curve right :)
That might be asking too much.
-
Ah ok thought you previously said the output was linear.
As long as you have it sorted now thats all that matters :)
Regarding Ver4, it likely will be done, maybe not at first but the modular way Mach Rev4 will be done it will make adding things easier and they wont break other things.
Hood
-
I thought it was linear but after getting the VFD settings straightened out it was clear that the 0-10V output is actually rather chaotic. Guess I'll just live with it for now and look forward to the release of Mach4 Turn some time in 2074....
:)
SG
-
I know Mach can output a fairly linear PWM as the CSMIO uses it and its very close right the way through the rev range on my wee lathe so it could be controller you are using.
I think you are being a bit optimistic with your release date, if it had been a mill then possibly, lathe no $%£^& chance.
Hood