Machsupport Forum
Mach Discussion => Mach3 under Vista => Topic started by: Werdelin on February 20, 2017, 04:48:04 PM
-
Hello,
I have just put a 3 axis router table together, and I am now fighting with the axis calibration in Mach3.
The Mystery is (so far) about the X-axis and the Y-axis. They have the same stepper motor, Nema23, the same Microstepper drive, Leadshine M542, with the same setting for microsteps (=16) BUT the screws do not have the same pitch. The pitch for X axis is 5, for the Y-axis is 10.
Wouldn't you expect the Steps Per in Config>Motor Tuning to be the DOUBLE for the X-axis compared to the Steps Per for the Y-axis? I mean, to move a bolt 1 mm takes N (number) of steps on the Y-axis,
for the X-axis it is 2 x N , since the pitch is half of what is on Y-axis?
Or am I just totally on the wrong path here?
Any help will be much appreciated,
best regards
Anders
-
Hi Anders,
You are on the right track.
There is a calculator here : http://www.machsupport.com/forum/index.php/topic,16315.0.html
And an example here : http://www.machsupport.com/forum/index.php/topic,12512.0.html
In addition, on the Settings (Alt-6) page there is an axis calibration feature.
Hope this helps,
Tweakie.
-
Hi Tweakie,
Thanks for your reply. It cleared out one mystery for me. Observing my screws a little closer, I discovered that they have the same pitch, and they have the same number of starts (2), however the diameter is different. But diameter does not play here...
I used the axis calibration on the Settings Screen in Mach 3, and now I have my axis calibrated. Now the Steps Per are appx exactly the same on both axis:
X : 160.00209
Y: 159.8356766
which I guess is a question of poor measuring. Might as well set them both to 160?
However: If I compare with the example that you sent me in the link, my Steps Per are ridiculously LOW. I've filled in my values in the quote below:
"Here is how you do the math. I will give you mine as an example. What we need to know is, How many pulses from Mach will it take to move the machine 1 mm? This is how I came up with the number.
My steppers have 200 pulses per revolution. ( 360 degrees divided by 1.8 degrees = 200 )
Micro stepping = 16. So 200 X 16=3,200
Motor to screw gearing is 1-1. So 3,200 X 1=3,200
Screw lead is 10 mm (pitch x starts). My screw will have to turn 0.1 rounds to move the nut 1mm. 1.0 divided by 0.100=10. So 3,200 X 10=32,000."
If I do the calculation myself, I come up with a value 200 times higher than that of the Axis Calibration on the Settings Screen?
best regards
-
Obviously you have some of your machine information wrong (maybe microstepping ?, maybe pitch ?).
The last line in your calc. (Screw lead is 10 mm (pitch x starts). My screw will have to turn 0.1 rounds to move the nut 1mm. 1.0 divided by 0.100=10. So 3,200 X 10=32,000) should be 3200 / 10 = 320.
However, the important thing is that you have it sorted. ;)
Tweakie.
-
Hi Tweakie,
In the Excelsheet "steppercalc_alenz_rev1" the lead is a multiplication of pitch and thread starts. I have measured the pitch not just once - the pitch being the distance from one crest to the next, regardless of number of starts (see attachment) - and it is 5 mm. With 2 starts it goes 5 x 2... It can't be that.
I will definitely have to verify the microstepping...
But what's the impact of this very low Steps Per? I have set the Velocity to 6000, but around this value my stepper motor trips out, not even being very fast, and with a default Acceleration value of 25, slow starts and slow stops. If I set my Steps Per higher, then the axis will travel longer than they should. Also, if you look at the second attachment, which is actually made from a gcode of a SQUARE with a CIRCLE inside it, the result come out slightly longer on one end, and the circle is dragged to an uneven oval? Does this mean that my motors lose steps?
[The last line of my calc is copy/pasted from the link you sent so the mistake is in Chaoticone's example, but I ought to have seen it. But maybe it should be corrected]
Anders
-
sorry, wrong attachment
-
Hi Anders,
Following the example calculation you have “1.0 divided by 0.100 = 10” it should be “1.0 divided by 10 = 0.100”
For motor tuning…
Start at 3000 and increase Velocity in steps until you find the place at which the motor stalls. Reduce the Velocity by 30%. Set Acceleration to 10% of the Velocity figure. You may be able to further ‘tune’ the set-up to increase speed but don’t risk destroying accuracy and reliability.
Check your machine axes mechanically as it could be a loose grub screw, coupler, etc. or mechanical binding that is causing that lost motion.
Tweakie.
-
Hi Tweakie,
I have tightened the motor block of the x-axis, and thereby I have improved the square and pocket above to be almost quadratic / circular. So you where right, the mechanical binding was indeed the reason
Still, for the steps per, the calculation even with the last value ends up being 320. Whereas I with steps per set to 160 get the table to cut the square depicted above in exactly the right measures? The big question for me is of course: Will I be able to tune my motors to the best performance possible with the present equipment, or will a steps per of 160 limit the possiblities when it comes to torque, speed, etc.
Another question I have for you is about limit switches. The limit switches and the home switches have been working fine, until recently, when I extended the cable for the limit switch of the Z-axis. Now, only the limit switch of the Z-axis is working, the home limit switch for the X-axis and the Y-axis seems dead. I have disassembled the plugs for the extensions to see if if I had made a rotten soldering, but verything seems to be OK. They all seem to be wired to the same pin, is there a way that I can test them individually? I have been looking at Config > Input Signals, but even with the Z-axis disabled (Home, Z++, Z--) the limit switch is working?
Do you have a clue?
best,
Anders
-
Hi Anders,
Obviously your drives microstepping is set to 1/8 which is just fine.
You are very unlikely to achieve any higher resolution or performance if you change microstepping to 1/16 so it would be better to leave it as it is.
I assume your switches are normally closed circuit (n.c.) connected in series. With everything switched off, use a multimeter (on continuity) at the breakout board to test your switch wires which should show closed circuit - operating any switch should show open circuit. If this is not the case then you may have made a mistake in your wiring of the extended switch.
Tweakie.
-
Hi Tweakie,
OK I'll leave it as it is, which is:
Steps Per =160 Velocity = 6000 Acc 60 Step Pulse 5 Dir Pulse 5
I will buy a multimeter one of these days.
However, when i click the GO TO ZERO, the X-axis is moving to its ZERO at a far higher speed than I can obtain by the motor tuning without the motor stalling? What is the explanation for that? Of course if I could imitate the tuning that the Mach3 is using for the GO TO ZERO command, then I'd be much better off speedwise...
Anders
-
However, when i click the GO TO ZERO, the X-axis is moving to its ZERO at a far higher speed than I can obtain by the motor tuning without the motor stalling? What is the explanation for that? Of course if I could imitate the tuning that the Mach3 is using for the GO TO ZERO command, then I'd be much better off speedwise...
Hi Anders,
I have no explanation for that but remember that accuracy and reliability is far more important than speed so don't go setting your Velocity too high. ;)
Tweakie.
-
Hello again,
I don't know if I can rely on that this thread is alive?
Anyway, I'll post and see.
I now have a software problem. I am using CAMBAM for CAM programme. And visually in the cam window, my design makes absolute sense, a number of logs cut-out from a 2440 x 1220 cm sheet.
Anyway I generate the gcode, loads into Mach3, and my design is in the middle: a lot of crazy arcs starting from either end of the sheet and looping to the other end in immense proportion.
By google, I have come across threads that almost exactly describes my problem, and relates it to the Distance mode / IJ mode:
CAMBAM is set to IJ Incremental C-P1
Mach3 is set to Distance mode: absolute and IJ mode incremental.
And I have spent the whole day doing anything in between, typed G91.1 in the MDI in Mach3, in CAMBAM switched from Incremental to default & postprocessor to Mach3, restarted programmes, updated settings etc.: STILL, those crazy loops!
I really hope that someone can help me out here,
best regards
Anders
-
In Config. General Config. change the JI Mode
then Regen. the Toolpath Display.
Ideally your Gcode should always contain the G90.1 / G91.1 as appropriate.
Tweakie.
-
Hello,
I have tried to do as you say, go to Config > General Config, change the IJ mode from Incremental to absolute and vice versa, whenever those loops appear. And after each swapping regenerated the toolpath window, to no avail.
The gCode of CAMBAM is set to default... here's the prologue in the beginning of the gCode string. With a gCode, like that should the IJ mode be incremental or Absolute, and should the Distance mode be Inc or Absolute?
( Made using CamBam - http://www.cambam.co.uk )
( WOODWAVY SECTION 1B R12 NAT 3 CAMBAM singular 2 4/10/2017 1:47:43 PM )
( T0 : 0.0 )
G21 G90 G91.1 G40
( T0 : 0.0 )
T0 M6
( WOODWAVY SECTION 1B R12 NAT 3 CAMBAM singular 2.nc )
( Made using CamBam - http://www.cambam.co.uk )
( WOODWAVY SECTION 1B R12 NAT 3 CAMBAM singular 2 4/9/2017 10:23:03 PM )
( T0 : 6.0 )
G21 G90 G91.1 G40
G0 Z3.0
( T0 : 6.0 )
T0 M6
( Profile2 )
G17
M3 S1000
G0 X4.9207 Y1153.611
G0 Z1.0
G1 F300.0 Z-0.4
G1 F800.0 Y1135.4444
Do you have any other ideas?
best regards
Anders
-
Exactly the same idea.
You Gcode is putting Mach3 into the wrong mode. Delete all the occurrences of G91.1 from your Gcode and replace them with G90.1
Tweakie.
-
I did as you suggested, and now I get "radius to end of arc differs from radius to start", but at least the loops disappeared from the Toolpath screen., hehe.
By looking around I've gathered that this is Mach3s expresion in words of the IJ mode problem?
I also have a yellow button on the mach3 screen bleow the Toolpath screen that says: "Abnormal Condition". When I click it says:
"One or more axis are enabled or disabled
IJ mode is absolute
Currently in metric units"
Does this say you anything?
best regards
Anders
-
I wish to add that if I
1) change every line with the G 91.1 (there is but one) to G90.1, and
2) ensure that the General Config > IJ mode : Absolute, then Mach3 tells me "Radiius to end of arc differs from radius to start", - however this message seems to block Regen Toolpath, so I cannot 'see what's wrong'.
And if I
1) change the general Config > IJ mode to Incremental
2) change the line G90.1 to G91.1 in the gCode made by my CAM programme (that's actually the default mode of my CAM programme), I get crazy loops.
From your experience, is it possible just to swap between G91.1 and G90.1 in both the Gcode and the Mach 3 General configuration, and that's all there is to it?
best regards
Anders
-
Hi Anders,
Just swap G91.1 for G90.1 in your Gcode - that's all you need to do.
Tweakie.
-
Hi Tweakie,
I am afraid that just to swap G91.1 for 90.1 in my Gcode will not make it work.
As I wrote in my last post, doing that makes Mach3 say "Radius to end of arc differs from radius to start", and seemingly there's no change to the crazy loops toolpath.
I had this from a different source:
"That definitely looks like the wrong IJ mode to me but you are really the only that can say for sure. I also wonder if there was a G2 or G3 that wasn't canceled when it should be?
Neither the distance mode nor IJ mode setting in Mach3 general config will make any difference (a G90, G91, G90.1 or G91.1 executed through Gcode overrides their relevant settings in general config) at all as long as the Gcode sets the correct mode as needed. Which it should because the Gcode is what determines what the right mode is. Well, ultimately that decision comes down to the programmer (the one writing the Gcode) and what they want the machine to do."
Can I ask you about this? If the CAM programme Gcode overrides Mach3 settings then changing the G91.1 for G90.1 in the Gcode would give the outcome that Mach3 changes it General Config> IJ mode setting. But how can I prevent Mach3 from making the crazy loops if I cannot change Mach3's "reading mode" of the Gcode?
best regards
Anders
-
Here's also what:
I changed the Arc Center Mode setting for the MOP in the CAM programme to Absolute, then generates Gcode from the design, and loads it into Mach3.
In Mach3, the General Config > IJ mode is changed to Absolute, all by itself. But still those crazy loops.
-
1.what version of Mach3 are you using?
What Cambam version are you using?
2.Draw something simple in Cambam and see if you have the same problem.
What ever you draw generate the code for it and also export it as a dxf.
Post the complete code and the dxf file.
3.I assume that you are using the Mach3 post processor in Cambam and there are a number of settings
for it. Make sure that the settings are the same as how Mach3 is configured.See / understand the differences in the Arc Center Mode.
Haven't used Cambam recently but it always generated good code for me.
RICH
-
Hello Rich,
I am using Mach3 version R3.043.066
I am using CamBam Plus [0.9] Rel 8P.
You'll have the dxf and the gcode in a sec.
(Hitherto I have produced the dxf in Rhinoceros, exported it with R12 Natural Export dxf mode, and the drawing appeared unchanged in CamBam, have been able to do holding tags etc. in CamBam on it). And I have done several dxfs that just worked all the way, this way.
best regards
Anders
-
I have of course been through every aspect of the Machining > Arc Center Mode, set it to default + set the postprocessor to Mach3, set Arc Center Mode to absolute, set it to Incremental CP1, P1C etc.
Just before I thought I have solved the problem and let the machine run an nc file, it made all the drill holes in my design, then set off to make a perfect arc all the way through a sheet of 2440 x 1220 x 21 plywood, and would have continued off the table if I had not stopped it. Reason that I thought I had solved it was that there was no toolpath showing, but neither any "Radius to end of arc differs from radius to start" message. Maybe there's a graphics card problem also...
The nc files (the Gcode that CamBam makes) with the crazy loops are in size about 150 KB to 400 KB, my PC has 1GB RAM.
The successful nc-files are way smaller , less than 50 KB
-
Hi Anders,
Just checked your posted Gcode file - it loads and runs just fine here (as it is, using G91.1).
Tweakie.
-
Anders,
File runs fine here also and using Mach3 version 062.
I don't use Mach version 066 and is problematic. I would suggest you use install and try version 062 or less.
See if that solves your problems.
RICH
-
Hi again,
@ Rich:
I will definitely try and rum version 062, thank you.
@Tweakie:
Have a look at the attached photo.
To the left in the mauvegreen field the Gcode in digits, and in the line with the setting of this specific Gcode: G91.1.
Below the General configuration window: IJ mode : Incremental
And in the toolpath window behind: Crop circles.
The photo is taken just after launching Mach3, nothing has been meddled with.
I also attach a copy of this specific code.
Along with a dxf of what I want Mach3 to show/ cut.
?
best regards,
Anders
-
Hi Rich tried to swap to v. 062, same thing
-
Hi Anders,
Clearly the Gcode shown in your last picture is not the same Gcode file as you originally posted.
Tweakie.
-
Anders,
Attached pic shows backplot of reply 25 posted nc file as compared to
the dxf. Notice that x axis is scaled in the code as compared to the dxf and also some stuff was not selected. I don't know what your doing in CamBam...........
I got the crop circles in Mach when the nc file was loaded.
Like Tweakie replied the file is not what you originaly posted.
Did you try the "original posted file" with correct config in version 062?
If you stay with the original posted info and solve the problem then
you can go on to more complicated stuff.
RICH
-
Hi,
The files posted in reply #22 was my attempt to solve the assignment that you, Rich, gave me in reply #20; the files run fine here, too. So I guess I can say that with the original posted info, there never was a problem.
I have a number of .nc-files that run fine.
However, I have a vast number of .nc-files which in Mach3 open with crop circles. They're all exported as .dxfs [dxf-option: R12 _ natural] from Rhinoceros, opened in CamBam in which they are processable and editable [profiles, drills, holding tabs etc]. Toolpath generated, then Gcode.
I can say with some certainty that the problem is not with Rhinoceros, since I have .nc-files done this way, who have no crop circles. And the .dxfs when opened i CamBam show no sign of crop circles, neither the ones that turn out to run fine in Mach3, nor the ones that come up with crop circles in Mach3.
I am sorry that I have sent a wrong .dxf-file, the correct one in relation to the screenshot in #25 you find attached to this post.
We are on the same level here: You have opened the .nc-file and you have experienced the crop circles, although both the Gcode had G91.1 in the prior section, and Mach3 was set to Incremental, right?
Is there any way that Mach3 can assume another IJ mode setting than the one that shows in the Gcode, is there any way that those crop circles are produced by some other instance than the G91.1/G90.1//GenConfig >IJmode:Absolute / Incremental setting?
best regards
Anders
-
Hi Anders,
I think you have demonstrated that this is not a Mach3 problem.
I am not certain that you are using CanBam correctly, because there are many users here and there has not been another identical reported problem.
The latest Gcode that you have posted has some of the arcs drawn in Absolute and some of the arcs drawn in Incremental - basically your Gcode contains a mixture of standards which cannot be processed by Mach3 without the appropriate G90.1 / G91.1 being added throughout the code (almost from line to line in some places).
What is it, I wonder, that you are doing with CamBam that is different to everyone else. ??
Tweakie.
-
Tweakie,
I agree it's not a Mach problem.
Did a quick try of the posted WOODWAVY SECTION 1A.dxf and generated
a profile code for the complete dxf from Cambam and no arc problems here.
See attached screen shot QUICK TRY RICH.
-------------------------------------------------------------------------
Anders,
Suggest you try generating code for just a small part of dxf
in Cambam.That makes it easier to look into what the problem may be.
ie; see SMALL PART OF DXF pic attached as an example.
The code for that pic is attached....TEST3 RICH.
It is just the a small part of your original nc file and
just added line numbers and commented out the problematic lines
280, 290, 310, 320.Note that there is no problem with most of the code.
If the g2 or g3 coding is not correct you can get crop circles etc.
and that can be due to number of things.
You can compare how it's drawn and how Cambam interprets each arc or line
if you have the time and want to investiagte. Cambam provides info on each
arc and line of the drawing.
Suggest you quickly generate code for a profile (with and with out offsets) and engrave and see how it goes.
Take Care,
RICH