Posts made by fcwilt

@Duncan

To activate tool zero you need a T0 command - you can put it after the other tool commands in config.g if you want.

Frederick

@Leonard03 said in G30 during G28 issue:

I'm referring to G1 H4 command. It was better to measure from let's say X80 to the endstop?

I'm not sure what you mean by "measure".

Frederick

@martin7404

I re-read all of the posts and that seems to be the case M92 only, no M350

Frederick

@Leonard03

Just FYI - G92 is not a movement command, it merely sets the current axis position to whatever value present.

So G92 X123 Y456 sets the logical X position to 123 and the logical Y position to 456.

Frederick

@FelixUCF

I seem to recall there is a jumper that determines what appears on that pin.

Did you check it?

Did you check

@Triet

Is moving away from the end-stop sensor 5mm enough to deactivate it?

If the end-stop sensor is activated a G1 H1 move will be skipped over.

Frederick

@sebastianwac said in Homing X triggers before reaching endstop:

G91                ; relative positioning
G1 H2 Z10 F3000    ; lift Z relative to current position
G1 H1 X-1205 F3000 ; move quickly to X axis endstop and stop there (first pass)
G1 H2 X5 F3000     ; go back a few mm
G1 H1 X-1205 F1500 ; move slowly to X axis endstop once more (second pass)
G1 H2 Z-10 F3000   ; lower Z again
G90                ; absolute positioning

One small observation. The G1 H2 X5 F3000 command - you don't need H2 since the preceding G1 H1 X-1205 F3000 will have marked the X axis as homed and at the point plain G1 moves will work as expected.

Is it possible that the cable length (approx. 5 meters) is introducing additional resistance, making the controller interpret the switch as open?
Or could it be due to electrical noise from nearby signal or motor cables?

5 meters is a lot. It could be picking up noise.

Is the wire twisted or shielded? Is the end-stop device a simple switch, like a micro-switch? Is it normally closed? Normally closed is the best as the signal wire is connected to ground, making it resistant to noise.

Frederick

@dc42

Where can I find the versions 2.2.1 and 2.3.0 for the WiFi server?

Thanks.

Frederick

@Leonard03 said in G30 during G28 issue:

I feel really sorry... Looking at commits on GitHub between those dates, there were many and substantial changes in RRF.. I feel sorry because only now I came across this bug (?) after so much time

There was a time when I would install beta or rc firmware - but no longer - I have things to print.

So I am still using 3.5.4.

Frederick

@dc42 said in Mini 5+ Wifi Problem Revisited:

We are aware of an issue whereby in some machine configurations running firmware 3.5.x the object model becomes too large for both DWC and PanelDue to fetch it simultaneously. One of the symptoms is dropped network connections. In version 3.5.1 of PanelDueFirmware we made some changes to mitigate this, and in RRF 3.6 we made some more.

Both of the PanelDue units are running firmware 3.5.1.

I am not running any version of RRF 3.6 as I do not install alpha/beta/rc firmware.

I will update the WiFi firmware to 2.2.1 and see if changes anything.

If you can get 2.3.0 to me I will test that as well.

Thanks.

Frederick

@Leonard03

Good job.

Very strange.

I'm wondering at this point if there is a problem in the firmware.

If I was using RC firmware (which I never do) I would resort to the last stable version prior to the RC version and see if the problem goes away.

Frederick

@Leonard03 said in G30 during G28 issue:

I don't understand your question, I apologize. Plese give me a little more details so I can try out

Let's assume the current Machine Position is X=20 Y=20.

To verify this you will need to check in the Object Model as the DWC user interface shows User Position, not Machine Position.

Then execute the G30 at that position.

Then check the Machine Position to see if it has changed.

Frederick

@jimakron said in Trouble firing 45 watt TTL Laser on "output6_buff" PMW:

Given the IN pin accepts 0-5 VDC or PWM I suspect that you need to connect a resistor (1K should be suitable) from the 5V_EXT pin to the out6_buff pin.

Frederick

@Leonard03

Thanks for the reply.

Since you have a Z end-stop homing Z first means you have no need to use G1 H2 commands.

Why not use the simplest code possible?

I understand it may be satisfying in some sense to optimize homing by coding homeALL.g discretely but that again makes the code more complicated. Also it means if you find a flaw in homing X or Y you have to makes changes in multiple places.

In any case it's your printer to configure as you please, just offering advice based on many years of programming experience and several years for using Duet hardware.

Now back to the original issue.

If you don't set the Z=0 Datum in the homing code, it all homes correctly?

When you set the Z=0 Datum in some separate code is the X position the same before and after executing the code?

Frederick

@dc42 said in Mini 5+ Wifi Problem Revisited:

@fcwilt have you tried release 2.2.1 of the WiFi firmware?

We also have a draft release 2.3.0 which I can make available to you if you would like to test it.

Currently I only have two printers up and running, both using 6HC boards.

Both are showing version 2.2.0.

I can easily setup a Mini on my workbench but it would have no hardware connected.

I would be happy to try both 2.2.1 and 2.3.0.

Even using the Ethernet connection on the two 6HC based printers is leading to occasional lost connections.

Frederick

@sebastianwac

Well one possible answer is that the X homing command simply isn't moving as far as you think it is going to move.

We need to see the actual homing code for X.

Also, have you verified that the X axis steps-per-mm setting is correct?

Frederick

@Leonard03

One thing to remember is the some errors in config.g can cause the processing of config.g to be cut short.

I dealt with this by tracing the processing of config.g to make sure that it ran to completion:

At the start of config.g I have this local variable declared:

var trace = "config_trace.txt"

Then I create the first line of the file:

echo >{var.trace} "trace begun"

Then I add additional lines as seem appropriate at appropriate locations:

echo >>{var.trace} "network config"

echo >>{var.trace} "motor config"

Finally at the end of config.g I have this:

echo >>{var.trace} "trace done"

It's not much work and can save time in the long run.

Frederick

@Leonard03 said in G30 during G28 issue:

Yes, is there, so why not use it When homing Z I lower the gantry until that switch is triggered and then do a G30 in the center of the bed.

Using it makes perfect sense.

What is odd, at least to me, is that your homing code is written as if there is not a Z end-stop. Those G1 H2 Z# commands are not needed if you simply home Z first and leave it at a safe position for then homing X and Y.

Now is is just my personal preference but I forgo the minor optimizations that can be done in homeALL.g by just invoking the individual homing routines:

M98 P"homeZ.G"
M98 P"homeX.G"
M98 P"homeY.G"

One other minor difference is that I don't set the Z=0 Datum during homing but only:

• when creating a height map
• when loading a height map
• when starting a print

Doing this ensures that any possible variations due to thermal changes are taken into account.

As to the original issue I am still stumped - something is being overlooked I imageine.

Frederick

@awitc

Well the docs for M226 say it is to be used from within the GCODE file being printed:

Use M226 when a pause is required in the GCode file being printed, for example to pause after a particular layer has completed. It waits until all the moves in the queue have been completed.

I think M25 is the correct code but if the docs are correct it doesn't stop the print, just pauses it.

The daemon code is run every 10 seconds but in your case I have no idea what is going to happen since you don't allow the while loop to exit.

Perhaps @dc42 will notice and address your issues.

Frederick

@awitc

I don't think M226 is the command you want.

And where are the bits of code that exit the while loop?

Thanks.

Frederick