@dc42 Thanks, that works for out9 (obviously coupled with the Lasermode)
..for io2.out i made a simple look into the automatic macro... pling....

M571 P"nil"

and everything works as expected 😉

EVERYTHING i assigned in the Automatic Mode Macro needs to be freed up...

@mrehorstdmd

Very neat.

Frederick

@oliof

Discussion page.

@o_lampe said in New Wiki layout:

I've linked to specific sections of the old Wiki pretty often, will these links still work?

Yes.

It's usually a good idea to rehome Z or at least doa. single G30 probe at the center of the bed before and after the leveling. Before so that it has a good idea of where the bed is before probing the points. After because correcting the tilt can alter where the physical Z0 position is and doing another probe will re-establish it.

Hi @achrn

Good news!
Just to confirm you, I put the SSR + config.g line to activate an output and this way solved completely my issue.

No more fan noise during boot or when I reset/ emergency stop the printer. 🙂

Thanks again for your help.
Julián.

Here is a little test video, for information, I plugged the X's sensor into the Zprobe connector for testing and it works fine.

I still have to install the Zprobe sensor as soon as I receive it.

https://youtu.be/vkGkOMY7Mt4

Good day

@eminus you can do the following:

In the config.g file, use the M584 command to configure 6 axes, one for each motor. I suggest you use X Y Z U V W. Implement some sort of homing mechanism so that you can move each joint to a known position. You can use microswitches, optical or Hall sensors, or (if the mechanics is tough enough) motor stall detection. After homing all 6 joints, send G1 commands to the Duet from the Pi to control the joints.

Can you send M106 P# for each fan number and see if the results match expectations?

@loris https://wiki.fysetc.com/BIQU12864_On_Spider/

rotate both connector 180 degrees and swap them if this not works...

@aitor said in Unexpected resets:

if you think of something else to try, let me know.

If it happens often enough that you're pretty sure you can trigger it you may want to try testing with 3.4 beta.

@vrghost I've run that macro several times, using M98 from DWC, and it produces the same output each time. So I think this one is also fixed already.

Did you manage to create a file that causes all the memory to be used up?

Good morning @t3p3tony,

A pity, I hope they can add it soon

I'll have to do it manually for now

Thanks for the quick reply

Best regards

Thank you for your answers.
In the slicer its no problem so while printing the should be no collision because its not possible to place parts in that area then.
Its only the thing that for a "user" it would be possible to reach a point where the printhead will collide with a part of the printer.
It seems like to avoid that I have to waste the blue area as well.

I will have a look at this and decide what is more important for me.

If anyone else has an idea how it could work, I would of course be very grateful.

Regards!

@jay_s_uk

Thanks! That was the problem. My bad... I treated z the same way as y and x which is obviously wrong. 🤦

Thanks for pointing me into the right direction.... You saved my day.

Cheers, Chriss

@phaedrux

I will keep you guys up to date when I have that again.

Cheers, Chriss

@phaedrux - @ctilley79 - got me thru the hiccups of getting all the right services started and in the proper order.

We got the updates and packages down and running and dcs / dwc is live. Toolboard was on 3.4.oBeta3 - so I went all in there again. We'll see how she goes from here .

I have the hostname and machine name matching [ duet3/duet3 ] in pi / and config.g

So far things are working ... I neglected to save my macros and all my local dwc settings were gone too - but Im getting much closer - network drop outs are better atm as well.

Running on the new SD card 64 GB SanDisk Extreme - fastest they sold at Best Buy.

My pi/nix game is ever so slightly improving ...

If the disconnects continue ... will address and be back.

@fcwilt said in 3D Touch not deploying:

Perhaps verify the orange wire is property crimped and has continuity to the BLTouch.

Well, thanks for your time, but it appears that my issue was in fact, a ground plane( I plugged a buck converter in incorrectly) issue coupled with an intermittent connection at a solder joint, which were both issues that I had thought were fixed before, but they had reoccured.

@davidewen
First you should define a "filament-error#.g" macro, which is called at filament runout (# is the number of your extruder).
In this "filament error macro" you can create and set a global variable.
After setting the variable, add a blocking message (M291...)
You have to reset the variable after confirming the filament change.

Create a "daemon.g" file in the sys folder. Here you can check the variable and make your beeps.
eventually something like this...

while global.beep = true M300 S500 P1000 ; beep with 500Hz for 1sec G4 P1000 ; delay of 1sec