DebugPrintf does not always write to the window in RT environment, but there's a catch.

[DieselPower]

I have diagnostic DebugPrintf messages running in a real time environment which should output at 1 Hz.  The funny thing is that they will start to output and then stop.  If I put a breakpoint on line of code that has the DebugPrintf function call and quickly execute it when it breaks so as to not interrupt all of the running threads it will ALWAYS output that message.  What is it about normal (fast) execution that doesn't get the message through?

[AustinStanton]

Hey Michael

Could you please give a little bit more context on your issue, what is happening when you don't put a breakpoint on the line? 

Thank you

Austin Stanton

[DieselPower]

The message I have set to go to the Debug Output window does not go there like it should.  I set this diagnostic message up to determine why my TCP messages aren't going to my Windows system.  They would stop so I added a breakpoint to see if the execution was hitting this spot and then bam, there's my Debug message.  At this moment if I clear the debug window it will show 3-4 of these messages without recognizing the \r\n that is clearly in the string builder then stop.  If I clear the window it will do it again.  Meanwhile the TCP message is transferring because I have a diagnostic message on the Windows end as well.

	sprintf(messageSafeties, "%sEND\r\n", messageSafeties);
	DebugPrintf("%s", messageSafeties);
	TCPWriteMessageString(messageSafeties);

This message should be written at 1 Hz.You can see that, despite the existence of \r\n it is not breaking and only writes 4 messages before stopping.My windows program is receiving the TCP messages at 1 Hz.

[DieselPower]

Does DebugPrintf only print 256 characters?  The help file does not list a maximum.