Thermistors stop reading after about 10 to 20 seconds

M105 is get extruder temp.

The code that does reacts to this is:

    case 105 : // M105
      if(setTargetedHotend(105)){
        break;
        }
      #if defined(TEMP_0_PIN) && TEMP_0_PIN > -1
        SERIAL_PROTOCOLPGM("ok T:");
        SERIAL_PROTOCOL_F(degHotend(tmp_extruder),1);
        SERIAL_PROTOCOLPGM(" /");
        SERIAL_PROTOCOL_F(degTargetHotend(tmp_extruder),1);
        #if defined(TEMP_BED_PIN) && TEMP_BED_PIN > -1
          SERIAL_PROTOCOLPGM(" B:");
          SERIAL_PROTOCOL_F(degBed(),1);
          SERIAL_PROTOCOLPGM(" /");
          SERIAL_PROTOCOL_F(degTargetBed(),1);
        #endif //TEMP_BED_PIN
        for (int8_t cur_extruder = 0; cur_extruder < EXTRUDERS; ++cur_extruder) {
          SERIAL_PROTOCOLPGM(" T");
          SERIAL_PROTOCOL(cur_extruder);
          SERIAL_PROTOCOLPGM(":");
          SERIAL_PROTOCOL_F(degHotend(cur_extruder),1);
          SERIAL_PROTOCOLPGM(" /");
          SERIAL_PROTOCOL_F(degTargetHotend(cur_extruder),1);
        }
      #else
        SERIAL_ERROR_START;
        SERIAL_ERRORLNPGM(MSG_ERR_NO_THERMISTORS);
      #endif

        SERIAL_PROTOCOLPGM(" @:");
        SERIAL_PROTOCOL(getHeaterPower(tmp_extruder));

        SERIAL_PROTOCOLPGM(" B@:");
        SERIAL_PROTOCOL(getHeaterPower(-1));

        SERIAL_PROTOCOLLN("");
      return;
      break;

It really doesn't do anything much at all, except call degHotend(extruder-number) and degTargetHotend(extruder-number) and write some serial (which in this instance as its written to a hardware uart its non-blocking - meaning it wont cause pauses - only the calling of SERIAL actually has a computational load - not the act of writing it itself, if that makes sense.).

DegHotend then goes and simply reads the thermistor by way of doing an analog_read() on the respective Temp_Pin, then mapping that result to the Thermistor_tables to spit out an integer.

Nutshell; Its not doing anything heavy lifting wise, and even if you had thermistors disconnected, it wouldn't hang, it would just respond with null.

So the M105 is a bit of red-herring here I'm going to offer.

Now, M140,  is "Bed Heat Fast"... it also does relatively little either.. literally all it does is set the PID Setpoint variable for the bed heater to the specified temp, and then returns. Because Marlin is built as a 'state machine', this does nothing for the rest of the execution loop, and next pass through the loop when it hits 'bed pid' it will cause the PID StateMachine for the Bed to start trying to reach setpoint because it now sees that the TargetBedTemp is > CurrentBedTemp. Now when the Thermistor Reading is > TempSetpoint-30°, it will actually run in traditional 'Bang-Bang mode' which means it will just turn on solid. Only once the temp is at < TempSetpoint-30° does the PID StateMachine wake-up again and start PID driving the heater.

If either of the above two are going to cause potential issues, its the M140 .. and even then.....

So back to basics. If you turn on BEDPID, turn it off again - download a fresh firmware thats unmodified just set the motherboard correctly and compile - do you resolve the issue (points to code problem, or problem with the code edits you did)?

If that doesn't work - Is the Bed Heater MOSFET turning on as soon as the M140 command is issued? If its not - then theres again something wrong with the code - even a cooked MOSFET wont cause the M140 to fail.. so I tend to lean to the first suggestion.

Finally - can you zip up your firmware and post it somewhere - I can then have a look at your Configuration.h a bit closer for you? And can you confirm you are seeing the "23:10:42.161 : FIRMWARE_NAME:Marlin V1; Sprinter/grbl mashup for gen6 FIRMWARE_URL:http://github.com/mlaws/solidoodle2-marlin/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:OrdBot EXTRUDER_COUNT:1
" or similar message on startup (obviously you wont see OrdBot on yours ) ?