In the interest of getting rid of the stray electrical charge developed from the moving belts, I suspect that it would be best to route it to earth ground, rather than the common rail of the power supply.
This would minimize the chances of the static possibly causing any issues, and dissipate it direct to ground, rather than routing it through whatever electrical path before eventually, hopefully, being tied to ground.
This reminds me that I need to double check my grounding...
@Danal Merry Christmas to you as well!
Thanks for the tip again, the boards are all back online, running 2.05, the web servers all up to date, and the displays also.
One good thing that came out of this, and the newer firmware on the controllers, is that my printers now stay on the IP address that I assigned them to, instead of ignoring the config.g specified IP address like they did under the older firmware.
Now I just need to get the other printers assembled and using the boards. Two spare boards is a bit of an embarrassment!
@phaedrux
The lights are a stacklite set, of course I don't have the actual brand and model, but like the one shown in this wiki's first image.
https://en.m.wikipedia.org/wiki/Stack_light
I believe they all share a common v+ wire, but diodes can be used to work around that, or I can roll a switching logic isolation board to go between the duet and the lights.
The part I was looking for advice on was where to get started in trying to trigger them.
I'll start reading on the functions you mentioned, and see what I can find, and other questions come up from there.
Thank you for the suggested reading.
I have been using a Duet Wifi for years, but haven't really gone down the rabbit hole of any inputs or outputs beyond the default Configurator supported bits until now.
My employer bought a RailCore II printer, and then put it in a location (behind a partition) that is easily forgotten about.
We have an extra 24vdc status indicator light stick, and I'm looking to program some triggers that would turn on outputs on the DueX5, probably just extra PWM fan outputs or heater outputs, and use them to power the status lights.
My initial thought was to trigger the one light any time the printer is on, easily done by just wiring it to the PSU output.
The second light would be if there is a print in progress, possibly blinking it slowly just to say that the printer is operating. (one of the spare extruder heater outputs set to bang-bang at low frequency, was my thought.)
The final thought was to trigger a red light or strobe if there was a fault, such as a thermal runaway and the printer locked out the heaters, etc.
Can someone point me toward the right direction to get started with this, in the RepRapFirmware programming style?
I would like to understand it and do it, but I'm not sure where to start when it starts wandering away from the basics.
@dc42 Considering that this is an early board, pre-ordered just after the beta boards, I imagine many things were updated later on.
I've purchased a couple of Duet2 Wifi boards since, and my work just purchased a Duet2 Ethernet, and I'm always a little amused as I see the improvements between each generation.
We bought a PanelDue 5i for the RailCore that was just built at work, and I'm tempted, but my 4.3 generally works fine...
Please disregard...
I just had an idea, and checked how many jobs were stored on the Duet (and how large they were) and found that once I cleared out a good few that were old data, everything displays.
That said, the PanelDue was not displaying quite a few files, and a wide variety of ages and sizes were invisible for some reason.
After purging ~150-200MB of gcode, everything appears to show on the PanelDue, including some I thought I'd deleted from the Duet, and were still stored on it.
As the title says, the only common thread I can find is that I recently started using PrusaSlicer, and the files that I slice in it do not show up on the files list on the PanelDue, but all the files sliced in S3D show up normally.
Looking in the Web Control Interface, they are all present, and in order that I uploaded them, most recent first, the PrusaSlicer files most recently.
They print as expected, if managed from a PC or even my phone. I just can't see them on the Panel Due.
Duet2 Wifi
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.1.1 (2020-05-19b2)
Duet WiFi Server Version: 1.23
PanelDue v1, 4.3", Firmware 1.23.2
I can update the display to v 1.24, but I'm not seeing anything that looks applicable in the update notes, so I didn't want to push my luck and potentially have a failure if it's unrelated.
@Danal Merry Christmas to you as well!
Thanks for the tip again, the boards are all back online, running 2.05, the web servers all up to date, and the displays also.
One good thing that came out of this, and the newer firmware on the controllers, is that my printers now stay on the IP address that I assigned them to, instead of ignoring the config.g specified IP address like they did under the older firmware.
Now I just need to get the other printers assembled and using the boards. Two spare boards is a bit of an embarrassment!
Thanks for the input.
I went ahead and dug up the information on updating from this firmware, and it fixed the issue I was having with this PanelDue.
Once I saw that it'd added some nice features, I pulled out my spare PanelDue that is intended for a printer that's still sitting in pieces, and updated it as well.
The spare DuetWifi that goes with it wasn't so easily updated, and is now forcing me to test my Bossa/SAM-BA skills...
I just updated my DuetWifi from 1.18 (I think) up to 2.05, and noticed that some gcode files are not showing up on the list when I tap the SD card icon on the PanelDue.
I can access the printer through the web interface and print the files, but I'm not seeing them on the PanelDue.
I don't see anything in the release notes for the screen that hints at this, but I may well be missing something.
My only reason that it's not updated is that I would need to disconnect it from the printer and get my PC to talk nicely to the screen for the update, and I didn't see anything that seemed to be necessary on the notes.
Any suggestions or information would be welcome.
Happy Holidays everyone!
-Josh
That makes a lot of sense, and it's simple to boot.
I have a couple of 27,000mfd 15vdc caps around that my work used to use as brown-out prevention on the 5vdc supply rail of some small dot-matrix receipt printers.
I suspect that one of those would be more than enough to trigger the coil.
The issue that I am running into with this switch is that if I use the ATX PS-Off g-code:M81, it breaks the connection between the pins on the ATX power control connector. The thermostatic setting isn't an issue, other than the only g-code for power that recognizes it being M81.
I will have to test whether M81 is a blocking command, and if it will cause a Wait condition until it is completed.
If so, it would be able to indirectly allow another command to trigger once the hot end fan has cooled down, if the M81 was followed with a command to turn on a "fan" that triggered the remote disconnect power switch in a shutdown macro.
Barring something like this being functional, it looks like the energized relay method that DocTrucker suggested may be the only option, though a bit more of a work around to get to that point than it seems like should be required.
Regarding the wiring of the switch on the mains power, it is a dual pole, single throw switch, so it is already switching line and neutral. The printer is also protected by a whole house RCD circuit breaker, which I have not had any issues with leakage current false triggering, or switched lines.
Re: Remote Control Power Switch using Raspberry Pi
Jackal 21 Jan 2017, 20:13: "I have only implemented remote switch off on my delta with raspberry pi and Omron remote reset switch (https://www.omron.com/ecb/products/pdf/en-a8gs.pdf)"
After seeing this in the linked thread above, I ordered one of these switches, thinking that I could easily drive it to shut down mains power to the MeanWell SE-600-24 that powers my printer.
This has hit a snag after realizing that it requires 5V 0.2A to trigger the coil, and that the G-code driven power off only opens a switched dc contact on the ATX control pins.
My questions are: is there any way to change what output the ATX M80 and M81 trigger, or to invert the switch behavior (M81 i1 for instance?)
If I could invert the switching behavior, I could run a voltage regulator or just a divider circuit, and either drive it through the ATX power output or a transistor, to trigger the reset coil on the power switch.
The other option that I was pondering was to use an external transistor to switch it, controlled by one of the unused heater outputs on the expansion header.
If going that way, is there any relatively simple g-code to trigger it after the thermostatic extruder cooling fan has turned off, like the ATX power seems to already have logic programmed to do?
I was hunting for any g-code to do this, but was not finding it if it exists.