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 ) ?

Simplify 3d serial data reads m105 blank after a while
when it should read received

Repetier-Host Just states commands waiting 1
m140

I'm at a complete loss I'm still searching though but I would love to hear your thoughts

The host software is waiting for confirmation that the command is complete so if it can't be performed the setup will just hang.

it appears serial communication stops after a while

Any ideas?

It appears it's an issue with repetier-host. I notice after 10 to 20 seconds it would say command waiting on the bottom and it would prevent me from selecting anything else.

I tried this in simpilify 3d and it worked just fine so I believe something went wrong when I updated Reptier-Host.

I'll uninstall the program and all reg files and reinstall them to see if this does the trick.

Windows (of current supported versions; Vista, 7, 8 32/64 variants) support 250,000 just fine. You just select it as the baud rate *inside* repetier-host. Sounds to me like you're poking in device properties on the Virtual COM Port itself ? just guessing though.

Anyway, works fine on the two dozen or so win boxes I've fudged with lately -  you can progmatically open COM Sockets at 250,000 - the device manager 'speeds' relate to the low-level stuff within Windows and not the speed that the port is actually opened at.

I only set it in RH under the printer config.

If you can't work it out and it is a baud issue, you could always recompile the firmware at 128,000 to match.

I'm doing some research on changing this on windows since I can't change it through the device manager any higher.

Any thoughts would be greatly appreciated

When I connect to my ramps 1.4 board
the thermistors read correctly for about 10 to 20 seconds then they freeze.

Any ideas on what could cause this?