Hello Guest it is June 03, 2023, 07:41:05 PM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - vinythewheel

Pages: 1
CVI MachStdMill (MSM) / question re compensating for probe offset
« on: November 04, 2013, 08:51:00 AM »
Is that possible to edit probing button?
For example:
I want to find the center of a circle. If i want good accuracy, i have to find the circle once then turn the spindle 180 degre and find center again. The résulting real center is the average of both mesurement. That way, all error introduce by the ecentricity of the probe, the TIR of my spindle, ... are wiped off.

To be able to do it, i have to modify the probing macro. Is that possible?

General Mach Discussion / Lost step on large gcode program
« on: November 29, 2011, 10:25:36 PM »
I have a lost step issue (or gained step) that I can solve. I spend 40 hours on the past two weeks to try to resolve this issue and i just return to the point I was at the beginning. I have no more idea and need help and idea from anyone who want to help.
I discover this problem when I want to mill a plastic mould during the finishing passes. The Gcode get 1:30h to finish at 300mm/min (12in/min) feed rate (30000 lines). The offset at the end on the Z axis was around 0.8mm (0.031in). So i scrap the job and do it again with slower feed rate. Results were worst.

Thing I already done:
To verify the integrity of the mechanical line in the axes, I just glue a metal plate on the rear shaft of the motor, then I home the axe and mark with a razor blade the position. Each time I home the axe, the mark on the metal plate and the motor must be aligned. That tells me that there is no mechanical movement in the coupling and no backlash in the ball screw. It’s also a good way to verify lost step because it’s independent of any raise in temperature that can occur in the ball screw that can make the axe move. I glue those plates two week ago and after several hours of machine run, the marks are still aligned.
To measure the lost step, I home the machine then I switch in jog mode with a fine step (0.001mm or 0,00004in) a normal step on my stepper motor is 0.025mm (0,001in) so this jog step is much smaller than my motor step. I then jog till the home switch led light on and read the displacement. After homing, the out-of-phase is always between 0,0400mm and 0,0425mm every time I do it. This difference is due to the time that mach3 and motor take to react when the home switch is trigged. Base on that, I run a G-Code program and after that run, I jog to the home switch to measure the out-of-phase in machine coordinate.
I put an encoder with 1000 ppr on the Z axe. This encoder gives me exactly the same amount of step lost that the homing method give me.
I first thought of PP problem, I read a lot of post on that forum. I find someone who has a similar problem which gets solved by the SmootStepper PP replacement.  It was the easiest way and less time consuming way to fix the problem. So I bought a SmoothSteper board.
 The SS didn’t solve my problem. But that helps on the general operation of the milling. All axes run smoother and the spindle can run at 1 RPM very smoothly. It’s a great board for all this.
Then I extract the 600pound milling from its hole and open the control panel. I re-wire the control of the drive. I use coaxial wire with the shield ground on the SS casing only. The SS casing is an aluminum casing which is supposed to be a good Faraday shield. I didn’t put those wires into the wire tray to maximise the distance between those wires and the power line. The minimum distance is around 4in and there is no parallel path between the controls wire and the power line. Base on the fact that the Stepper Gecko drive can have ripple voltage of 600V, the induction on in the control wire must be less than 0.5 V in the worst case scenario. The USB cables pass in the tray, I think that the communication protocol in USB removes the induction problem that can occur in the USB cable itself.  I speak with a colleague who have 40 year in the RF industry and know A LOT about induced noise. He tell me that a low frequency noise (<100 kHz) is the more difficult noise to get rid of with shielding. Special shielding material must be used. He also tells me that the coaxial cable I used will surely remove around 20 dB of noise which must be enough to solve my problem. 
All this work to remove noise didn’t solve the lost step problem.
I then wrote down a GCode who dig a square pocket inclined at 30 degree around the z axis. The step down is 0.05mm (0.002in) and the dimensions are 100mm x 100mm (4in x 4in) at federate of 600mm/min (24in/min) I toke 20 minutes to complete the run. The axe Z home exactly at the same place each time because there is no that much move in the Z axis. But the X and Y axes always home with an out-of-phase (or lost step) of about 0.05 for X and 0.07 for Y. If I run this code several time, I always get the same results. If I run this test at 1200mm/min (48in/min) feed rate, there is no lost step. If I run this test at 100mm/min (4in/min) the resulting lag get worst. Running those test without spindle give the exact same results. In constant velocity mode, the pattern is similar but the out-of-phase values are different. Increasing the pulse width in the motor turning screen didn’t change the results.
So I get lost. Is someone having an idea to solve this issue?
I think its will be a good idea to wrote down a macro who run the same pocket GCode over and over, record the out-of-phase into a file then change something like feed rate and run the gcode again. This program can get statistic result on a specific run and may be very useful to resolve lost step issue. I try to make a gcode who move down a little, stop and move down a little a couple of thousand time. The point of this code was to be able to know if I lose or gain step. But when I run this code, I home at the exact same position. If someone have an idea to create a gcode who can do this kind of work.

SmoothStepper USB / SmoothStepper and PLC with Modbus
« on: November 18, 2011, 12:25:12 AM »
Hy, brand new on this forum.
So... let’s go into it.
I have a milling 3 axes with gecko drive, spindle with servo, and automatic tool change. All do by myself. The motor control is made by Mach3 and all the rest is made by a Fatek PLC. I feel it's more reliable and safe to dedicate a PLC to control limits and estop because it's closer to the energy that way.
The spindle has 1 HP at 10000 RPM and all axes are mounted on 0 backlash ball screw and linear bearing. That makes the machine pretty fast.
I use tis milling on the past 2 year, toke me 3 year to build it.

A couple of day ago, I run my biggest and complicated G-code on that mill. An 3D mold for plastic part. The finishing run toke 25000 line of G-Code.  After the machining end up, I realise that there is some missing step. I look upon this forum and conclude that the tension on my PP wasn’t high enough. Then I decide to use SmoothStepper drive to overpass this problem. In fact, if I still miss some step, I can simply put some encoder on the step motor. Till yet, everything look fine.
After installing the SS driver and updating Mach3 to the lasts version, thing became worst.  All my input from Modbus stop working. I try to reinstall and reconfigure all the communication on the  Mach3 seting but never work.
When I open Mach3, SS throw me a error screen who tell me that Limits and estop are on another port than the SS port. All my input are set to the port 0 (Modbus port) when I open the debugger screen of Mach3, I see the led blinking as it normally do when I push my estop button on limits. So the config is good but something in the SS driver cut the communication or I don’t know what.
If I restart Mach3 on PP without SS, all input work well. Is there something I can do to fix this?
Really sorry for my poor English, I try to do my best

Pages: 1