Console/printf issues with .Net usage

[SamMarrocco]

While doing some debugging of C Code that I was planning to run on a KFlop thread, I encountered a discrepency. I've thinned out everything about the code down to the core....

The C Code is as follows:

#include "KMotionDef.h"
main()
{
printf("Starting........\n");
int a;
for (a = 1; a <= 10000; a++)
{
printf("Hello %d\n",a);
}
printf("Completed.\n");
}

If this code is placed into KMotion's C Program editor, compiled, downloaded and run, it display as expected, albeit slowly. After approximately 30 seconds, the last of the 10,000 lines print and "Completed" is displayed.

If the same code is sent to the KFlop from my vb.net application, the code compiles, downloads, and runs, sending the console output (as expected) to the visual studio environment output window. The console is displayed by reading the value in the Controller.MessageReceived Event and printing it to the output window of VS.Net. However, the output stops at the 1272nd line, and never displays 'completed'.

I first came upon this when I noticed that my debugging info (all printf()'s) were only outputting to the VS environment for a very brief time after they started. It doesn't necessarily seem to be a "buffer filling" type of issue; more of one where the console output is ignored after a brief time after the C program begins executing.

Any thoughts?

[TomKerekes]

Hi Sam,

I just tested the C# .NET example SimpleFormsCS.exe from Version 4.35e and I don't see a problem. I ran it 3 times:

You might compare your method with the method used by SimpleFormsCS.

A common mistake is to create more than one callback event handler. ie every time the Console is updated rather than once for the application.

Another is to not use a mutex and have thread safe issues with different Threads receiving the messages and another Thread displaying the messages. See ConsoleMutex in the example.

[SamMarrocco]

Based on what you tested, I did the same and had the same results. The SimpleFormsCS.exe app was able to display the entire loop of output from my c app without stopping short.

So I began to explore what you suggested in that it might be a threading issues. Here is what I found....

My vb.net app's form is set up with
Public WithEvents ThisController As New KM_Controller
Shared ConsoleMutex As New Mutex 'Mutex cannot be declared as Static at the form level in vb.net, but can in C#.

The MessageReceived method in that form then looks like this:

Private Function MyController_MessageReceived(message As String) As Integer Handles ThisController.MessageReceived
ConsoleMutex.WaitOne()
Console.WriteLine(message)
ConsoleMutex.ReleaseMutex()
End Function

So it shouldn't be an issue of creating more than one callback event handler.

Adding the mutex as I saw it in the SimpleFormsCS.exe code doesn't seem to make any difference. As before, the console returns some messages, then stops.

So I explored the SimpleFormsCS code a bit more. As an experiment, I removed all the mutex statements from SimpleFormsCS and the code still ran fine, returning everything from the KFlop C loop.

I then tried changing your ConsoleMessageHandler callback, emptying it of everything except a single line, adding
Console.Writeline(message);
....to determine if the problem was in the visual studio console as opposed to the textbox you were using to append message string.

Still no issue--the SimpleFormsCS code returns the entire loop to the console as promised.

It seems like, if nothing else, the SimpleFormsCS code would have behaved the same (stopping after a few seconds like mine) if the problem had been the lack of mutex locks.....?

As always, I appreciate any thought you have on this.

[TomKerekes]

Hi Sam,

btw does your program always stop on the same number 1272?

You might check if KFLOP thinks it sent all the lines. Does the Thread complete (green bar goes away on KMotion.exe's C Program Screen).

You might add a line of code as:

Code: Select all

ch7->Position=s;

Then look at the KMotion.exe Axis Screen channel 7 position to observe the value of a.

I'm not very familiar with VB. There is surely some way to have mutexes. I see Rick uses them in his Chip CNC Program. Search for "Mutex".

Threading issues are unpredictable depending on timing. A problem only occurs if one Thread would be in the middle of modifying some data and gets preempted and another Thread modifies the same data resulting in something lost or corrupted.

For unsolicited console messages to be received by the PC a data request must be requested from KFLOP. In that case, if KFLOP has any console messages to be sent, it responds with the messages before sending the requested data. So if your App stops requesting data from KFLOP it won't receive any more console messages. Normally every App does some type of status updates for messages to be received.

You might want to debug it to see what is happening. Set a break point in KMotionServer.exe process in KMotionServerMain.cpp on the line:

Code: Select all

		while (!ConsoleList[board].IsEmpty() && nSent++<10)

[SamMarrocco]

-No, the program does not always stop on the same number, but it *is* always between 1000 and 2000.
-Interestingly enough, the greenbar in KMotion's UI sometimes goes away somewhere between 1000 and 2000 as well, and the thread continues running (as evidenced by the counting continuing afterwords until the loop is complete. KMotion seems to think the thread has completed (by the green bar disappearing) earlier than the thread has actually finished. Could this be because the thread has actually completed, and the KMotion UI is still updating for some time afterwards (buffering)?

Yes, VB does have Mutexes; I only meant to point out that the mutex could not be static and 'form-level' as you had yours in the C# code. Apparently this is a known difference between the two languages. That said, adding the Mutex didn't seem to make any difference; neither did removing the mutexes from your code. I would have thought your app would show the same issue with them removed. Perhaps that isn't the case. Totally understand the unpredicability of threading code--everytime I think I've threaded something properly I learn something new

I'll look into your your suggestioms about using a channel to return the C loop value...

[TomKerekes]

Yes there is buffering in KFLOP (256 lines) and KMotionServer (Infinity). If the green light goes out then the C Program completed.

[SamMarrocco]

Got it. That explains why the green light goes 'off' but the text continues for a while.
Incidentally, that green light is helpful for debugging. Is there a dotnet method of checking the state of a thread like the green light shows?

I'm going to try a very minimal app to narrow this issue down...

[TomKerekes]

See here.

[SamMarrocco]

I have minimized a test application down for simpler debugging without any multiple processes running. I'm getting interesting results that aren't quite making a lot of sense yet, but I thought I'd include them. Maybe a light will go on at some point in my head. I've attached the test app with comments.

Adding the mutex as I have (surrounding the console.writeline statement in the controller.messagereceived event) does not seem to make any difference.

What is interesting is that if I add a timer to the form that checks controller.threadexecuting() property every so often, the output continues all the way to the end as desired. That 'check' seems to 'bump' the form thread in some way that continues checking the message pump. If I make the timer interval several seconds, the output from the console will work, then pause until the next tick and call the .threadexecuting. Then it runs for a bit again until the next tick.

This behavior has all the unpredictable hallmarks of threading issues. I'll keep placing my results here in case it helps anyone in the future.

[TomKerekes]

Sounds like what I tried to explain earlier:

For unsolicited console messages to be received by the PC a data request must be requested from KFLOP. In that case, if KFLOP has any console messages to be sent, it responds with the messages before sending the requested data. So if your App stops requesting data from KFLOP it won't receive any more console messages. Normally every App does some type of status updates for messages to be received.