Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: Brotenc on December 29, 2017, 04:41:05 PM
-
With machine homed and zeroed if I use jog in either X or Y direction the DRO indicates that the move is longer than the Jogging increment.
If the increment is 1.00 the DRO shows 1.0002
If the increment is 0.1 the DRO shows 0.1003
If the increment is 0.0100 the DRO shows 0.0103
If the increment is 0.0010 (or smaller) the DRO doesn't change and the X or Y axis does not move.
In all cases if I jog back in the negative direction the DRO goes exactly the correct amount.
The Z axis does not have this error
The diagnostic screen does not show the error because it only shows 3 places to the right of the decimal point.
In the jogging configuration jogging is shown to support from 1.0 to 0.0001
If I activate the diagnostic log I can see each of the jog increment change requests.
2017-12-29 13:33:28.832 - API: mcJogSetInc(inst = 0, axis = 0, inc = 0.1000) (Mach4GUI)
2017-12-29 13:33:28.833 - API: mcJogSetInc(inst = 0, axis = 1, inc = 0.1000) (Mach4GUI)
2017-12-29 13:33:28.833 - API: mcJogSetInc(inst = 0, axis = 2, inc = 0.1000) (Mach4GUI)
2017-12-29 13:33:28.833 - API: mcJogSetInc(inst = 0, axis = 3, inc = 0.1000) (Mach4GUI)
2017-12-29 13:33:28.833 - API: mcJogSetInc(inst = 0, axis = 4, inc = 0.1000) (Mach4GUI)
2017-12-29 13:33:28.833 - API: mcJogSetInc(inst = 0, axis = 5, inc = 0.1000) (Mach4GUI)
2017-12-29 13:33:30.409 - API: mcJogSetInc(inst = 0, axis = 0, inc = 0.0100) (Mach4GUI)
2017-12-29 13:33:30.410 - API: mcJogSetInc(inst = 0, axis = 1, inc = 0.0100) (Mach4GUI)
2017-12-29 13:33:30.410 - API: mcJogSetInc(inst = 0, axis = 2, inc = 0.0100) (Mach4GUI)
2017-12-29 13:33:30.410 - API: mcJogSetInc(inst = 0, axis = 3, inc = 0.0100) (Mach4GUI)
2017-12-29 13:33:30.410 - API: mcJogSetInc(inst = 0, axis = 4, inc = 0.0100) (Mach4GUI)
2017-12-29 13:33:30.410 - API: mcJogSetInc(inst = 0, axis = 5, inc = 0.0100) (Mach4GUI)
2017-12-29 13:33:31.465 - API: mcJogSetInc(inst = 0, axis = 0, inc = 0.0010) (Mach4GUI)
2017-12-29 13:33:31.465 - API: mcJogSetInc(inst = 0, axis = 1, inc = 0.0010) (Mach4GUI)
2017-12-29 13:33:31.465 - API: mcJogSetInc(inst = 0, axis = 2, inc = 0.0010) (Mach4GUI)
2017-12-29 13:33:31.465 - API: mcJogSetInc(inst = 0, axis = 3, inc = 0.0010) (Mach4GUI)
2017-12-29 13:33:31.465 - API: mcJogSetInc(inst = 0, axis = 4, inc = 0.0010) (Mach4GUI)
2017-12-29 13:33:31.466 - API: mcJogSetInc(inst = 0, axis = 5, inc = 0.0010) (Mach4GUI)
2017-12-29 13:33:33.059 - API: mcJogSetInc(inst = 0, axis = 0, inc = 0.0001) (Mach4GUI)
2017-12-29 13:33:33.060 - API: mcJogSetInc(inst = 0, axis = 1, inc = 0.0001) (Mach4GUI)
2017-12-29 13:33:33.060 - API: mcJogSetInc(inst = 0, axis = 2, inc = 0.0001) (Mach4GUI)
2017-12-29 13:33:33.060 - API: mcJogSetInc(inst = 0, axis = 3, inc = 0.0001) (Mach4GUI)
2017-12-29 13:33:33.060 - API: mcJogSetInc(inst = 0, axis = 4, inc = 0.0001) (Mach4GUI)
2017-12-29 13:33:33.061 - API: mcJogSetInc(inst = 0, axis = 5, inc = 0.0001) (Mach4GUI)
If I attempt to jog when the increment is lower than 0.001 I get this:
2017-12-29 13:35:10.582 - API: mcJogSetInc(inst = 0, axis = 0, inc = 0.1000) (Mach4GUI)
2017-12-29 13:35:10.582 - API: mcJogSetInc(inst = 0, axis = 1, inc = 0.1000) (Mach4GUI)
2017-12-29 13:35:10.583 - API: mcJogSetInc(inst = 0, axis = 2, inc = 0.1000) (Mach4GUI)
2017-12-29 13:35:10.583 - API: mcJogSetInc(inst = 0, axis = 3, inc = 0.1000) (Mach4GUI)
2017-12-29 13:35:10.583 - API: mcJogSetInc(inst = 0, axis = 4, inc = 0.1000) (Mach4GUI)
2017-12-29 13:35:10.583 - API: mcJogSetInc(inst = 0, axis = 5, inc = 0.1000) (Mach4GUI)
2017-12-29 13:35:12.054 - API: mcJogSetInc(inst = 0, axis = 0, inc = 0.0100) (Mach4GUI)
2017-12-29 13:35:12.054 - API: mcJogSetInc(inst = 0, axis = 1, inc = 0.0100) (Mach4GUI)
2017-12-29 13:35:12.054 - API: mcJogSetInc(inst = 0, axis = 2, inc = 0.0100) (Mach4GUI)
2017-12-29 13:35:12.054 - API: mcJogSetInc(inst = 0, axis = 3, inc = 0.0100) (Mach4GUI)
2017-12-29 13:35:12.054 - API: mcJogSetInc(inst = 0, axis = 4, inc = 0.0100) (Mach4GUI)
2017-12-29 13:35:12.054 - API: mcJogSetInc(inst = 0, axis = 5, inc = 0.0100) (Mach4GUI)
2017-12-29 13:35:15.342 - API: mcJogSetInc(inst = 0, axis = 0, inc = 0.0010) (Mach4GUI)
2017-12-29 13:35:15.343 - API: mcJogSetInc(inst = 0, axis = 1, inc = 0.0010) (Mach4GUI)
2017-12-29 13:35:15.343 - API: mcJogSetInc(inst = 0, axis = 2, inc = 0.0010) (Mach4GUI)
2017-12-29 13:35:15.343 - API: mcJogSetInc(inst = 0, axis = 3, inc = 0.0010) (Mach4GUI)
2017-12-29 13:35:15.343 - API: mcJogSetInc(inst = 0, axis = 4, inc = 0.0010) (Mach4GUI)
2017-12-29 13:35:15.343 - API: mcJogSetInc(inst = 0, axis = 5, inc = 0.0010) (Mach4GUI)
2017-12-29 13:35:19.824 - API: mcJogIncStart(inst = 0, axis = 0, inc = 0.0010) (Mach4GUI Button)
2017-12-29 13:35:19.824 - Attempt transition from "Idle" on event "Jog" Axis.cpp:564
2017-12-29 13:35:19.824 - Signal id 1127, (Jog Enabled), changed from HIGH to LOW.
2017-12-29 13:35:19.824 - S_IDLE_on_exit
2017-12-29 13:35:19.824 - ACTION_start_jogging
2017-12-29 13:35:19.824 - S_JOGGING_on_entry
2017-12-29 13:35:19.831 - Attempt transition from "Jogging" on event "Stop Jog" Controller.cpp:1379
2017-12-29 13:35:19.832 - S_JOGGING_on_exit
2017-12-29 13:35:19.832 - S_FILE_RUNNING_stop_jogging
2017-12-29 13:35:19.832 - S_IDLE_on_entry
2017-12-29 13:35:19.832 - Signal id 1127, (Jog Enabled), changed from LOW to HIGH.
I can't figure out what is going on here. I have a PMDX 416 controller, Windows 10
Thanks
-
Forgot to mention I have Mach 4 build 3481 and latest PMDX software. :'(
-
What are your steps per for the axis showing the error? You can not move in partial steps. Only whole steps can be taken. So, the result is most likely the math of putting you as close to requested as possible.
-
My X and Y are set to 1/8 and my Z is set to 1/4. MY X and Y are on a belt and my Z is on a screw.
What is the message "Attempt transition from "Jogging" on event "Stop Jog" Controller.cpp:1379" indicate? Where can I find a listing of all the error messages?
The actual error is extremely small considering what I use my machine for so it probably doesn't matter but it is curious.
-
My X and Y are set to 1/8 and my Z is set to 1/4. MY X and Y are on a belt and my Z is on a screw.
This doesn't make sense. Your X and Y axes are set the 1/8 steps per inch (or mm)?? When you go to the Configure->Mach menu, click on the "Motors" tab and select "Motor0", what does the "Counts per unit" say? Likewise the other motors.
For "very small" jog increments, if you don't get any motion it means that the jog increment is smaller than one step as entered in the "count per unit" field referenced above. For example, if you have 100 counts per inch, each step pulse will move 0.01 inches. If you set the jog increment to 0.0001 inches and try to do an incremental jog, you will get no motion until you jog 5 times (I think the PMDX plug-in rounds fractional motion up starting at 1/2 of a step). And then every 10 incremental jogs.
Likewise, if you set the "counts per unit" to 400, each step will be 2.5 thousandths of an inch. If you start at zero and command a move to 0.008 you will actually end up at 0.00075 because that is as close as you can get with that step size. If the DRO is displaying 3 fractional digits, it will round up (I think) and show 0.008. If the DRO shows 4 fractional digits it will show the full 0.0075.
What is the message "Attempt transition from "Jogging" on event "Stop Jog" Controller.cpp:1379" indicate? Where can I find a listing of all the error messages?
This is not an error message. It simply says that the Mach4 core is attempting to change out of the "jogging" state, because it received a "stop jog" event (i.e. the motion planner told the core that it was done generating the motion).
-
@Brotenc
Have you figured out this error problem?
I get a similar thing and don't know why it acts this way. Feed screw is 5mm per turn, so for one inch (25.4/5) = 5.08 turns, times 3200 steps per rev
I have steps per unit set to a whole number (16256) and when I jog one unit it goes to .9997. Jogging negitive one unit does not return to zero, like .0002.
I was told that digital control was exact, but this acts like it's converting to parsecs and rounding it off, then reconverting to inches and getting an accumulated error.
There is no feedback in the actual motion, so mach4 is basically telling me it's not going to do 16256 steps when told.
-
Hi Roaster,
the position/velocity/time data provided by Mach for its trajectory planner is INTEGER. It can move
15432 steps or 15433 steps, but not in between.
One step at 3200 steps/rev with 5mm pitch screw is 1.5um Are you telling me that your machine is accurate enough
to indicate 1.5um? If so Hass and Mori Seiki had best watch out, a real machine builder ins in town!
Craig
-
Hi Craig
It's not the machine, it's Mach4 not jogging one unit.
I tell it to jog one unit and it does something else, as indicated by the dro.
As I stated, my steps per unit is a whole number, so what's up? Why would it do something other than move one unit worth of steps?
-
I tried a few things and the dro error is less with low acceleration rates and worse with high acceleration.
This means I can work around it, but something in the acceleration math is interfering with the delivery of the correct number of steps per unit. This decreases machine accuracy, but I guess close is good enough.
-
Hi,
OK there are a few things you can try. The first thing to realise is that when you engage microstepping, in your
case 16 microsteps per full step for 16 X 200=3200 steps per rev that it doesn't really work that way.
There have been a number of disscussions on the forum and other places but the short story is that that the torque
between adjacent microsteps is very low and cannot be relied upon to step that one microstep. In fact its reasonable
to consider a two phase stepper as having a resolution of 200 steps/rev and can almost always be relied on to
do 'half' steps for 400 steps/rev. Microstepping beyond half steps don't in reality offer you any better resolution,
what they do offer is smooth motion.
The history goes that astronomers first proposed the use of microstepping, who knows they may have been hoping for
better resolution, they didn't get it, but what they did get was 'smooth' and that suited their telescopes very well.
For the purpose of your experiments you should switch off microstepping and run at full steps. Do your measurements and see
if they match your expectation. You may try half stepping as well, I think you'll be impressed.
The 'effective resolution' of a two phase stepper is 400 steps/rev or with a 5mm ballscrew a linear resolution of 0.0125mm
or 12.5um. Pretty good for a hobby machine. You can quote 3200 steps/rev or 1.5625um per step, you'll impress a
newbie but any CNCer will roll there eyes and think 'tosser'.
Craig
-
do you even read the post? This is the MACH4 dro showing the error. I'm not trying to impress anyone with 1/16 excitation, I'm trying to meet the thumbrule for 5000 steps per unit. The Mach4 thumbrule.
In my case 1/8 just didn't work, but 1/16 does. For whatever reason. The machine isn't even built yet.
THE PROBLEM IS THAT MACH4 DOES NOT SEND THE CORRECT NUMBER OF STEPS PER UNIT.
It's supposed to be a digital control system, but it's doing fuzzy math figuring number of steps per command. The steppers are doing exactly what is commanded. They are not slipping, skipping or stalling.
Mach4 is not requesting the correct number of steps to achieve one unit.
GRBL on an Arduino is more precise.
-
Hi,
yes I did read your post, did you read mine? Try full steps, ie NO microstepping.
That would correspond to a steps per value of 40 steps per if in millimeters or 1016 steps per if in inches.
My machine is accurate to 5um and I can operate it all day without it deviating from its programmed position
by more than 5um. Is that accurate enough for you?
Craig
-
OK I did try 1:1, and the error is worse. Jogging one unit five times gives 4.985" dro change. The motor tuning is set to 1016 steps per unit in mach4 config. Pretty simple. 5.08 x 200.
Jog an axis one unit. Mach4 does not send 1016 steps. The digital read out in mach4 shows less than an inch travel. I expected it to be precise.
Why does mach4 not send 1016 steps when told to jog one unit? Isn't precision the target here? How does it not follow a command?
I don't have a pulse counter hooked up to it yet, but it is possible it's sending 1016 steps and it's the dro that doesn't count right.
-
Hi,
not sure whats going on. Mach doesn't send pulses, it sends numbers, its up to your motion controller
to produce the right number of pulses.
What motion controller are you using?
If mach were faulty there would be many people who suffer this problem but there isn't. Thats not to say that
your copy could be faulty but it seems unlikely.
It could also be your steppers but more likely the drivers. Is it possible to drive two drivers with the same signals,
if they behave identically you could pretty much say the the steppers/drivers are OK.
That leaves the motion controller. I can't really think of anyway to test short of substituing a known good one.
Craig
-
I get you, but like I said, I'm not measuring the steppers travel or anything. This is strictly an error showing up on the digital readouts of Mach4 Mill application.
It gets worse if I raise the acceleration value, and it got worse when I changed from 16256 steps per unit to 1016.
To me that means the math formula for determining what to send to the motion controller is fuzzy. And yes, everybody should be seeing it, based on what I have here.
The original poster of this thread brought it up first, so call it a known problem.
The fact that the error changes with motor tuning specifics would seem to indicate that the math could be improved. In the interest of digital precision.
I'll settle for this kind of accuracy, but it just isn't right, analy speaking.
My motion controller is a piece of work, I can tell you, but I'm not able to measure the output yet.
Hold on. What you said about the software not sending pulses, it sends a number. So what drives the dro values? Is it feedback from the motion controller??
-
Hi,
if you are not measuring an axis travel distance how do you know Mach is sending wrong info?
May I suggest to start with use MDI at a very slow rate, I guess you use inch units so;
g1 x1 f5
followed by;
g1 x0 f5
ie just sending the x axis back and forth 1 inch at 5 in/min. If that works ok up the speed. I think the trajectory
planner in Mach, which is in itself quite an advanced breed, incoperates max accelerations and velocities when it plans
a move.
It is not my experience that anything about Mach4 is fuzzy, thats more a description of me rather than Mach.
Craig
-
see above post re the feedback. It could be the f ing motion controller.
-
Hi,
no Mach is not a feedback controller.
It can read MPGs and encoders, the motion controller actually receives and counts the pulses and sends the numbers
back to Mach. Mach can display them if you wish. What it won't do, or at least do well, is alter the output to a motor
to cause the encoder to go to a specific place.
Unless you have encoders hooked up then the DROs are a reflection of whats going on inside Mach.
Are you using work coordinates or machine coordinates, machine coordinates are most direct and preferred for testing
despite being a little confusing.
Craig
-
Hi Craig
I'm a total noob at this and just learning the system.
I'm building a machine and just now setting up the control box and configuring the motors.
I expected that giving a command to move 1 inch would cause the dro to go to 1.0000. It does not. It's always a bit less, and with the steps per inch set to 1016 it changes to .9995" It's cumulative and after a couple jogs it's off pretty good.
If it's not reacting to feedback from the motion controller then mach4 is not following orders.
I have to get the motors on the rig and do some motion and measure it now, just to see what's real.
I'll get back when I have data.
Thanks for your help
Mike
-
Hi Mike,
that is unusual. I use metric but if I MDI 100mm say, the DRO goes 100mm and my actual machine is that close
to 100 mm Ii can't measure the error with verniers.
If you have metric basllscrews why use inch native units?
Craig
-
Hi Mike,
just had another thought (funnily enough it wasn't that painful either!), just for testing purposes set both
your native and preferred units to millimeters and try the same experiments. I'm wondering if it a rounding
error in the conversion between metric and imperial.
Certainly can't hurt to try.
Craig
-
because it converts in whole numbers. I could use either metric or imperial.
I ended up setting the drivers to 1:2 and 2032 steps per inch vel 60 and acc 5
thing is, I gave it a command string instead of jogging and the results at the dro were perfect.
g01 x4 f20 g01 y2 g01 z1
g01 x2 f20 g01 y1 g01 z0 and the readouts finished at 2.0000, 1.0000, and 0.0000
I couldn't ask for more.
Why the jog function is off a bit I don't know, and I'm not caring so much any longer.
-
Hi,
kool your making progress. It would appear that you jog increments are such that they don't land on whole numbers and therefore subject to rounding errors.
Most importantly Mach will execute Gcode and be able, at least according to the DRO, to drive to the right location. The challenge now is to see to it that the
motion controller and axis drives follow suit.
Craig
-
This is a known issue that affects some motion controllers in the current build (3481). It has been addressed in later builds (I tested with 3633 and the issue was gone), which you can download and test here: ftp://ftp.machsupport.com/Mach4/DevlopmentVersions/
When we are ready to release a locked-down version, it will be available on our website and I will update this thread as well. If the issue persists in other versions, there is something else going on that we'll need to tackle.
Happy CNCing!
-Bryanna
-
This is a known issue that affects some motion controllers in the current build (3481). It has been addressed in later builds (I tested with 3633 and the issue was gone), which you can download and test here: ftp://ftp.machsupport.com/Mach4/DevlopmentVersions/
When we are ready to release a locked-down version, it will be available on our website and I will update this thread as well. If the issue persists in other versions, there is something else going on that we'll need to tackle.
Happy CNCing!
-Bryanna
Good news!!!
In fact, I have a similar issue too. I use ESS 216 + Mach4 3481.
Hope to meet the officially upgraded version soon. ;)
-
I think I know how to fix it.
Send a command for G0 x1.
I know Mach4 is very complex, but it's a little odd anything other than that would happen. Hence my comment about fuzzy math. Giving direct commands to move gives perfect DRO results.
In my testing the DRO result after a jog changed with accelleration settings changes. That should not be. Unless they've got something like Bernoulli's equation providing the result to send. KISS?
-
I have a similar problem, which is a pain for touching off manually. Both the DRO's and actual machine movement is less than that commanded by either Gcode from the MDI or jog - so I don't believe it has anything to do with the controller.
Now running version 4.2.0.3804 (but the problem also existed in versions from May and Sept 2017)
Screenset: stock wx4 from latest download, and in customized wx6 from ~Sept 2017
As this is bugging me, I've done some more tests today to quantify the problem. The table below shows the error for 5 separate executes of a line of gcode via the MDI ie G54 G91 G0 Zstep. For example, if Z0.001 is commanded 5x, the DRO and the machine move in uniform steps to 0.005 (so DRO/5X = 1.000). Same for 0.002mm, but not so for increment values from 0.002-0.098mm. For step sizes above 0.098 mm everything is perfect. Odd, especially as ridiculously small steps work OK.
step
(mm) DRO @ 5X DRO/5X
0.001 0.005 1.00
0.002 0.01 1.00
0.003 0.01 0.67
0.004 0.015 0.75
0.005 0.015 0.60
0.006 0.02 0.67
0.007 0.02 0.57
0.008 0.02 0.50
0.009 0.025 0.56
0.01 0.03 0.60
0.09 0.42 0.93
0.098 0.49 1.00
0.099 0.495 1.00
0.100 0.5 1.00
The jog command will not work at all for step sizes below around 0.05mm, meaning that I always have to use an MDI line of gcode to execute fine jogging.
Note that in all cases DRO changes are accurately reflected in axis movement (using a Z-setter, 0.01mm divisions).
I realise that 0.001mm movements are totally meaningless for machining, but my router/engraver will move 0.001mm on and off the 3D probe repeatedly (Z axis only - so no backlash issues) - despite the use of 1/25th microstepping.
Any ideas please? This is really bugging me.
Best regards,
Louis
-
A quick followup note. Decided to try the above tests at much lower speeds. Previously used G0 or G1 F100. I've found that the DRO error disappears for feeds of 75mm/min or slower - so G54 G91 G1 Z-0.05 F75 gives the correct DRO change of -0.05mm, but using F76 gives only 0.03mm.
However still no luck with fine jogging, even with a jog speed down to 1%.
Louis