watchdog Timer for teensy 4.1

[Neelwell2]

Hello All
I am a musician, and since i discovered , micro computers, i love working with them.
They have opened a lot of doors that i never knew existed, that i have used in my music journey.

But i still have a lot to learn.
But Learning is the best part
I am using a teensy 4.1 ,and I'm running drums via midi through the ( TEENSY) 4.1.
and i am using Electronic Solenoids to hit the drums.
It works great
But now and then, ( very rarely) a drum may get stuck closed.
This is problematic, because when that happens , the power going to the solenoids ( 24volts) is constant.
Heating up the coil in the solenoid.
If i Diosconnect the teensy from the computer, it un-sticks and rest's
Now these solenoids are strong , and can take the heat, if that happens , but i dont want to damage them.
I got a phone call one day and was not paying attention and one of the solenoids got stuck, and it took at least 40 minutes , but the solenoid caught fire, and i had to make a mad dash for the fire extinguisher.needless to say that solenoid had to be replaced.
But i don't want to have a replay of that.

What I'm trying to do is counter act that when it happens.

From what I understand, this can be counteracted with a watch dog timer.
If i get a stuck drum witch is a stuck midi note,

Now I have the watch dog timer library.

But I don't have enough knowledge to know how to set it up yet.

This is why I need your help can anyone help me with this problem thank you very much in advance.
Here is my sketch
-----------------------------------
#include <Watchdog_t4.h>
#include <MIDIUSB.h>

// these are the arduino pins that the solenoids are hooked up to
enum drumPins {kickPin = 6, snarePin = 3, hhPin = 5, crashPin = 3, cowbellPin = 4 , openhatPin = 0};

// these are the midi notes that each solenoid triggers on, as well as an alternate for each
enum midiNotes {kickMidi = 2, snareMidi = 4, hhMidi = 3, crashMidi = 49, cowbellMidi = 39, openhatMidi = 46};
enum midiNoteAlts {kickMidiAlt = 44, snareMidiAlt = 48, hhMidiAlt = 45, crashMidiAlt = 149, cowbellMidiAlt = 47, openhatMidiAlt = 146};

void setup() {
// the serial port is just used as a monitor for debugging
// it is not needed for midi
Serial.begin(115200);

// setup all output pins
for(int i=0; i<=8; i++) {
pinMode(i, OUTPUT);
}
}

void loop() {
//listen for new MIDI messages
midiEventPacket_t rx = MidiUSB.read();
processMidi(rx);
}

void processMidi(midiEventPacket_t rx) {
switch (rx.header) {
case 0x0:
// do nothing
break;

//note on
case 0x9:
handleNoteOn(rx.byte1 & 0xF, rx.byte2, rx.byte3);
break;

//note off
case 0x8:
handleNoteOn(rx.byte1 & 0xF, rx.byte2, 0);
break;

// control change
case 11:
Serial.print("CC: ");
Serial.print(rx.byte2);
Serial.print(":");
Serial.print(rx.byte3);
Serial.print("\n");
break;

default:
Serial.println(rx.header);
break;
}
}

void handleNoteOn(byte channel, byte pitch, byte velocity) {
// it is possible to use the actual midi velocity here, just be sure to
// double to value because midi is 0-127
// and then change digitalWrite to analogWrite
if(velocity > 0) {
velocity = HIGH;
}

switch (pitch) {
case kickMidi:
case kickMidiAlt:
Serial.print("Kick: ");
digitalWrite(kickPin, velocity);
break;
case snareMidi:
case snareMidiAlt:
Serial.print("Snare: ");
digitalWrite(snarePin, velocity);
break;
case hhMidi:
case hhMidiAlt:
Serial.print("HH: ");
digitalWrite(hhPin, velocity);
break;
case crashMidi:
case crashMidiAlt:
Serial.print("Crash: ");
digitalWrite(crashPin, velocity);
break;
case cowbellMidi:
case cowbellMidiAlt:
Serial.print("Cowbell: ");
digitalWrite(cowbellPin, velocity);
break;
case openhatMidi:
case openhatMidiAlt:
Serial.print("Open hat: ");
digitalWrite(openhatPin, velocity);
break;
default:
// print the midi note value, handy for adding new notes
Serial.print("Note(");
Serial.print(pitch);
Serial.print("): ");
break;
}

if(velocity == 0) {
Serial.println("off");
} else {
Serial.println("on");
}
}

 

[defragster]

Fire Bad!
There are examples of use for the Watchdog library.
Posted code is made readable (indentation is preserved) when using the CODE markup - first icon "</>" on the toolbar.
Post can be edited for a short time - select the CODE and then hit that icon.

 

[BriComp]

You could use a capacitor to drive the solenoid. Charge the solenoid through a resistor (gives just enough current to hold solenoid in place).
Then when you fire the drum stick the initial drive current comes from the capacitor, followed by a much lower holding current through the resistor.

 

[defragster]

Interesting how this happens? Is the NoteOff missed or somehow lost? Or is there something latching the pin ON when it was commanded to drop to OFF?

Watchdog is critical when the sketch can HANG somehow. Not sure there is a hang of any sort involved, but just a problem telling the solenoid to go off.

In the case some or all of the code is still running it might be that the watchdog still gets 'FED' so it won't cause the restart and the long powered solenoid could persist.

Thought here is every 'Solenoid ON' command maps through a function that records the active HIGH state and the Time. Then have a 'Monitor' function that scans all the recorded solenoid states and sends out a LOW command to any that have been on longer than some few seconds, and then marks it OFF the active list. If it really is hanging then this won't help but the watchdog should. This periodically called function could 'Feed' the watchdog - so if it fails then it would restart.

 

[Neelwell2]

Interesting how this happens? Is the NoteOff missed or somehow lost? Or is there something latching the pin ON when it was commanded to drop to OFF?

Watchdog is critical when the sketch can HANG somehow. Not sure there is a hang of any sort involved, but just a problem telling the solenoid to go off.

In the case some or all of the code is still running it might be that the watchdog still gets 'FED' so it won't cause the restart and the long powered solenoid could persist.

Thought here is every 'Solenoid ON' command maps through a function that records the active HIGH state and the Time. Then have a 'Monitor' function that scans all the recorded solenoid states and sends out a LOW command to any that have been on longer than some few seconds, and then marks it OFF the active list. If it really is hanging then this won't help but the watchdog should. This periodically called function could 'Feed' the watchdog - so if it fails then it would restart.

That sonnds like what i need, Like i said in my post, when i unplug the teensy, from the computer, the solenoid shuts off and restarts , i am not a code creator, any guidance on how to do this would be helpful. thank you so much.