New "virtual pins" module for testing purposes

I’m currently using simulavr set for atmega644p so I can test Fluidd while making changes, but this is becoming a problem given the limited number of pins available in this chip!

As I want a bunch of features enabled on the simulated MCU, I need to keep disabling some to free pins so I can use those in other features… which is not ideal!

I’ve tried using an atmega2560, but seems this is not supported, so I’ve now moved from that solution!

What I’ve been thinking is to add a new Klipper module called “virtual pins” (or simulated pins) that only purpose is to allow creating more pins that one can use with the existing modules, like [output_pin].

Ideally, the pins for this new module could be configured via [virtualpin], and then have a new command that would return the current state of a virtual pin or even all virtual pins.

Before I delve into developing such a module, I would ask for feedback as to understand if this is a useful module and if it would make a good candidate to eventually get merged into Klipper master code-base.


Will be useful for non developers too. An output pin is the only way i know to add a custom switch or slider to webui.

Perhaps a bit “off topic” here, but I’ve been thinking of possibly extending the “batch mode” processing of Klipper so that it would not require a mcu “data dictionary”. More specifically, have the host code “auto-generate” any required data dictionaries as it parses the printer.cfg file.

The advantage of doing this is that it would make it easier to run batch mode tests. In particular, it can be tricky to run a batch mode test when the printer.cfg file has multiple mcus.

If this were implemented, then any syntactically valid pin name would be considered valid by the host. (Thus, a batch mode test without explicit mcu data dictionaries would not be useful for verifying that a file is valid; however, it could still be useful to test kinematics.)

Not sure if that helps what you are looking for. Perhaps it will provide some additional ideas.


Well, this “virtual pin” won’t actually be used for anything… though one could be able to access via macros I guess!

After talking with @th33xitus on this topic, he made the excellent suggestion of trying to run TWO instances of simulavr, and amazingly, it works just fine!

The changes are quite trivial to get it up and running (all it needs is a different port path) though the impact is a bit considerable (docker indicates uptime ~1.0 with 1 instance, and ~2.0 for 2 instances)

So now we do have a solution for the lack of pins: just add more simulavr instances!

Nevertheless, I am still going to consider the “virtual pins” and might try and code a PoC for it as I do think there is some value!

Just a quick update, I’ve now managed to simulate any digital_out, pwm, adc pin types with relative success!

If anyone wants to give it a try, just add this file to your “klippy/extras” folder:

klipper/ at pedrolamas/virtual_pins · pedrolamas/klipper (

Then on the “printer.cfg”, add a [virtual_pins] entry, and from that point on, try setting a few pins to virtual_pin:xxxxx.

That will add a new SET_VIRTUAL_PIN gcode command that allow to set a virtual pin value (pass the PIN name and new VALUE from 0.0 to 1.0)

Under Klipper, one can create a macro to output all virtual pins state:

  M118 virtual_pins = { printer.virtual_pins.pins }

You can also check the status of all the virtual pins on moonraker via http://localhost:7125/printer/objects/query?virtual_pins (change “localhost:7125” accordingly!)

I’ve been considering the naming and came with these 2 options!

  • virtual-pins
  • simulated-pins

0 voters

I’m inclined to use “simulated-pins”, but wanted to check what other people think!

1 Like

From a software engineering standing point, what I have done is created a mock object for the pins, so I’m now considering if this should be called mock-pins or mocked-pins

(Yes, I hate naming stuff…)