XBuddy board GPIO?  

RE: XBuddy board GPIO?

Since your error says "undefined", you may have to first run an M42 P35 M1 (output), before you can do M42 P35 S0.
Might also be needing a "T" instead of "M":
https://reprap.org/wiki/G-code#M42:_Switch_I.2FO_pin

Based on:
https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/master/lib/Marlin/Marlin/src/HAL/HAL_STM32F1/fastio.h
your port math is correct. Pin PC3 would be 0x23, and that's the error you're getting, so at least you got the right pin!

RE:

Thanks, i will try doing that one of these days (soon).

This doesn't say anything about whether to use T or M, so i will try with both.

I wanted to try switching the spi pins, because they are exposed in the unused "accelerometer" expansion port (and i have a cable to connect to said port, making it all a bit cleaner).

RE: XBuddy board GPIO?

Posted by: @me-2

Thanks, i will try doing that one of these days (soon).

This doesn't say anything about whether to use T or M, so i will try with both.

I wanted to try switching the spi pins, because they are exposed in the unused "accelerometer" expansion port (and i have a cable to connect to said port, making it all a bit cleaner).

Thanks for sharing your experiments !

I did some digging in the code and I think I found what caused your error, I've highlighted the relevant lines in the screenshot below:

It's consistent with the error message you shared ("HWIO", "undefined")

Basically, the official firmware only allows `analogWrite`s to 2 pins, `FAN` and `FAN1` :/

I may be wrong, I have just read the code and inferred that this was the cause without actually running it, but I think I'm right.

RE: XBuddy board GPIO?

Darn. I had hoped to not change the firmware. i did try setting the pin mode, once with t and once with m and i got a bluescreen both times.

RE: XBuddy board GPIO?

I think you could still address the I2C pins on the accelerometer connector (and SPI on the expansion connector), but it would certainly be more complicated.

RE: XBuddy board GPIO?

how complicated? i just want an enclosure to heat itself up when i start an abs or asa print, and turn off when its done.

Posted by: @pyrho

Posted by: @me-2

Thanks, i will try doing that one of these days (soon).

This doesn't say anything about whether to use T or M, so i will try with both.

I wanted to try switching the spi pins, because they are exposed in the unused "accelerometer" expansion port (and i have a cable to connect to said port, making it all a bit cleaner).

Thanks for sharing your experiments !

I did some digging in the code and I think I found what caused your error, I've highlighted the relevant lines in the screenshot below:

It's consistent with the error message you shared ("HWIO", "undefined")

Basically, the official firmware only allows `analogWrite`s to 2 pins, `FAN` and `FAN1` :/

I may be wrong, I have just read the code and inferred that this was the cause without actually running it, but I think I'm right.

also, is that code for the xl? it looks like your tabs say "hwio_XLBuddy.cpp". idk if it matters anyway.

RE: XBuddy board GPIO?

The Buddy firmware isn't much better: https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/master/src/common/hwio_buddy_2209_02.cpp

Basically says the same thing.

switch (ulPin) {
        case MARLIN_PIN(FAN1):
            Fans::heat_break(0).setPWM(ulValue);
            return;
        case MARLIN_PIN(FAN):
            Fans::print(0).setPWM(ulValue);
            return;
        case MARLIN_PIN(BED_HEAT):
#if HAS_MODULARBED()
            return;
#else
            _hwio_pwm_analogWrite_set_val(HWIO_PWM_HEATER_BED, ulValue);
            return;
#endif
        case MARLIN_PIN(HEAT0):
            _hwio_pwm_analogWrite_set_val(HWIO_PWM_HEATER_0, ulValue);
            return;
        default:
            hwio_arduino_error(HWIO_ERR_UNDEF_ANA_WR, ulPin); // error: undefined pin analog write
        }
    }

This means that while the firmware clearly supports M42 commands, there are only 3 pins that are allowed to receive that command: FAN1, FAN, HEAT0.

This seems like a gross oversight, IMO.

I've opened a new GitHub issue, here, to try and get the firmware opened up, so we can drive and listen for things, using the Gcode. Please throw some comments up there, for support. Thanks!

RE: XBuddy board GPIO?

And here I was, checking GitHub occasionally for the schematic, but they decided to stick it as a direct download on a page I had previously never seen.

Anyway, seems like if it's just this section of the code that is limiting the pins that can be used, then it would be easy enough to tweak it and build a custom firmware that supports it.

As someone who has, and has been dabbling more as of late in C++ for Arduino-compatible microcontrollers, I can tell you I'm not going to spend time adding in code for things that aren't needed for the project I'm working on. So it may make sense, even if it's annoying, that only three pins are allowed to receive M42 commands.

Posted by: @fil4ment

The Buddy firmware isn't much better: https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/master/src/common/hwio_buddy_2209_02.cpp

Basically says the same thing.

 

switch (ulPin) {
        case MARLIN_PIN(FAN1):
            Fans::heat_break(0).setPWM(ulValue);
            return;
        case MARLIN_PIN(FAN):
            Fans::print(0).setPWM(ulValue);
            return;
        case MARLIN_PIN(BED_HEAT):
#if HAS_MODULARBED()
            return;
#else
            _hwio_pwm_analogWrite_set_val(HWIO_PWM_HEATER_BED, ulValue);
            return;
#endif
        case MARLIN_PIN(HEAT0):
            _hwio_pwm_analogWrite_set_val(HWIO_PWM_HEATER_0, ulValue);
            return;
        default:
            hwio_arduino_error(HWIO_ERR_UNDEF_ANA_WR, ulPin); // error: undefined pin analog write
        }
    }

 

This means that while the firmware clearly supports M42 commands, there are only 3 pins that are allowed to receive that command: FAN1, FAN, HEAT0.

This seems like a gross oversight, IMO.

I've opened a new GitHub issue, here, to try and get the firmware opened up, so we can drive and listen for things, using the Gcode. Please throw some comments up there, for support. Thanks!

RE:

Also it's 4 pins. Two fans, heatbed, and HEAT0 (the printhead).

Seems like if you want to live dangerously you could compile custom firmware and change the default case from

default:
            hwio_arduino_error(HWIO_ERR_UNDEF_ANA_WR, ulPin); // error: undefined pin analog write

to something like:

default:
             _hwio_pwm_analogWrite_set_val(ulPin, ulValue);

Please note I am not sure if this is correct, by any means!

Also, you get into weird things. For example:

Posted by: @me-2

Um, i tried printing a model with the following custom gcode (trying to switch pins pc3 and pc2) at the start of the 2nd layer

M42 P35 S0

M42 P34 S0

M300 S100 P1000

I got the following bluescreen of...    problems :

 

it won't let me upload the gcode here 🙁

Pin 34, PC2, is the SPI2 MISO. This is an input to the micro, so there is undoubtedly code elsewhere that is setting this as an input pin, so if you tried to use it as an output pin, it would fail, somehow.

So somewhere you'll need to check if SPI2 is enabled, and disable it if so, and set the pin as an output. Since Prusa is using this for SPI for an accelerometer, it's not strictly an "unused" pin, as the Marlin firmware is talking about. So I certainly would not expect that Prusa, having assigned specific functions to pins they've broken out, would code up extra code that allows shutting that off and using it for other things.

This is where the pros and cons of open source come in. Pro: You can modify it to do whatever you want. Con: If nobody else has already done the work, you will have to do that work.

What I was hoping there was were pins that were broken out but NOT assigned a function by Prusa. Truly unused, only there for future expansion type pins. But a quick look at the pin mappings from Prusa linked earlier and it appears that Prusa has assigned functions for all the pins they broke out.

RE: XBuddy board GPIO?

Quick response: PE12, on the expansion port, does not appear to have ANY current application.

RE: XBuddy board GPIO?

Full response:

Posted by: @jseyfert3

Also it's 4 pins. Two fans, heatbed, and HEAT0 (the printhead).

Yup. You're right. It's 4 pins. I misread the preprocessor "#" as comments, because I've been writing bash scripts too much, lately.

Seems like if you want to live dangerously you could compile custom firmware and change the default case from

default:
            hwio_arduino_error(HWIO_ERR_UNDEF_ANA_WR, ulPin); // error: undefined pin analog write

to something like:

default:
             _hwio_pwm_analogWrite_set_val(ulPin, ulValue);

Please note I am not sure if this is correct, by any means!

Instead of changing the default, you could also add another case, but that would be far more involved. I don't know if THAT route is worth chasing.

Also, you get into weird things. For example:

Posted by: @me-2

Um, i tried printing a model with the following custom gcode (trying to switch pins pc3 and pc2) at the start of the 2nd layer

M42 P35 S0

M42 P34 S0

M300 S100 P1000

I got the following bluescreen of...    problems :

 

it won't let me upload the gcode here 🙁

Pin 34, PC2, is the SPI2 MISO. This is an input to the micro, so there is undoubtedly code elsewhere that is setting this as an input pin, so if you tried to use it as an output pin, it would fail, somehow.

So somewhere you'll need to check if SPI2 is enabled, and disable it if so, and set the pin as an output. Since Prusa is using this for SPI for an accelerometer, it's not strictly an "unused" pin, as the Marlin firmware is talking about. So I certainly would not expect that Prusa, having assigned specific functions to pins they've broken out, would code up extra code that allows shutting that off and using it for other things.

This is where the pros and cons of open source come in. Pro: You can modify it to do whatever you want. Con: If nobody else has already done the work, you will have to do that work.

Yup. We now know that it's POSSIBLE. It's just a matter of... will anyone actually DO it?

What I was hoping there was were pins that were broken out but NOT assigned a function by Prusa. Truly unused, only there for future expansion type pins. But a quick look at the pin mappings from Prusa linked earlier and it appears that Prusa has assigned functions for all the pins they broke out.

As I said earlier, PE12 looks utterly unused in the schematic (see attached).

RE: XBuddy board GPIO?

I would like to add a micro switch or similar to pause a print job if the filament spool gets tangled on both my Mini and upgraded MK3.5. That way a print job can possibly be saved in the event of a tangled spool.

My Mini sucked a tangled spool right up to itself and jammed the extruder in a not so fun kind of way.

Any way to implement this on the xBuddy board or the Mini board?

RE: XBuddy board GPIO?

not yet, i think. i have tried using the extra gpio pins with official firmware (5.1.2, not 5.1.3 but i don't think it makes a difference), and it gives an error (bluescreen and beeping) every time.

RE: XBuddy board GPIO?

I talked to support. He said he escalated the idea. Maybe something will come of it.

RE: XBuddy board GPIO?

That would be great if something did come from it!

also, in my previous post i forgot to mention that i only tested M42 commands (writing to gpio pins), so adding a micro switch and reading from a gpio connection might work (slim chance, but worth testing).

RE: XBuddy board GPIO?

Posted by: @oregonerd

I would like to add a micro switch or similar to pause a print job if the filament spool gets tangled on both my Mini and upgraded MK3.5. That way a print job can possibly be saved in the event of a tangled spool.

My Mini sucked a tangled spool right up to itself and jammed the extruder in a not so fun kind of way.

Any way to implement this on the xBuddy board or the Mini board?

Could you add a microswitch into the filament run-out sensor wiring?  No idea which line you'd need to switch to what... but a tangled spool, if you can fit a switch to detect it, probably could be handled as a filament run out anyway?  Sensor and its wiring is very easy to access on the mini+. 

RE:

Could you add a microswitch into the filament run-out sensor wiring?  No idea which line you'd need to switch to what... but a tangled spool, if you can fit a switch to detect it, probably could be handled as a filament run out anyway?  Sensor and its wiring is very easy to access on the mini+. 

Maybe, according to the attached schematics.

in theory, you could solder on a micro switch that shorts p2/vout on the filament sensor to ground or vcc, although this has a decent chance of wrecking the filament sensor.

alternatively, if you used a spdt switch, you could switch between the actual reading from the sensor and gnd / vcc (thus protecting the sensor)

Note: do this at your own risk. my recommendations might be wrong (e.g, following them might destroy your printer), and doing this will definitely void your printers warranty.

RE: XBuddy board GPIO?

Basically, the filament sensor has three wires going to it: 3.3v (Vcc), Vout (an analog value that indicates sensor reading), and Gnd (kinda obvious what this one is).

if you cut the cable to the filament sensor, then wired up your switch so that normally the sensor reading is passed through to the loveboard but when the spool is being pulled into the extruder the sensor is disconnected and the signal to the loveboard is connected to Vcc (or Gnd, idk which would indicate no filament).

The attached image shows how you could wire it.

I am going to say this again: doing this will void your printers warranty

RE: XBuddy board GPIO?

Putting a micro switch in series with the filament sensor on the Mini should be rather easy.

RE: XBuddy board GPIO?

oops, sory. the info / instructions i gave are for a mk4, not mini. 

that being said, you could probably do something similar on the mini or mk3.5, probably even the same exact wiring (the sensor on the mk4 is a hall effect sensor, on the mini i think it's IR, i think mk3.5 is same as mini).

i don't have time rn to dig through the mini's schematics, i'll tell you when i get around to it (probably tomorrow).