Door Open Switch and LED´s

[CR3D]

So now here is the answer from Roland Littwin .. the programmer of Repetier... The answer in the picture is in german... here the translation from the mail:

---

<response type="requestPause" string="true">//\saction:pause\b\s(.)</response>
<response type="continuePause">//\saction:resume\b</response>

Recently there was a discussion with the Marlin developers and Gina from Octoprint to correctly implement the official solution. As a result, you can
// action: break
send from the firmware to tell the host to pause. (RequestPause: The reason is the solution only Repetier host / server understand, therefore, if it is officially implemented better you use action commands.)
// action: resume
would make the host talk again.
This was wrong in older server versions because the description was too spongy. But with the last version it should work correctly. Marlin is still echoing: before that what is accepted by the server.
So if the sensors are connected to the printer you have to bring the firmware only to send this. How does David know who wrote the firmware? Logic would then perhaps if sd pressure as always else host ask for break. Whether he also installs a continue or if you should always explicitly click on the server afterwards is then a matter of taste.
Hope that helps to solve it on the firmware side.

---

In my opinion, a break function is enough. that would continue in my opinion then synonymous over the server suffice.
Is it possible to add this command ... ?

Thanks a lot!!!

And about Duet interface:

I try to use it more in the future, but companies often like a clear and simple design, file management on the server, display of files etc ... actually things that are less related to printing, but unfortunately it is. ...

[dc42]

To do this properly, the GCode sender would need to tag each line with a file address or line number or similar (line numbers are a standard but optional feature of GCode) and RRF keep track of them. Then in the resume message, RRF would tell the sender which line to resume from. That way, RRF can do an early pause, throwing away moves that have been queued but not yet executed - just as it does when you print from SD card.

Without this, RRF will need to send the pause response, complete all the moves in the queue, and complete any additional moves that the host has already send or is in the process of sending (otherwise it won't be able to read the resume command from the host). So the pause will be delayed significantly.

It really is much simpler to print from SD card, also that way you are not dependent on a host computer to send the GCode stream fast enough - which is a problem not only with a Windows host but, according to reports, even when using a dedicated Raspberry Pi as the sender.

[CR3D]

Yes I know that SD would be much easier... i will focus this in the next time... but for other Machines a USB Print is needed.
The delayed pause is ok... I know this...

A resume isn´t needed....

Would adding the pause function possible?

[dc42]

What is the reason that you want the Duet to be able to initiate the pause? Is it because the reason for the pause is out-of-filament, or something like that? If not, why can't you initiate the pause from Repetier?

[CR3D]

Yes on the one hand out of filament, but above all the opening of a door. Even if there is a delay, it is better if he still pauses.

[dc42]

@cr3d, try setting up a trigger macro (see M581) to run when when the door is opened. In the macro file use this command:

M118 P1 S"// action:pause"

That will send the string to USB.

[CR3D]

@dc42 said in Door Open Switch and LED´s:

M118 P1 S"// action:pause"

@dc42 -> you are the best!!!!!! Everything is running now!! Thank you so much!