Hello Guest it is January 20, 2020, 01:55:42 AM

### Author Topic: Bug in formulas  (Read 7328 times)

0 Members and 1 Guest are viewing this topic.

#### Sargon

• 99
##### Bug in formulas
« 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.

#### Tweakie.CNC

• 8,089
• Super Kitty
##### Re: Bug in formulas
« Reply #1 on: November 28, 2010, 08:46:22 AM »
Sargon,

Just out of curiosity, which version of Mach are you using ?

Tweakie.
Success consists of going from failure to failure without loss of enthusiasm.  Winston Churchill.

#### Sargon

• 99
##### Re: Bug in formulas
« Reply #2 on: November 28, 2010, 10:16:19 AM »
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.

#### Sargon

• 99
##### Re: Bug in formulas
« Reply #3 on: November 28, 2010, 10:19:19 AM »
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.

#### ger21

• 6,291
##### Re: Bug in formulas
« Reply #4 on: November 28, 2010, 11:26:40 AM »
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.

« Last Edit: November 28, 2010, 11:34:15 AM by ger21 »
Gerry

2010 Screenset
http://www.thecncwoodworker.com/2010.html

JointCAM Dovetail and Box Joint software
http://www.g-forcecnc.com/jointcam.html

#### Sargon

• 99
##### Re: Bug in formulas
« Reply #5 on: November 28, 2010, 09:43:47 PM »
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.
« Last Edit: November 28, 2010, 09:49:49 PM by Sargon »

#### ger21

• 6,291
##### Re: Bug in formulas
« Reply #6 on: November 28, 2010, 10:24:34 PM »
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.
Gerry

2010 Screenset
http://www.thecncwoodworker.com/2010.html

JointCAM Dovetail and Box Joint software
http://www.g-forcecnc.com/jointcam.html

#### Sargon

• 99
##### Re: Bug in formulas
« Reply #7 on: November 29, 2010, 09:05:24 AM »
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.

#### Sargon

• 99
##### Re: Bug in formulas
« Reply #8 on: November 29, 2010, 08:22:12 PM »
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?

#### Ya-Nvr-No

• 993
##### Re: Bug in formulas
« Reply #9 on: November 30, 2010, 07:36:32 AM »

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