Messages

91

General Mach Discussion / Re: Bug in formulas

« on: November 30, 2010, 12:52:59 PM »

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!

92

General Mach Discussion / Re: Bug in formulas

« on: November 30, 2010, 12:31:18 PM »

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!

93

General Mach Discussion / Re: Bug in formulas

« 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?

94

General Mach Discussion / Re: Bug in formulas

« 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.

95

General Mach Discussion / Re: Bug in formulas

« 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.

96

General Mach Discussion / Re: Bug in formulas

« 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.

97

General Mach Discussion / Re: Bug in formulas

« 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.

98

General Mach Discussion / 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.

99

General Mach Discussion / Re: 'Local System Rotated'

« on: October 09, 2010, 05:26:22 AM »

Bumping the thread!

I also would like an answer on this. It is a very useful feature that is unfortunately broken. I've stopped using it after scrapping a few pieces. Is there any chance that this bug can be fixed any time soon? Has anyone figured out a work-around?

I would really like to use this feature as it would be invaluable for rotating the parts to fit the available material on my router table without having to cut/rotate the sheet to avoid excess scrap.

I find it hard to believe that other people with router tables aren't also crying to have this feature fixed.

Art, are you reading this?

Thanks in advance!