Klipper: Read Pins Scripting

[SergeyKrutyko]

I have a system witch one extruder & filament switching module.

Switching of the filament is realized by setting the logical state on the pins of RAMPS.

For example, 1.2 pins specify the filament number.
3 pin reports on readiness - that the filament is switched and new loaded

I fount klipper gcode command for set pin state. i dont fount command for read and condition logic.

Can I create a script that would expect this read 3 pin?

If 1, then wait.
If 0 - then continue printing.

Thank you!

[mcmatrix]

I have a system witch one extruder & filament switching module.

I am really interested in seeing pictures of your module.
Is it something similar that Prusa has?

For example, 1.2 pins specify the filament number.
3 pin reports on readiness - that the filament is switched and new loaded
I fount klipper gcode command for set pin state. i dont fount command for read and condition logic.
Can I create a script that would expect this read 3 pin?
If 1, then wait.
If 0 - then continue printing.

Klipper doesn't have such gcode scripting capabilities.
If you're printing via Octoprint then you can somehow control it with action commands.
http://docs.octoprint.org/en/master/features/action_commands.html#
In Klipper you may create a custom menu for your functionality to manually control it.
But you cannot make a gcode script in Klipper to fully automate this flow!
Maybe it's doable in Octoprint.

Currently, there's no gcode to read pin state.

[SergeyKrutyko]

mcmatrix, you right - this is analog of prusa mmu2 now it progress and i want solve this issue in advance.

In the original version of prusa it is implemented through the firmware.

How I see this solution in the klipper:

1. There is a tool selection command T and there is a mechanism for reassigning the command. It is necessary for me that when I get the tool T0 (T1, T2 ... T4), I run a script that, depending on the value of T, should set the states of some pins, for example:
   ......
   [tool_override]
   

   two system variables:

OLDTOOL and NEWTOOL

gcode:
G1 X0 Y0 F7200 ; homing
G1 E-50 F100 ; unload filament
IF NEWTOOL=0 ; select tool 0
SET_PIN PIN=toolcode1 VALUE=0
SET_PIN PIN=toolcode2 VALUE=0
IF NEWTOOL=1 ; select tool 1
SET_PIN PIN=toolcode1 VALUE=1
SET_PIN PIN=toolcode2 VALUE=0
IF NEWTOOL=2 ; select tool 2
SET_PIN PIN=toolcode1 VALUE=0
SET_PIN PIN=toolcode2 VALUE=1
;check for busy
WHILE GET_PIN PIN=toolstatus VALUE=1
....pause code....

resume printing

G1 E50 F100 ; load filament

....

[SergeyKrutyko]

may be made few tool overrides:
[tool0_override]
[tool1_override]
....
[toolx_override]

[SergeyKrutyko]

main problems is: how still wait when multimaterial switch module complete work

[mcmatrix]

main problems is: how still wait when multimaterial switch module complete work

Somebody has to implement new gcode command for Klipper.
gcode that will read and wait for pin state.
for example WAIT_FOR_PIN PIN=pin STATE=1
There's internal buttons module that can be used for pin state reading.

Similar to what marlin has
http://marlinfw.org/docs/gcode/M226.html

[SergeyKrutyko]

main problems is: how still wait when multimaterial switch module complete work

Somebody has to implement new gcode command for Klipper.
gcode that will read and wait for pin state.
for example WAIT_FOR_PIN PIN=pin STATE=1
There's internal buttons module that can be used for pin state reading.

Similar to what marlin has
http://marlinfw.org/docs/gcode/M226.html

yes as variant.... and need tool override feature or global T command override with internal variable with logic

[SergeyKrutyko]

WAIT_FOR_PIN PIN=pin STATE=1 is a good idea, but need two additional parameters

1. TIMEOUT - in seconds, to prevent the system halt
2. ERRCMD - for abort or pause printing

ex:
WAIT_FOR_PIN PIN=pin STATE=1 TIMEOUT=60 ERRCMD=@pause

[mcmatrix]

Tool override, could it be this?

You will define additional extruders.
Because in real life you only have 1 hotend so other extruders will use shared heater.

# In a multi-extruder printer add an additional extruder section for
# each additional extruder. The additional extruder sections should be
# named "extruder1", "extruder2", "extruder3", and so on. See the
# "extruder" section in example.cfg for a description of available
# parameters.
#[extruder1]
#step_pin: ar36
#dir_pin: ar34
#...
#shared_heater:
#   If this extruder uses the same heater already defined for another
#   extruder then place the name of that extruder here.  For example,
#   should extruder3 and extruder4 share a heater then the extruder3
#   config section should define the heater and the extruder4 section
#   should specify "shared_heater: extruder3". The default is to not
#   reuse an existing heater.
#deactivate_gcode:


#   A list of G-Code commands (one per line; subsequent lines
#   indented) to execute on a G-Code tool change command (eg, "T1")
#   that deactivates this extruder and activates some other
#   extruder. It only makes sense to define this section on
#   multi-extruder printers. The default is to not run any special
#   G-Code commands on deactivation.
#activate_gcode:
#   A list of G-Code commands (one per line; subsequent lines
#   indented) to execute on a G-Code tool change command (eg, "T0")
#   that activates this extruder. It only makes sense to define this
#   section on multi-extruder printers. The default is to not run any
#   special G-Code commands on activation.

During toolchange T<index> activate and deactive gcode is executed from extruder.

[SergeyKrutyko]

This is possible? I have only one physical heater / extruder in the system

[SergeyKrutyko]

Sorry i see description for: #shared_heater

[SergeyKrutyko]

mcmatrix, thanks for ideas. if you must realise command WAIT_FOR_PIN - then complete resolve my project for mmu2 bassed module!

[mcmatrix]

Btw if your filament switching module is open source project then maybe you could share it with the community.
I'm really interested to see this mmu2 based module working.
Maybe I even try to build it for myself if you share the project.

[SergeyKrutyko]

Btw if your filament switching module is open source project then maybe you could share it with community.
I'm really interested to see this mmu2 based module working.
Maybe I even try to build it for myself.

offcoz! now i get all stl files of original prusa mmu2 and print it.
also i waiting for all necesuary parts from aliexpress.
original project based on prusa board. my project on ramps + nema17.
total budget of my version mmu2 (original prusa stl details + ramps) is 80$ - it realy low price for this feature :)

i write own firmware for ramps. now i still wait for parts delivery and after complete and tests i place it to github if it interested :)

[SergeyKrutyko]

I therefore wrote it here. I hoped that if this is possible and the necessary functionality in the klipper will appear, I will be able to finish the project faster

[SergeyKrutyko]

Here is original prusa solidworks project of mmu2 https://www.thingiverse.com/thing:3080920

[KevinOConnor]

IF NEWTOOL=0 ; select tool 0
SET_PIN PIN=toolcode1 VALUE=0

I would caution against "programming in g-code". Instead, I'd recommend creating a Klipper "extras" module (see: https://github.com/KevinOConnor/klipper/blob/master/docs/Code_Overview.md#adding-a-host-module ) that performs the required actions and error handling.

original project based on prusa board. my project on ramps + nema17.

If your filament switcher has its own micro-controller you might want to consider running Klipper on that micro-controller and using Klipper's multi-mcu capability.

-Kevin

[SergeyKrutyko]

If your filament switcher has its own micro-controller you might want to consider running Klipper on that micro-controller and using Klipper's multi-mcu capability.

Own microcontroller will essentially perform a primitive task - engine management (material supply, slot switching and tube movement). There will also be several buttons for manual control.

Communicate with the main board of the printer, everything will be 3-4 wires, according to which the simplest combination will be applied to replace the filament.

To connect the entire system to the klipper seems to me too difficult and not justified

[SergeyKrutyko]

I would caution against "programming in g-code". Instead, I'd recommend creating a Klipper "extras" module (see: https://github.com/KevinOConnor/klipper/blob/master/docs/Code_Overview.md#adding-a-host-module ) that performs the required actions and error handling.

Kevin, i dont know python.... or know it too bad ((( also hardware + arduino and c++ is my featured technologies.

I agree that it may make sense to make the system as klipper module - but for now it seems to me faster and easier to do everything with a separate card controlled via wires through pins

[mcmatrix]

For tool change scripting you can use slicer options.
For example, Simplify3D has tool change script options and
probably others have it too.

...
{IF NEWTOOL=1}G1 F12000 Z2
{IF NEWTOOL=1}G90
{IF NEWTOOL=0} Do WHATEVER
...

[SergeyKrutyko]

For toolchange scripting you can use slicer options.
For example Simplify3D has toolchange script options and
probably others have it too.

{IF NEWTOOL=1}G1 F12000 Z2
{IF NEWTOOL=1}G90
{IF NEWTOOL=0} Do WHATEVER

I thought about it!
But:

1. A system with several clipper extruders solves this task more beautifully.
2. I would not like to be tied to a simplify only

[mcmatrix]

A system with several clipper extruders solves this task more beautifully.

Hopefully you don't need IF condition in gcode.
As Kevin said scripting in gcode is a slippery way.

If only what you need is pin state waiting command then I think it's doable.

[SergeyKrutyko]

mcmatrix, yes i need only waiting state of pin and all!

Here is an approximate algorithm of the module, as I imagine:

1. the execution of the change of filament command T0 ... T4
2. The filament is unloaded from the extruder
3. set pins to indicating the number of filaments for module
4. The module switch the drive of the current filament yarn
5. The module unload the current filament back until the sensor switching the end
6. The module selects another filament
7. Feeds the filament into the extruder by a predetermined tube distance
8. The module releases the filament thread drive for its free movement
9. The module sets the ready flag on the specified pin
10. The printer extruder load the filament in itself
11. The printing is continues

ps. sorry for my bad english

[mcmatrix]

Nice flow.
There's one thing you have to keep in mind when dealing with pins in Klipper.
Setting pins state is not real-time or instantaneous.
Klipper might schedule a change to a GPIO pin in a 100ms
and processing gcode also takes time.

[Maximuscr31]

Very interested in the software side of this. The hardware would be the easiest part. I really would like mmu2 capabilities for special prints. Please keep us updated.

[KevinOConnor]

Kevin, i dont know python.... or know it too bad ((( also hardware + arduino and c++ is my featured technologies.
I agree that it may make sense to make the system as klipper module - but for now it seems to me faster and easier to do everything with a separate card controlled via wires through pins

FYI, I'd recommend writing a Klipper "extras" module even with the separate card controlled through gpio pins. I understand it is a little more work upfront, but I think it would provide a nicer interface and much better error handling.

-Kevin

[SergeyKrutyko]

FYI, I'd recommend writing a Klipper "extras" module even with the separate card controlled through gpio pins. I understand it is a little more work upfront, but I think it would provide a nicer interface and much better error handling.

I had time to think. Also I looked at your recommended servo.py example. I am now really inclined to release it as a module of klipper.

In this regard, I have to you few questions:

1. There are 3 stepper motors on the module itself. Also there is a motion sensor filament.

2. In the original module - this is the presence of a filament sensor. I thought a lot and decided to replace it with to a motion sensor, based on a hall chip.
   Why I decided so - the fact is that the module itself is not a module for the supply of plastic. It just brings the thread to the extruder. Then the extruder picks up the thread and loads it into the itself. The thread motion sensor - will allow controlling this process. And in the event that it did not work out - then make a thread reset.

3. In principle, you can even load into the module - your firmware, and manage the engines, via virtual extruders.

Your system allows you to connect several modules. I just did not understand if I can from the klipper plugin, pass gcode commands to a specific MCU

[SergeyKrutyko]

mmu device have a 3 stepper

1. select filament (for movement)
2. select out of filament to the extruder
3. moving filament for load or unload

how i can control this motors when i connect my mcu as second device to a klipper?
i must use our default mcu firmware and place all logic to a python extras?

[KevinOConnor]

Running Klipper micro-controller code on the mmu2 is more work than using a "separate card with 4 wires". However, it should allow for very flexible control and error handling.

To control the mmu2 steppers from Klipper you would need to compile and install the klipper micro-controller code on your mmu2 ramps board. You'd then want to add something like the following to your config file:

[mcu mmu2]
serial: /dev/ttyUSB1
pin_map: arduino

[stepper_mmu2_select_filament]
step_pin: mmu2:ar54
dir_pin: mmu2:ar55
enable_pin: !mmu2:ar38
step_distance: .0225

[stepper_mmu2_select_out_to_extruder]
step_pin: mmu2:ar60
dir_pin: !mmu2:ar61
enable_pin: !mmu2:ar56
step_distance: .0225

[stepper_mmu2_load_filament]
step_pin: mmu2:ar46
dir_pin: mmu2:ar48
enable_pin: !mmu2:ar62
step_distance: .005

[my_mmu2_module]

You'd then create a klippy/extras/my_mmu2_module.py file with something like:

import stepper

class PrinterMMU2:
    def __init__(self, config):
        self.printer = config.get_printer()
        self.s1 = stepper.PrinterStepper(config.getsection("stepper_mmu2_select_filament"))
        self.s2 = stepper.PrinterStepper(config.getsection("stepper_mmu2_select_out_to_extruder"))
        self.s3 = stepper.PrinterStepper(config.getsection("stepper_mmu2_load_filament"))

and command the steppers with something like:

    def cmd_MY_SWITCH_FILAMENT(self, params):
         force_move = self.printer.lookup_object("force_move")
         force_move.force_enable(self.s1)
         force_move.manual_move(self.s1, dist=10.0, speed=5.0)

the force_move module helps perform basic stepper movements. It's also possible to do fancy stepper movements, but hopefully the existing force_move.py module will get you started.

-Kevin

[SergeyKrutyko]

KevinOConnor thanks! you really help me. Write code in python is good and flexible idea!

[SergeyKrutyko]

Also me need to get sensor and buttons states....

[mcmatrix]

Please see #545
It's using internal buttons module to get pin state change callbacks.
You'll get the idea of how it can be done.

Something like this, this will call callback on press and release (both states changes 0,1)

....
buttons = self.printer.try_load_module(config, "buttons")
buttons.register_buttons([config.get('pin')], self.button_callback)
....
def button_callback(self, eventtime, state):
    if state:
           do something

or this will only call callback only when pressed (only state 1)

...
self.back_pin = config.get('back_pin')
....
buttons = self.printer.try_load_module(config, "buttons")
buttons.register_button_push(self.back_pin, self.back_callback)
...
def back_callback(self, eventtime):
   do something
....

[SergeyKrutyko]

mcmatrix, Module "buttons" have a support of multi mcu mode?
how to set it in the configuration?

[SergeyKrutyko]

Also, sensor i must read state as button?

[KevinOConnor]

mcmatrix, Module "buttons" have a support of multi mcu mode?
how to set it in the configuration?

Back to my sample above, with @mcmatrix code it would look something like:

[my_mmu2_module]
back_pin: ^mmu2:ar2

I'm not familiar with how the mmu2 works. Can you describe what the code is supposed to do on a change in input signal? Does it need to immediately stop/start a stepper movement?

-Kevin

[mcmatrix]

Also, sensor i must read state as button?

If it's just digital on/off (1/0) sensor then it doesn't matter is it really button or not.
Currently, there's no way of polling input state at any moment!
You can only monitor input sensor state changes via buttons module callbacks.

Maybe it's not a problem. If your module sensor will always start up in a known state
and your module will keep track of any sensor state change internally. Then you're always aware of in what state your sensor is.

[mcmatrix]

@KevinOConnor I see that in background buttons are reporting their state continuously?
Is it possible to add a change (a method) in buttons.py to query button state at any time?
Something like get_button_state(self, pin).
Ofcoz then buttons.py has to keep track of pins states.

When using real buttons then a state change is enough but with a sensor, you might want to get the state at any time. Then we can use buttons module for both.

[KevinOConnor]

@mcmatrix - The button mcu state should always be in sync with the host mcu state. A message is sent on each change so the host can just keep track of that state. (There was a minor issue on state not being reset on a reconnect, but that should be fixed as of commit 357b2f47.)

Separately, it's also possible to track pin state using the endstop module. That's a better choice if the code needs to quickly halt a stepper on a change in input signal.

-Kevin

[mcmatrix]

@KevinOConnor Thanks.

[KevinOConnor]

I'm going to close this for now. Let us know if you have further questions.

-Kevin