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.
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 printer.cg 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.
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!
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…
and then reference it in a Gcode macro (which is what is throwing the error):
#///////////////////////////filament sensor button macros/////////////////////////////////////////////////
[gcode_button sensor_fs]
#pin: PC7 # !!!!!!!!!!!!!!!!!!!!!change with the pin name to which the sensor is connected!!!!!!!!!!!!!!!!!!!!!
pin: virtual_pin: fs_button
press_gcode: # sensor released
I assume I’m trying to use this incorrectly.
PS Im trying to simulate a physical button being pressed, where no actual button exists.
EDIT: NVM, I got it working. It was user error, I was trying to use it in the wrong location:
[gcode_button sensor_fu]
pin: virtual_pin: fs_button # remove the negation "!" for sensor v1 - use just PA10 as example
release_gcode: # filament unload procedure
I haven’t checked, but the way you have it (with the space) I assume it will create a nameless virtual pin (ignoring the Id you put in), just be aware of that if you have more virtual pins in your config!
So I just found this thread and I’m curious if this virtual pin module will help me to accomplish a particular goal.
I have a BCN3D Sigma D25 printer currently running Klipper. This is an IDEX machine, and both printheads have a piezo sensor used for probing the bed with the nozzle. My issue is that Klipper does not allow for two Z-probes to be configured. Both of the probes are simple on/off like an endstop, so I could modify the hardware so that both probes trigger the same pin on the MCU. The issue there is that BCN used FFC (flat flexible cable) for all of their connections, and I don’t want to modify the hardware and risk ruining it when it works well as-is.
My question is: could I use this Virtual_Pin module to assign my Z-probe to a virtual pin whose status is determined by either of two physical pins (essentially an OR gate)? This would allow me to easily write a macro to determine the offset between my nozzles at the start of a print. Currently I use T0 for all probing and the probe on T1 is undefined/unused. This means that my nozzle offset between T0 and T1 must be determined manually (or shims are inserted on T1 to physically set both nozzles to the same height).
Hi @wcj97, the virtual pins were built for simulation purposes, but having said that, you might be able to do something in conjunction with gcode_button to achieve your purposes!
I have NOT tried this, but something along the lines of this might help:
The idea here is that each pin (in the example above A1 and A2) is assigned to a gcode_button and when it changes state, then UPDATE_VIRTUAL_PIN is called so that virtual_pin:my_pin is updated with and OR of these 2 pins.
Then all you need is to use virtual_pin:my_pin where you want it!
Once again, I have not tried this so if you use this, you will be doing it at your own risk!
thanks for the excellent work, with your module I wrote a good script to delay the start of printing. with a convenient slider implemented with your virtual pin
