Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: ozwes007 on June 21, 2015, 08:30:31 PM
-
Hello all,
I am trying to pass a value from a script to Mach3. The Value is 13.846153846154. However, instead of passing this value it passes 13.8567. The value is the actual position that Mach will go to based on the Steps per Unit defined in the Motor tuning section. Now the issue is, this would be fine if it was a one off amount and wasn't used in additive functions or for that matter any arithmetic based function in your program. I use these passed values in a number of intense mathematical on the run equations that are duplicated upwards of 3-400 times per program.
The error that is generated due to this incorrect passing of value gets to the point that Mach3 is becoming useless as a program in any real accurate program cutting of parts.
My Question is.... Is this the correct way Mach3 passes values? or Am I missing something in the setup or the script writing in passing Values.
I use a few of the included Wizards to generate internal Polygon Shapes and have found that theses also generate the error in accumulated movements.
And No backlash has long since been eliminated ;-)
Wes
-
SO lets see your script. It all depends on what you are doing in the script and HOW you use the values.
NOW can you measure 13.846153846154 to insure that it is accurate ?? Can your machine CUT it to that degree ?
Remember that Mach3 is a $150.00 DIY controller running inside of windows (;-) There are concession that were made to make it all possible. ONe of those is accumalative moves. IF mach canot make a small move that is LESS than a single step then it adds it to the next move in the que and so on.
What is the minimum resolution of a single step for your setup ?
Post your script for review.
(;-) TP
-
Hi TP,
Not trying to be nasty, just asking for an answer to a basic flow process of Mach3.
The GCode and Script can be found here - http://www.machsupport.com/forum/index.php/topic,29895.0.html.
The measurement of 13.84615 or 13.8462 is actually degrees, and as I indicated it actually goes to 13.8467(hence the steps per degree is 355.5555555556). That in itself is not the issue. the issue is the accumulated effect of adding this value around the circumference of a Circle. This value is for a 26 Tooth gear, when you process this to a 233 tooth gear the amount in accumulation is quit high for practical use. When you pass the 13.84615 value around it remains within tolerance.
Wes
-
I think I may have found a work around.
At this point in the Macro
Dim Gear1 As Double
Dim AxisCut As String
Teeth = Question ("How Many Teeth on the Gear?")
Gear1=Val(Teeth)
SetVar(6,Gear1)
Gear1 = 360/Gear1
Print Gear1
SetVar(1, Gear1)
I changed it to this
Dim Gear1 As Double
Dim AxisCut As String
Teeth = Question ("How Many Teeth on the Gear?")
Gear1=Val(Teeth)
SetVar(6,Gear1)
Gear1 = 360/Gear1
Gear1= Round(Gear1,4)
Print Gear1
SetVar(1,Gear1)
Basically rounding the value down to 4 Decimal places gives me 0.003 of a degree maximum variation. Im thinking it might be a rounding issue or not being able to handle large value decimals in the Variable.
Your Thoughts?
Wes
-
I did not take it as nasty(;-) I just needed a bit of perspective as to how you were using the values.
SOMETIMES I get a question like this and they have build a presicion CNC out of 2x4s using threaded rod for screws and complain about not getting 0.00000000001 accuracy cutting nylon and they know it for sure because they have a $5 plastic caliper and the part is not coming out to the .0000001 in a shed that is at about 200deg F and 96% Humidity. (;-)
YEP you found one of the answers the other would be to use format . The actual values that mach3 use internally are very large decimal wise. TO use them with YOUR accuracy you have to intervene and set the needed resolution or limit the rounding as you did. Otherwise Mach may just rounds UP to the DRO display resolution.
To be sure I would round to the 5th instead of the 4th. GEARS need to be precise.
I like your thinking (;-)
(;-) TP
-
Thanks TP.
I did try the format function first, however the results were unpredictable. May have been the Format is was using (I think ##,##00).
I will try the 5 digit and see if it makes any appreciable difference. I initially used 4 as that was all the DRO's show.
And yes I can appreciate the $5 dollar caliper standard. I actually had a customer complain about a job i had done for him because his Calipers(yes they were Chinese plastic ones) indicated I had machined a part over 2mm Larger then he wanted. Stupid me, i should have used his calipers to make it ;-).
Wes
-
Ok Final Test.
Changed the 1024.set A Axis DRO to 6 decimal points and the Round function in the Macro to Match.
on a 705 mm Dia Gear with Mod 3 gear cutter at 2214.822821 mm Circumference, each tooth is accurate to .012 mm max( In theory)
I believe the rounding is the way to go on this one, and i will leave the 1024 A Axis set to this so i can verify as i cut
on the smaller 1-300 mm gears.
Thanks for the inspiration TP, sometimes we just need to step away from these things for awhile and the answer will be there when we get back.
Wes
-
HIYA Wes, I am glad you got it sorted out. Mach3 was built for the general DIY users and there are many things based on general DIY CNC knowledge. BUT mach3 is capable of PRECISE ACCURACY if you know how to extract it.
Good job on the gear work. Have you tried Arts Gearotic motion program ?
(;-) TP
-
Yes, I have had a look at it. Some of the information and design features are brilliant, however not having tried the cutting function I would be remiss in passing judgement.
I would think it would be great for small RC gear cutting and GoKart gear boxes and such, and certainly for low production 1 off assemblies that don't require low noise gears.
And as you can see, I am only looking at it from my background in engineering.
As to Mach3/4 being DIY, I believe those days are gone, as I am seeing more and more Taiwanese, Chinese, American, and Australian products brought of the shelf incorporating Mach3 as the Control software. Even a lot of the questions on these forums relate back to store bought Mach3 configurations. It is a problem with Good after market software, eventually it gets used in commercial stuff, and the robust nature of its design come to the fore. From that stems the inevitable intellectual/legal lock down of the software.
Also TP, I put up a macro used while trialling the Number features of Mach Cypress Basic. It becomes quite interesting when you put in large decimal place numbers.
I.E. what rounds up and down and where the cutoff point is.
Wes
-
HI Wes, The problem with Mach3 as a Commercial contoller is there are a good number of bugs and odd things left in Mach3 that can ruin parts and break tools and tear up hardware.
Tool comp has problems, Subs have problems G2 and G3 CAN have problems . The Z is know to run away from time to time(;-)
AND it will never be fixed (;(
There are also OEMs packing up and leaving Mach3 because there is no hope for it to ever get fixed. In mach3's idles years the competition Zoomed right on by .
SO I leave it classed for simple DIY users (;-) , There is does well.
(;-) TP
-
another thread about mach leaving me pulling my hair.
im just a guy with an old dos based knee mill cnc and an old fanuc engine lathe. both controls down, too old, dont want to fool with them,
i want to go to mach and an external motion control device and modern computer with modern software. something i can put
together thus learning the internals so i (with help) can maintain my own stuff rather than calling the $$ fanuc man.
every time i think im ready to move a little, i get cold feet. i sense that most of the many many problems seen on these forums
come from someone wanting to couple a laptop to a $10 chinese bob, and drive steppers stolen from god knows where and
wired improperly. so i get inspired, until i see a post like TP's above.
other very knowledgeable folk on this forum have seemingly incorporated mach3 into machine tools and are very satisfied.
leaves me very confused. what version of mach3 is the least buggy, and what are those bugs? can i at least depend on
one version to act in a stable manner if i am willing to avoid certain programming techniques? is mach4 really better? reading
the mach4 forum section leaves me pulling my hair too. is there any mach version buttoned down and ready to roll, if the machine
is properly built from good quality components? TP said "the competition zoomed right by..", TP, do you mean that systems
like Eding, usbcnc, others may be better alternatives than mach?
are there any threads i have missed that serve as a faq for all the above questions?
i welcome all input, in this thread, on this forum, or via pm.
thank you,
ken
-
Hi Ken,
The issues I have found nearly always come from the setup and the GCode speed. Also the need to reboot the machine daily helps. This may be a windows issue, as XP and most other versions of windows have memory leaks(memory over time is lost or corrupted while in use). I push my Machine to its limits on accuracy, so errors i predominately see are related to this. TP's comments on G2-G3 issues may be true, i have not found that to be the case, however I always put G04 P250 Moves after all Z moves and G2-3 moves. I do this because reading to many lines ahead and not having error correcting Ram in your machine is just a disaster waiting to happen. And quite honestly I have witnessed the same issue happen on top range machines(unexplained crashes) and the only thing we can put it down to is Hardware feedback or memory glitches. A lot of this latter can be eliminated by ensuring the Power input to your device is as glitch free as possible(use a UPS at a bare minimum).
So go for it Ken, get a kit, start fiddling. Its fun, its frustrating, however there are a multitude of people on this and other forums that have been there and done that.
As for Buggy versions of Mach3, they are documented in the Known bugs section. I use version .67.
Wes
-
I am trying to pass a value from a script to Mach3. The Value is 13.846153846154. However, instead of passing this value it passes 13.8567.
I don't see this here. If we take this snippet from your macro and enter your 26
Teeth = Question ("How Many Teeth on the Gear?")
Gear1=Val(Teeth)
Gear1 = 360/Gear1
Print Gear1
SetVar(1, Gear1)
The value that is printed is 13.846153846154 and the value in var 1 is exactly what it should be i.e. 13.8461538461538 so I don't understand where your 13.8567 is coming from.
-
I am trying to pass a value from a script to Mach3. The Value is 13.846153846154. However, instead of passing this value it passes 13.8567.
I don't see this here. If we take this snippet from your macro and enter your 26
Teeth = Question ("How Many Teeth on the Gear?")
Gear1=Val(Teeth)
Gear1 = 360/Gear1
Print Gear1
SetVar(1, Gear1)
The value that is printed is 13.846153846154 and the value in var 1 is exactly what it should be i.e. 13.8461538461538 so I don't understand where your 13.8567 is coming from.
Hi Stirling,
All the above I have resolved. The 13.8567 is what appears in Mach3 DRO as #1 after it is passed. The Value in the Macro is exactly as you state. Im not 100% sure where the 13.8567 comes from either, however if you check the bottom of the previous page you will see how I used a rounding function and Increasing the DRO decimal places actually fixed the Issue. My personal belief is that there "appears" to be a double rounding when you pass the Var back to Mach3. And Just for clarity the rounded Number as it should round is 13.8462, and this is applied when I use the Round function and actually appears in the DRO as such.
Wes
-
Hi Wes
I appreciate you've sorted it but I'm just interested in why you had to do what you had to do. Any chance you could post your xml so I can set my system exactly as yours. Also the values you're inputting to your macro prompts?
-
the XML is included in the zip file here - http://www.machsupport.com/forum/index.php/topic,30351.0.html
the input for this particular gear is 26 tooth gear, 22 wide, 6.014138 Deep and 1 for the cut depth.
You can play with the tooth numbers and you will notice the inaccuracy at higher numbers is quite high(for gear cutting)
The full Code for the Macro and GCode is here - http://www.machsupport.com/forum/index.php/topic,29895.0.html
I have altered it a little for precutting the gears, however this issue relates to what's in this code.
This is the macro I used to run through the different number outputs - http://www.machsupport.com/forum/index.php/topic,30344.0.html
I have noticed when I set all my X,Y,Z and A axis DRO's to six decimal points for some reason a very small discrepancy in cutting that I have had since the machine was built appears to disappear.(only talking fractions of mm's here over 20-30 repeated cuts, which i assumed was backlash in the belt drive system)
Hope this helps.
Wes
-
Hi Wes
I ran your code and macro and recorded the actual step pulse output. the first .pdf shows the numbers:
The largest positional error as defined by your machine setup for A is 0.001998759mm.
I then ran it again with your round() modification and the second .pdf shows the numbers:
The motion was virtually identical except for a couple of cases where the step numbers 4923 and 4922 were reversed. The maximum error was 0.001776495mm so about 1/20,000ths of a mm difference over the first run.
Your machine's (theoretical/mathematical) precision according to your motor tuning is 0.0028126... mm/step so in both cases Mach has done its job and kept the error inside your machine's resolution.
Note that this is what your machine is ACTUALLY doing. It matters not how many decimal places the DROs show, changing the DRO "precision" does not cause Mach to alter its step pulse output.
Anyway - hope this is useful or at least interesting.
-
what version of mach3 is the least buggy, and what are those bugs?
Not sure if anyone knows, or if it's documented anywhere. Since 3.043.066 is the one currently on the download page, I'd assume that the developers feel that is the least buggy. However, many users have found that version unusable.
Imo, Mach3 is not nearly as bad as you';re being led to believe.
Yes, comp (G41/G42) has bugs. But I use it for 90% of my parts, and have only had an issue with an incorrect toolpath once or twice. Don't use it in subs or with offsets other than G54, though.
You need to be careful when using subs, especially with offsets.
I'm not aware of the G2/G3 bug Terry refers too, and I would expect that 99% of mach3 users aren't either.
can i at least depend on one version to act in a stable manner if i am willing to avoid certain programming techniques?
Yes. One thing to consider is that if you're using an external motion controller, it's plugin may be based on a specific version of Mach3, and it will probably work best with that version.
I've had good luck running older 3.042.*** versions, and most versions after 3.043.028 are OK as well.
Iis mach4 really better? reading the mach4 forum section leaves me pulling my hair too.
You're not alone there. Many longtime Mach3 users are very disappointed with the current state of Mach4, and some of the decisions that the developers have made.
-
Hi Wes
I ran your code and macro and recorded the actual step pulse output. the first .pdf shows the numbers:
The largest positional error as defined by your machine setup for A is 0.001998759mm.
I then ran it again with your round() modification and the second .pdf shows the numbers:
The motion was virtually identical except for a couple of cases where the step numbers 4923 and 4922 were reversed. The maximum error was 0.001776495mm so about 1/20,000ths of a mm difference over the first run.
Your machine's (theoretical/mathematical) precision according to your motor tuning is 0.0028126... mm/step so in both cases Mach has done its job and kept the error inside your machine's resolution.
Note that this is what your machine is ACTUALLY doing. It matters not how many decimal places the DROs show, changing the DRO "precision" does not cause Mach to alter its step pulse output.
Anyway - hope this is useful or at least interesting.
Thanks for testing this Striling.
A couple of points though that may be of interest.
The error i get from rounding is as I said is quite good, however passing a Val without rounding causes the error on rounding to compound to the point of being outside of my work Parameters. This issue I am seeing is not in the machine setup or the degree of accuracy but in the handling of the value being passed from the macro to the Gcode. Of interest is if you use the rounding Function 180 and 360 are seen as 180.000000 and 360.000000 in my setup, yet in yours I see values quite different. My error without the rounding if I Remember correctly(deleted the XL file i was using sorry)was small. yet accumulative quite large from actual. Once again it may be a version specific thing, however passing the Val from the Macro to the GCode is were the error started and by using the round function it was eliminated.
Wes