G30 XY coordinates - for probe or for nozzle?

dc42

The G30 coordinates are where you want the probe to be, not the nozzle. You need to set up the probe offset in G31 so the firmware knows where to command the nozzle.

r123

Now, mysteriously, this correct behaviour has returned.

Have no idea why it stopped working when did not edit G31.

Thanks!

r123

An update.

Have just had an hour of hell in which, initially, G30 and G29 went haywire (they both seemed to have lost a sense of where they should be working on the bed) and then it became impossible to even run HomeX or Homeall.

You can imagine that between each attempt there was an EMERGENCY STOP or a POWER OFF and yet the behaviour continued.

If I tried to perform HomeX the hotend would move in the Y direction (not X) and flap back and forth a couple of times before stopping.

Needless to say became quite discouraged but couldn't find anything further to reset (and have no M501).

One change could remember making recently was adding the R (R0.7 for the BLTouch works great!) parameter to M558 in config.g. In bed.g had another copy of M558 but WITHOUT the R parameter. When I added the R0.7 to the M558 in bed.g then everything started working correctly. This might just be a coincidence since would have had to homeX before executing bed.g and was unable to homeX before and had restarted many times.

In any and all cases there is something odd going on and it seems to involve functions like G31, M557, M558, G28, G29..... It manifests itself in the Duet losing sense of orientation, of X, of Y and, if previously homed, of position itself.

firmware 2.03 (2019-06-13b2)
Railcore2 ZL

dc42

If you find a particular sequence that causes this sort of problem, please let me know. I have one other report that suggests there might be memory corruption occasionally when G29 is run, but nothing definite yet.

r123

@dc42 Is there a reset procedure? I thought the Duet was a tabula rasa at reboot and loaded everything from config.g but this simply didn't work / was not sufficient. Would feel much more comfortable about experimenting if knew I could get out of it next time without a lot of blind trial and error.

dc42

Yes it loads everything from config.g (and config-override.g if you have a M501 command in config.g).

r123

Then it's a mystery why the above problem persisted through several reboots and several power cycles. Before going away.

r123

After a period of everything working great having more G30 misery today.

My bed.g is as below and ordinarily runs no problems.

Since an hour or so ago, whenever I run the third and final G30 in the sequence, seemingly the WRONG leadscrew starts turning repeatedly and the bed become skewed necessitating an emergency stop.

Basically I've been restarting, performing HomeAll, then running bed.g.

Sometimes the first time I run bed.g it's fine, but then the second time it goes beserk. Sometimes it fails on the very first run.

All very odd. Wish I knew what / how to reset to make this go away. Doesn't the M561 eliminate any previous transforms, anything that might cause the leadscrews to make independent moves?

ps all 3 Z motors are driven by a Duex5.

M561 ; clear any existing bed transform
G1 Z5 S2
M558 P9 X0 Y0 Z1 H5 F50 T6000 A5 S0.02 R0.7; larger dive height than config.g

G30 P0 X15 Y45 Z-99999
G30 P1 X15 Y260 Z-99999 ; was Y275
G30 P2 X275 Y150 Z-99999 S3
G1 X0 Y0 F5000 ; move the head to the corner (optional)

dc42

Which firmware version are you using?

r123

@dc42 Firmware 2.03

After making the post above continued to try different things for an hour or two.

Found that if I turned the printer off for a good amount of time (couple of minutes) would at least be guaranteed to be able to perform one round of bed compensation.

So in the end settled for turning the printer off 3 times to perform 3 compensations and get the bed nice and level. And then do some printing. At least was able to print with no problems.

Wish I had some idea what was going on. Very odd that rebooting was ineffective, that power down for a "while" behaved differently.

The details of the symptoms are perhaps not relevant, because earlier on in this thread (the last time everything unravelled) the printer was just doing seemingly random things. Like try to X home and it moves in the Y direction a bit, bounces off the endstop successfully, goes a bit further and then stops. Eventually all of this went away. But no ideas why.

dc42

@r123 said in G30 XY coordinates - for probe or for nozzle?:

@dc42 Firmware 2.03

After making the post above continued to try different things for an hour or two.

Found that if I turned the printer off for a good amount of time (couple of minutes) would at least be guaranteed to be able to perform one round of bed compensation.

So in the end settled for turning the printer off 3 times to perform 3 compensations and get the bed nice and level. And then do some printing. At least was able to print with no problems.

Wish I had some idea what was going on. Very odd that rebooting was ineffective, that power down for a "while" behaved differently.

The details of the symptoms are perhaps not relevant, because earlier on in this thread (the last time everything unravelled) the printer was just doing seemingly random things. Like try to X home and it moves in the Y direction a bit, bounces off the endstop successfully, goes a bit further and then stops. Eventually all of this went away. But no ideas why.

That does seem strange. Possibly a hardware problem?

r123

Hmm...

Not sure what would make one motor move inappropriately under certain circumstances. Perhaps noise on the SPI bus connecting the Duet and Duex stepper drivers causing bit-corruption such that a command for Driver 1 mistaken for Driver 2? Or "Up" misinterpreted for "Down"?

r123

Finally, after some time off, figured it out.

In various places had taken to reducing motor currents. For example in homeall.g had the following at the start of the script:

M913 X20 Y20 Z80 ; reduce motor power to 20% for silent performance (increased to 100% in Slicer print start script)

Whilst most of the time this worked fine, in some situations the lower currents were problematic and causes Ouija board like behaviour.

Phew.

Everything is currently at 100% and will reduce more judiciously in future.

r123

ps the "problem" crept up stealthily as parameters such as jerk and acceleration were gradually increased. Thus macros and commands which had worked previously began to produce erratic behaviours. Since most of the problems were on the Z mistakenly attributed it to the compensation mechanisms.