Hello Guest it is July 13, 2020, 05:32:22 AM

Author Topic: Does G28.1 always instantly reset a homed axis to zero? Can it be made not to?  (Read 1856 times)

0 Members and 1 Guest are viewing this topic.

I'm hoping to home (or is reference? still not sure of the terminology) X and Y axes before and after a run using G28.1, and read the X and Y DROs into variables in a macro, to compare the 'before' and 'after' values, so as to flag up any lost steps during a run. Obviously the 'before' values (after initial home/reference) will always be zero, and the final ones will also be zero if no steps were missed.

The problem is, sometimes the value of the DRO changes to zero instantly as the home switch trips, sometimes it remains at whatever value it had, ie doesn't reset to zero. For instance, this happens if I write a G28.1 command from the MDI line, and sometimes in gcode running from a gcode file. For that reason, I tend to write 'G92 X0' after a G28.1 Xx line.

Is G28.1 supposed to always reset a homed axis to zero the instant it's home switch trips? For my purposes it would be handy if it didn't.

Is there a way to make sure it doesn't reset to zero, so I can insert a call (in the line after the G28.1 command) to a macro that reads the DRO? Or is a different command needed for that?
Alternatively, has anyone successfully used any other method for logging missed steps?

Offline RICH

*
  • *
  •  7,411 7,411
    • View Profile
Quote
I'm hoping to home (or is reference?still not sure of the terminology)

The controlling software, namely Mach3 does not know the actual physical location of an axis until told. The controlling software does keep track of how the axes move  and the basis is it's owne  value. When the axes have been moved to some location that your happy with to have as a  reference, and tell Mach, then you have referenced the  machine.

Now home is another location which can be anywhere but is usualy user chosen for convenience. Home can also be the referenced position.

Hopefully  that covers it from a high level for basic understanding.



Quote
Alternatively, has anyone successfully used any other method for logging missed steps?

Why even bother looking  for them? What do you consider correct?
DRO is position of the axes and is correct if the "system", i repeat "the system", is perfect. There is no such animal! We did test thats showed how adjusting the timing belt tension can have an affect on posiiton. We ran controlled tests and conpared pulse steams to an accuracy of 1 part in  29,000,000. Special equipment used both for the electronic and mechanical items. If you loose  or gain motion for say 20000 steps per inch, then one step or pulse would be 0.000050" and that my friend is rather difficult to find even with a caibrated standard and 1000x microscope!

FWIW,

RICH
« Last Edit: September 19, 2017, 06:22:20 PM by RICH »
Thanks for clearing up the difference between home and reference, that makes sense now.

As for logging missed steps:-

A couple of months ago I was running the machine (which is basically a large format printer), left the room for 10 minutes, then continued to run another 20 odd files of Gcode on the machine, on the same workpiece. When I eventually checked the results, I found it had happily traversed an area of the workpeice where it was not suposed to go. Took me 5 days of checking to discover that what had probably happened was that the net curtain in the open window by the machine had temporarily caught in the gantry belt... and I took another 2 days to rerun all the code on a fresh workpiece. Thankfully, as the files in this instance were much smaller than usual, I didn't write off another entire week of working time.

If I'd have had a message, or a log entry to flag this up, I'd have known to stop the machine, throw away the damaged print, look for the source of the problem while the evidence is still fresh, and then start again, thereby not wasting days and days completing an already ruined peice of work.
Hi,
there have been any number on conversations on the forum about being able to detect lost steps and even more about correcting them if they occur.
To my knowledge without some sort of encoder its not possible or at least realistic to detect lost steps and with Mach alone almost impossible to
correct them.

In fairly recent times some manufacturers are making closed loop stepper drives. They have an encoder and the drive can, at need, add or subtract pulses
to have the stepper maintain its position with respect to its programmed position. They are somewhat more expensive than normal and despite the advertising
hype, theres plenty of that, are pretty good. The gold standard is of course a decent AC servo and matching drive, great speed, resolution and accuracy
and if something screws up and it gets out of whack it generates an error which will stop the machine. Depending on the size of your machine a servo
and drive might cost $500. Is $1500 a worthwhile investment to avoid the situation you described about a screwed up job?

Craig
My wife left with my best friend...
     and I miss him!

Offline olf20

*
  •  317 317
    • View Profile
Mach3, Atlas Knee Mill, 4th Axis, VcarvePro, ESS, Super PID.
Been Heating with corn since 1998
Thanks for the replies, I have looked into motors with fitted encoders, and they would certainly solve the problem of missing steps, but they are all beyond what I can afford.

The main gist of my question relates more to the behaviour of G28.1;
For instance, if this line appears in my gcode:-

G28.1 Y40

the DRO reads down from 40 until the home switch is triggered, then instantly reads 547.0000.
If I film the DRO, and slow the film down to maybe 3 frames a second, I can see what value the DRO was showing the instant the switch was triggered.

THAT is the value I want to be able to read into a variable in a macro, as it tells me how far the machine travelled in order to get to the switch.

What I would like to know is, how can I do something just like G28.1, but without it 'jumping' to the value 547 or whatever when the switch is tripped.

I know I can do 'G31 Y0', if my Y home switch is also configured as my probe, but I already use a different switch as my 'probe', with the Z axis. And as far as I can tell, mach only allows you to configure one port/pin as a probe.
« Last Edit: September 20, 2017, 12:17:27 PM by moorea21 »
Hi,
Mach4 has several probe assignments, G31.1, G31.2, G31.3 etc.

Craig
My wife left with my best friend...
     and I miss him!
I've searched for 'G31.1' here and on google; nothing came up. Where can I look for more on this?
Hi,
multiple probe inputs are a Mach4 feature. Probing is in large part done by the motion control plugin, Warp9 have added multiple probe input
capability to the ESS plugin in the last few months only.

Craig
My wife left with my best friend...
     and I miss him!
Okay, thanks.

Without upgrading to mach4, I've come up with an idea that could allow me to probe on 3 axes in mach3; IF it works....

Basically, it would involve sharing the switches inputs across 2 pins (ie the pins configured as 'home' and 'probe') so that the same switch could (in theory) be used for homing X and Y, and probing X and Y.

See picture (attached, I hope) for a clearer explanation.

Can I use a setup like this? Or is it going to cause confusion to mach?
« Last Edit: September 20, 2017, 03:43:39 PM by moorea21 »