How can I reroute multiple signals from a 4 pin connector using a relay switch?

  • Thread starter Thread starter Next_Of_Kintetic
  • Start date Start date
  • Tags Tags
    Pin Relay Switch
Click For Summary
To reroute multiple signals from a 4-pin connector using a relay switch, a 4-pole double-throw (4PDT) relay is recommended, as it can manage multiple signals without mixing them. The user seeks a solution to control which motor receives signals from a 3D printer via this connector, aiming for a setup that allows switching between two motors. A latching relay that retains its state without power is preferred, and there are concerns about the complexity of wiring and voltage connections. Suggestions include using off-the-shelf latching relay boards compatible with Raspberry Pi, which can simplify the control process. Overall, the discussion emphasizes finding a reliable relay solution that meets specific control and signal routing needs.
  • #31
pbuk said:
I should have mentioned that if it was my project I'd use a proper microcontroller instead of the Pi. I would enclose the whole thing in a box and power the relays from the 5V from the wall wart (I know I said you don't want to do that but that is because I don't know what else is plugged into the Pi e.g. HDMI. If you only have the control board and wires from the printer and the wall wart inside a plastic enclosure you don't have to worry about opto-isolating the board).

I'd use one of these: https://thepihut.com/products/adafruit-feather-m0-wifi-atsamd21-atwinc1500 but they are very difficult to get hold of now (I have one in my box of toys but you can't have it!). An alternative would be an ESP32 if you are happy with 100% Chinese technology, otherwise a similar M0 or M4 Feather board with a separate ATWINC-1500 WiFi module.
Here's the thing. My Pi is what talks to my 3d printer. It uses OctoPrint to send gcode to essentially tell the printer what to do when printing. That same Pi also controls a beefy relay switch, which is connected to the printer as well. Currently, when I contact my Pi through Wifi, I can click on a button on my computer, that goes through my local wifi, tells my Pi to activate a GPIO pin, that then sends a signal to the beefy relay, the beefy relay turns on, causing everything connected to the beefy relay to also turn on, including the 3d printer and also a lamp to light up the room. Once that happens, I can also click buttons on my computer to tell the printer to print something.
So basically, all of that is already set up; I do not want to change all that. And essentially, I am just trying to extend that functionality and design.

I cannot use a microcontroller to talk to my printer (at least not easily; it would be like re-inventing the wheel). So, basically, I would still need the PI, but then adding a microcontroller to the system to just talk to the relays does not make sense to me; it feels like an un-needed "middle man" component.
To me, it makes more sense to just use one main board (the Pi - who I already can talk to through my computer) do all the talking, and tell other components to do their specific function. Then have those components do those specific functions (ie: Pi should just tell the relays to switch, and they switch).
This also gives me extra control all in one place instead of having to deal with multiple points of contact.

Let me know if I misunderstood something though.
Thanks again.
 
  • Like
  • Love
Likes pbuk and Tom.G
Engineering news on Phys.org
  • #32
GrahamN-UK said:
There seem to be two definitions of extruder. https://all3dp.com/1/3d-printer-extruder-nozzle-guide/ suggests extruder can either mean "exclusively the motor and associated parts that push and pull the filament" or "the entire assembly including the hot end". You seem to be using the former definition whereas I lean towards the latter as that seems closer to the usage of extruder in non-3D printing contexts.

A normal extruder (using the former definition) pushes the filament into a single tube. With your proposal you'll need to ensure that filaments coming from two extruders can reliably feed into the single feed tube.
And again, this is why human terminology sucks. I always thought the same way, that basically the hot end should be called the extruder, and whatever pushes the filament into the tube should be a "filament driver", since as you said, that would make sense outside of 3d printer contexts. But, when I run into others or on other forums who talk about 3d printers, a lot of them refer to the former definition of extruder -- so much to the point where it has become part of my lexicon. It's unfortunate...

And yes, my plan is that they have their own tube, and then all those tubes get funneled into a main tube. Something like that exists, just need to find it or worst case scenario, make one. The case where both get funneled into the main tube at the same time should not happen, since I would activate the "filament change protocol", which would get rid of all filament in the main tube currently, before activating the other motor to start shoving more filament into the main tube.

GrahamN-UK said:
You wanted to treat the printer as a black box and not change it. How then are you going to pause a print and get the printer to feed the second filament to the hot end of the print head?

There's an existing method to cope with the filament running out. That is to use a filament (runout/break) sensor along with printer firmware that monitors the sensor. If the filament runs out the printer pauses the print, allows the user to replace the filament then resumes printing.

Is there some reason you can't use that method and have to invent your own?
uh what? I was referring to the 3d printer as a black box in a completely different context. It's essentially a black box because you do not need to know what signals it is sending to the motors/ extruders - if you want to relay those same signals to a different motor or location, you should be able to just relay them, and thus pretend whatever is sending them is essentially a black box.

As for coping with filament running out -- I am not inventing my own, I want to use that method, but make it more "automatic". Ocotoprint, the framework that my Pi uses for talking to the 3d printer, has this functionality already. You can basically tell it to pause and wait for filament replacement before resuming. And obviously, you can tie it into using a sensor associated with the printer.
But, you still have to physically go to the printer yourself and do the change manually.
I want to avoid that, be super lazy, and have something else do that so that it continues printing.
And then when I feel like it, just replace one of the filament spools.
The whole point of this project is to have my system to do the filament replacement for me.
But, that is an end goal.

Right now, the first step would be to get it to switch motors/ extruders/ filament drivers when I send a command to my Pi.

Hope that makes sense.
Thanks again.
 
Last edited:
  • Like
Likes Tom.G
  • #33
Next_Of_Kintetic said:
I'm a little bit confused by this statement. I agree the circuit is messy, but there is a signal coming from the pi. It would be coming from the GPIO pins.
There are only connections to pins marked "3.3V" which is pins 1 and 17 on a Pi connector. If they were meant to be GPIO pins then you should have marked them as such, although it doesn't really matter because...

Next_Of_Kintetic said:
Although, as you point out later, and now I am realizing it myself, there needs to be a relay driver of some kind that receives that signal instead, and then drives the actual relay accordingly (since those pins don't have enough power to do so by themselves).
Indeed.

Next_Of_Kintetic said:
Hmmm... interesting. But, isn't the issue with this relay that it is not a latching relay? So, it would have to keep being powered in order just to maintain a switched position?
No, when unpowered it is in the "NC" (normally connected) position.

Next_Of_Kintetic said:
I would either have to keep the relay powered all the time (which would be stupid in my opinion)
This is what relays are designed for.

Next_Of_Kintetic said:
Also, another issue is that according to the manufacturer, the "board does not have opto-isolation."
No it doesn't, but if you are only switching the low voltage control lines that's not really a problem.

The advantages of the board I specified are that it is cheap, easily available, works at the 3.3V signal level of a Pi, has a DPDT and is easy to wire to the Pi. You could use 2 SPDT relays, or even 4 SPST relays but I don't know if your printer could tolerate failure conditions where it was driving two feeders at once, and as this is your first foray into electronics you should keep it simple.
 
  • #34
Next_Of_Kintetic said:
Here's the thing. My Pi is what talks to my 3d printer. It uses OctoPrint to send gcode to essentially tell the printer what to do when printing.
I missed that part, yes of course in this case there is no point not using the Pi.
 
  • Like
Likes Next_Of_Kintetic
  • #35
Sorry for the late reply, been quite busy for most of the week. But here we go...

pbuk said:
There are only connections to pins marked "3.3V" which is pins 1 and 17 on a Pi connector. If they were meant to be GPIO pins then you should have marked them as such, although it doesn't really matter because...
Ah. I see what you mean. Fair enough.
Although, couldn't I use those as well to send signals to the relay board that you linked?

pbuk said:
No, when unpowered it is in the "NC" (normally connected) position.
That's kind of the point I was making though. Because then what happens if I switched to the "NO" position last time before I turned off the 3d printer. If I also turned off power to the relay (or let's say a surge happens, power gets cut off), then the relay reverts back to its NC state. When power comes back on, wouldn't it remain in the NC state unless something tells it to switch again? Wouldn't this cause an issue?

For example, imagine the following scenario:
- Printer runs out of filament
- Relay is currently on NC position (so filament associated with the "NC" motor has run out)
- All the fancy logic happens and Pi says "switch" to the relay
- Relay switches from NC to NO position in order to reference / use the other motor and filament associated with that motor. So, now the filament is coming from the filament spool associated with the "NO" motor.
- Filament change occurs as it should
- Everything is working fine
- Power surge happens (Oh no!)
- Power comes back online, but relay has no idea of its previous state
- Printing resumes with filament associated with the other motor (the "NO" motor)
- But, because the relay never switched back, the "NC" motor spins (the one that had its associated filament run out at the beginning), while the "NO" motor stays motionless. (Oops...)

So basically, I could end up sending signals to the wrong motor as a result. So, either I would have to keep the relay switch powered on all the time (but if a power surge happens, this would still reset the switch to NC, which messes with the way I imagined it working) OR I would have find some way to save the relay's state (which might be possible since I could potentially save it as an environmental variable on the Pi's server, but then I would need to figure out if the Otcopi framework can even access that)...

pbuk said:
No it doesn't, but if you are only switching the low voltage control lines that's not really a problem.
Wait, and this is probably my overall confusion about the subject, but I thought the point of opto-isolation is to protect high voltage surges from other parts of the system from wrecking circuitry that is not resistant to that high voltage. I mean, do I not have to worry about a high surge occurring within the relay from say the wall wart and then "cascading" back to the Pi? Is it only something to only worry about in terms of the voltages you are switching between?

pbuk said:
The advantages of the board I specified are that it is cheap, easily available, works at the 3.3V signal level of a Pi, has a DPDT and is easy to wire to the Pi. You could use 2 SPDT relays, or even 4 SPST relays but I don't know if your printer could tolerate failure conditions where it was driving two feeders at once, and as this is your first foray into electronics you should keep it simple.
I agree. And thank you for recommending it. I think it might be the way to go, but as I lack the experience, I'm just trying to make sure "I cross my T's and dot my I's" so to speak. I am not trying to find flaws or anything specifically wrong with it; I'm just trying to see in my mind how it would work within the system and any potential things I might have overlooked or if there is anything I need to work-around as a result.

As always, all answers are welcome and appreciated.
Thanks again.
 
Last edited:
  • #36
@Next_Of_Kintetic, for the reasons you just discussed, I recommend you stick with your original latching relay approach.
 
  • #37
Next_Of_Kintetic said:
Although, couldn't I use those as well to send signals to the relay board that you linked?
What the 3.3V pins? No, these are always at 3.3V. They provide power (up to 500 mA if I remember correctly) for attached circuitry e.g. this neat little real time clock module. You could use them to provide power to the relay board, but 3.3V relays are hard to find, you would be better off using the 5V pins: see below.

Next_Of_Kintetic said:
That's kind of the point I was making though. Because then what happens if I switched to the "NO" position last time before I turned off the 3d printer. If I also turned off power to the relay (or let's say a surge happens, power gets cut off), then the relay reverts back to its NC state. When power comes back on, wouldn't it remain in the NC state unless something tells it to switch again?
Yes: don't turn it off (I would power the relay from the 5V pins (2 and 4) on the GPIO connector so this was not an issue - you don't need a separate wall wart at all). I think recovery from a power outage is going to be more complicated than just having the Pi remember which feeder is feeding.

Actually forget about building it yourself, just use one of these: leave the jumpers off and bridge P25, CH1 and CH2 together (so that 2 of the SPST relays are switched simultaneously by GPIO 25).

Next_Of_Kintetic said:
Wait, and this is probably my overall confusion about the subject, but I thought the point of opto-isolation is to protect high voltage surges from other parts of the system from wrecking circuitry that is not resistant to that high voltage.
No, the principal point of opto-isolation is to prevent you from being electrocuted. It (or some other physical separation) is a requirement in the UK (and I believe in the US) when switching line voltages from a device with low voltage connections (the wires to the Pi from the relay box if this is in a separate enclosure) or exposed metal (the USB connector on the Pi if this is in the same enclosure).

Next_Of_Kintetic said:
I mean, do I not have to worry about a high surge occurring within the relay from say the wall wart and then "cascading" back to the Pi?
No, the wall wart already includes protection from line voltages appearing on the output, the same goes for the printer and its control lines to the feeders. You only need to worry if you are switching line level voltages.
 
  • #38
Hi everyone,

Sorry for the late response, but I have been extremely busy this last week (what else is new).
And I will unfortunately have to put this project on hold due to various life related circumstances.

So, I just wanted to thank you all for all your help and responses.
As for what I end up doing eventually (if I decide to use a latching relay or a powered relay -- that is something I'm still not sure about at the moment). I might even seek out other possibilities in the future. Either way, just wanted to thank everyone again for all their help. I have learned a lot from these discussions.

If I end up coming back to this project, I will just open a different thread if need be.
Feel free to lock or archive this thread.
Thank you all again. Until next time.
 
  • Like
Likes Tom.G

Similar threads

  • · Replies 7 ·
Replies
7
Views
583
  • · Replies 31 ·
2
Replies
31
Views
4K
Replies
8
Views
2K
  • · Replies 16 ·
Replies
16
Views
3K
  • · Replies 11 ·
Replies
11
Views
4K
  • · Replies 14 ·
Replies
14
Views
4K
  • · Replies 5 ·
Replies
5
Views
4K
Replies
12
Views
3K
Replies
2
Views
2K
Replies
6
Views
2K