Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: Sargon on November 27, 2010, 04:03:27 PM
-
I am having a problem with the formulas. Due to slight mechanical misalignment my router table is slightly out of square and with only a single drive on the y axis and a 48" gantry it also cuts longer along the y axis as x increases. Obviously the ultimate would be to correct mechanically, but short of changing to a slaved drives there will always be some practical error.
I have spent many hours on this problem and here is what I've found:
When you press "Cycle Start" it seems that the axis calculations are run upon the first move for all axis. This is normally not a problem UNLESS you have referenced the axis itself in the formula like f(y) = y - 0.001 * x * y. For my programs, Z is always moved to clearance height before moving X and Y to start location. When the Z starts moving and it does the formula calculation it IMMEDIATELY changes the DRO's to match the formulas.
For example, take a fictitious, exaggerated formula set like:
f(x) = x
f(y) = y - 0.001 * x * y
f(z) = z
Now, if my machine is at co-ordinate (X,Y,Z) (10,10,3) when I press "Cycle Start" then when the first movement code is executed (eg. G01 Z0.2500) the trajectory planner sends the Z axis to 0.25 at the feedrate specified like normal. However, at the same time, it also IMMEDIATELY sends the Y axis to 9.9 as per the formula, at infinite speed and acceleration. The result is an abrupt jerk and worst case scenario lost steps.
Why does this happen? Even if it was intended to apply the formula before the first move why isn't the correction move obeying the acceleration parameter? Also, I don't think it should even calculate the start position. If I have a part blank I want to add features to and I carefully set it all up, and then it does an initial correction move then the features will be offset. It should only calculate the formula for actial moves.
I may have a workaround using some careful scripting, or I could write a plugin, but I would prefer if it worked right in the first place. The correction in the end works well as it is (my parts are now square and y cuts equal lengths no matter where I cut the part on the table) but it is very hard on the stepper motors (they clunk pretty good).
Thanks for the software, Art. It is very versatile and works quite well.
-
Sargon,
Just out of curiosity, which version of Mach are you using ?
Tweakie.
-
Latest Dev version and it also happened before I upgraded to latest dev. According to the release log there hasn't been any changes in formulas since Dec 9, 2007 at version 2.62, so I even downloaded v2.63 and it seems that this is a long standing bug as it even happens in this nearly 3 year old version.
Any help would be appreciated.
-
To make it really easy to see, set the formula f(y) = y * 2 and type y2 in the mdi and watch the DRO jump to 2 x current Y value, and then feeds to the desired position of y = 4.
-
A workaround may be to always move your machine to X0 Y0 Z0 before applying Formulas.
If you set the formula, then close and restart Mach3, is the position using the formula when it restarts? If so, then you shouldn't have a problem? If not, just move to X0 Y0 before shutting off the machine.
Edit:
I just tested this on my design PC (no machine, but driver installed)
Set the Y formula to Y=y*x*3
With X at 3, and Y at 2, doing a Y3 with MDI takes about 15-20 seconds to get to Y 27. Turn off formula, and MDI Y2, and it takes the same time to go back to Y2. Feedrate is 100.
So it appears that I'm not seeing the problem that you are.
I'll try it with my machine later.
-
When I apply that formula (y=y*x*3) and set x to 3, y to 2 as you have done, do a y3 at MDI and my Y DRO jumps to +18.0000 and feeds to +27.0000. This was also on a test PC and not the machine connected to the router. I will repeat this test on that machine for a more conclusive result.
It seems weird to me at the moment that you are not getting the same results as I am. What ver are you running?
As for the workaround, I may have a better solution that is independent of start coordinates but have to wait until tomorrow to test it. I will post it here if it works.
Could others please try this and report the results? It would be nice to find out if this is an isolated problem with my machines or if it is an actual bug in the Mach3 software. Then I will know if I need to start digging into things on my end or not.
-
3.42.040
Do you have the driver installed?
If not, that could be the problem. Some things don't work correctly without the driver.
-
I have just tested the above on my router and it does indeed stall out the stepper as it hits it with pulses at full speed. Obviously driver is installed and working properly on this machine and no problems with the system cutting at speeds of up to 160 IPM (I cut plastic only, and for some materials the faster the feedrate, the better the surface finish).
One thing to note: this anomaly only happens on the VERY FIRST MOVE after a Reset or starting a G-Code file at the beginning, and will not occur under any other conditions that I've found yet. As far as I can tell init string has nothing to do with it as my init string in mach3 is only G80 (stop motion cycle) the problem does not happen if I send G80 from MDI and then move.
-
Update:
It actually happens on every cycle start. This is creating an offset any time feedhold is used with formulas turned on. The offset is equal to the amount of correction being applied to the axis. Also note that it indeed occurs even if f(y) = y + x. Hmmm, I should probably test f(y) = y + 0.1... I'll try that tomorrow.
I have found a workaround to make it stop slamming the motors with pulses. I modified the screenset to make the Start Cycle button execute a VB script that sets b axis to zero then execute cycle start. I then put my correction equation in for f(b) and set f(y) = y + b. This is protecting my y axis motor while still using the formula to correct table error. However, I'm not satisfied as feedhold is broken while using formulas.
Am I the only one with this problem?
-
Did you check the version?
Go to:
Control panel
System icon
Hardware tab
Device manager button
Look for
Mach X Pulsing Engines
Plus button
Mach3 Driver
Right click it, go to Properties
Mach3 Driver Properties
go to Driver tab
should see for version 5.50.0.0
-
That driver version is the same as I have. Dated April 11, 2010 I believe.
I have just reloaded XP and installed nothing but XP SP2 and Mach 3 (latest stable release). It still hammers the drive and the DRO still jumps to the calculated position before the machine starts to move normally.
Another interesting symptom is that if you feedhold in the middle of a move (ie pause it in the middle of a 10" feed) and hit cycle start again the stepper locks up indicating that it is being hit with pulses at full speed instead of being ramped up.
I can't see how it's possible that I'm the only one seeing this problem. This is now running on a "virgin" XP SP2, is not connected to the net, and Mach3 has no plugins running and no modifications have been made whatsoever. I have confirmed it on a number of other machines by visually watching the DRO's in Mach3.
Anyone who can, please verify that this happens on your machine by putting in a formula f(y) = y + 0.1 . The problem should occur on the first move from the MDI or when you press Cycle Start. At the MDI if you want to make it happen again hit reset twice and move again. It is easiest from the MDI if you just move another axis so that the affect can be clearly seen. You may want to turn off your CNC if you don't want to hit the motor with pulses that are too fast for it.
Art, if you are reading this, any help or insight you could provide would be much appreciated!
Edit:
This also happens using the Verify button on the MDI screen, and oddly enough, if you set f(y) = y + 0.1 and set your jog step 0.0001 and step jog on the x axis it will hit the y motor with pulses the first 3 times you jog (I guess something is stopping it from making the full jump).
Again, if others could please test this I would appreciate it very much!
-
I would say that 99.99% of all users have never ran with a formula so I think you are a minority with that problem(;-).
(;-) TP
-
Agreed ;(
However, this problem is almost bad enough to make the formulas completely useless! Surely this would wreak havoc if you were trying to drive a parallel machine with it!
Even if you don't use formulas, could you please test it and let me know? I really want to know if it's a problem with Mach3 or perhaps just with particular configurations or windows version.
Thanks!
-
Just my opinion, but I think that a single drive on a 48" gantry is probably asking for problems way beyond this issue. Although, as you say, it is not easy it would perhaps be better to concentrate on getting your machine square and to use slaved drives to better distribute the torque.
There may well be a bug in formulas, so what, it's no big deal - move on and get your machine right, in the long term it is a far better solution than a software 'fix'.
Again, just my opinion.
Tweakie.
-
I'm about 10 steps ahead of you, and the fact that mechanical solution is best is very, very obvious (to anyone who knows ANYTHING about machinery). I am well aware of the physics that this machine is working against. However, time right now does not permit me to rip the table apart as someone has already done that twice. The next time it comes apart it IS going to get dual drives (it just makes sense, doesn't it?), but that will not happen for a while. Also note I am only cutting plastic sheet and it puts virtually no load on the spindle or drives.
To be perfectly honest, a feature that does not work has no place in distribution software. I thank all who have worked to make this program as great as it is (I believe it is among the best because of it's flexibility), but this broken feature is out of place among the rest of the software that, for the most part, works flawlessly. I would say it needs to be fixed or removed. Just my honest, unbridled opinion. Of course, if it were to be removed it would eliminate native support for parallel machines. It is probably better to fix the feature because it is useful for a variety of applications (not just for correcting table error!) and makes the software much more versatile. The fact that there aren't many users making use of formulas does not negate it's usefulness to the users that would like/need to use it.
Thank you for your opinion, and I agree in principle, but in the practical world there are limitations, one being time, the other money, and I don't have much of either.
-
I've helped a couple people a few years ago set up formulas to correct an out of square Y axis. Neither reported the problem you have, although it was a much smaller correction.
I'll see if I can test this tonight.
-
Unfortunitly buggs in things that do not effect the majority are way down on the fix list as the squeaky wheel gets the oil. I think I would invest some time in correcting the aligment problem as a fix may be a long time down the road.
I am sure that is not what you want to hear but just the way it works.
Just a thought, (;-)
-
Lol... I'm going to write a plugin to do it if it gives me enough control... the table will be dealt with next year. The workaround I now have in place works, I just can't use feedhold and continue... I have to rewind, then everything stays lined up perfectly.
Thanks for the input and for confirming that this is likely a bug in Mach3.
Cheers!
-
I'll confirm that is a pretty nasty bug.
What I found was that jogging any axis other than the one with the formula would cause the one with the formula to not move when you did an MDI move. Doing MDI moves was OK, but jogging did it every time.
Like he said, the biggest problem is that nobody uses it. :)
I have a felling that this used to work OK, and crept in at some point and nobody noticed.
Actually, I'd always heard that it didn't work while jogging, so maybe it's always been like this? Reading this refreshed my memory.
http://www.indoor.flyer.co.uk/kinematic.pdf
-
Yes, the formulas are only applied to MDI and G-Code commands. I think this may have been intentional, I'm not sure, but it should probably be an option. The only spare time I have is when I'm at home so I will delve into plugin programming and see if I can get it all working without bugs that way.
Anyone who has any suggestions as to the best way to modify the trajectory I would appreciate it very much as I assume that this will be somewhat difficult to accomplish and this is my first plugin attempt (I like a good challenge! :) ). Assuming I am able to make it work well I will release it free of charge for anyone who wants to use it for parallel machines, error corrections, rotations without mixing up the DROS, etc...
-
hi- I am brand new to cnc and Mach 3. I am having trouble with the formulas. Moderator, if this should be a new thread let me know. The machine is custom built. It has two axis. No Z. It is going to be a portable cnc plasma. For now it is proof of concept phase. A axis is rotate(rotary table), and B axis is linear on the on top of the rotary table. It looks like a "banjo". The tool is held on the B axis and is constrained to a line that passes through the center of the rotary table.
Right now it is just drawing with a marker on paper.
I want it to run on standard x y gcode. My formulas are as follows.
A= arctan(y/x)*57.2957795
B=((x^2)+(y^2))^.5
It tests fantastic on the test feature on the formulas window.
All four axis (X Y A B) home at the rotary table's center.
I have been using very simple X Y gcode.
A note on something I read in the thread. I found the formulas work in MPG, Gcode, and STEP. Not on Hot keys and buttons.
Here is the problem. My test is a 5"square. I have drawn it at many locations on the table. It is consistent does not lose steps. It draws a complete square and it closes it. The size of the square is good and the corners form a perfect square. The lines that connect the corners are arcs.
If you draw a circle, the machine will drop the A and B axis completely.
I think my formula,s scaling and backlash(lack of) are good, The program seems to get it goofy or drop it completely. I have the problem at all feed rates. It it processing power on my computer?
Any thoughts would be helpful.
Adrian