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!
