I've frequently had my app just hang after a re-connect. If I stop the debugger after the hang, it is ALWAYS at the point indicated by ==> below:

public string WriteLineReadLine(string command)
{
string response = "";
try
{
MarshalPre(ref response);
KM_dotnet_Interop_WriteLineReadLine(_InstanceHandle, _BoardNumber, command, ref response);
==>MarshalPost(ref response);
}

What does this mean? I can't step or otherwise continue from this point. I never see this without a disconnect/reconnect. I have to assume it's being influenced by something in my app, since I can't get it to happen with my connection test app. But I have no idea how to pin down the root cause, since it all works fine as long as I don't go through (usually multiple) connect/disconnect cycles.

I'm also seeing typical turn-around times for UpdateMainStatus() averaging 15 mSec, as measured using this code:

Stopwatch Watch = new Stopwatch();
Watch.Reset();
Watch.Start();

KMController.UpdateMainStatus();

Watch.Stop();
Console.WriteLine("UpdateStatus: " + Watch.ElapsedMilliseconds + "\n");

The range of numbers I see is from a low of 2-3mSec, to a high of about 30mSec. Isn't this awfully high? You've both told me it should be 1-2mSec, but I almost never see it that low. Running my minimal connection test app, I see similar, though slightly shorter, times, though there is more variability there.

Regards,
Ray L.

OK, I thought you had both indicated typical was lower.

In trying to pin down the connection hang, I've discovered something interesting. There seems to be an interaction between KM_Controller.Connected and KM_Controller.CheckIsReady(). As I reported yesterday, I can pretty easily get it in a state where Connected is true, but CheckIsReady is stuck false, until I disconnect. I've if'd out nearly everything in my app except the connection logic, and I frequently find Connected does NOT go false when I pull the cable. And, when this happens, I also do not get the disconnect dialog from KMotion. I added a Console.WriteLine to show me my internal connection state, and the state of Connected, and the failure is highly repeatable. But, if I ALSO invoke CheckIsReady(), even though I don't USE the value returned, it seems to always behave correctly. So it appears Connected does not get properly updated under all circumstance UNLESS CheckIsReady() is invoked periodically. Does that make any sense? Does it give any clues to what's going on here?

Also, when the hang occurs, there is a little green arrow next to the line indicated below, stating that that line is NEXT to be executed when the CPU returns from wherever it currently is. So it appears to be hanging within the WriteLineReadLine DLL call.

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> I don't think that sounds too high at all. 2-3 ms may be the theoretical
> round trip time, but once you add the non-deterministic Windows timing and
> the interop I think an average of 15 ms is excellent performance.
>
>
>
> -Brad Murry
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> Behalf Of himykabibble
> Sent: Thursday, January 26, 2012 10:41 AM
> To: DynoMotion@yahoogroups.com
> Subject: [DynoMotion] Hanging In dotNet
>
>
>
>
>
> I've frequently had my app just hang after a re-connect. If I stop the
> debugger after the hang, it is ALWAYS at the point indicated by ==> below:
>
> public string WriteLineReadLine(string command)
> {
> string response = "";
> try
> {
> MarshalPre(ref response);
> KM_dotnet_Interop_WriteLineReadLine(_InstanceHandle, _BoardNumber, command,
> ref response);
> ==>MarshalPost(ref response);
> }
>
> What does this mean? I can't step or otherwise continue from this point. I
> never see this without a disconnect/reconnect. I have to assume it's being
> influenced by something in my app, since I can't get it to happen with my
> connection test app. But I have no idea how to pin down the root cause,
> since it all works fine as long as I don't go through (usually multiple)
> connect/disconnect cycles.
>
> I'm also seeing typical turn-around times for UpdateMainStatus() averaging
> 15 mSec, as measured using this code:
>
> Stopwatch Watch = new Stopwatch();
> Watch.Reset();
> Watch.Start();
>
> KMController.UpdateMainStatus();
>
> Watch.Stop();
> Console.WriteLine("UpdateStatus: " + Watch.ElapsedMilliseconds + "\n");
>
> The range of numbers I see is from a low of 2-3mSec, to a high of about
> 30mSec. Isn't this awfully high? You've both told me it should be 1-2mSec,
> but I almost never see it that low. Running my minimal connection test app,
> I see similar, though slightly shorter, times, though there is more
> variability there.
>
> Regards,
> Ray L.
>

And.... The exception coming out of KMController.Dispose() is absolutely 100% consistent, even in my minimal connection test app.

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> OK, I thought you had both indicated typical was lower.
>
> In trying to pin down the connection hang, I've discovered something interesting. There seems to be an interaction between KM_Controller.Connected and KM_Controller.CheckIsReady(). As I reported yesterday, I can pretty easily get it in a state where Connected is true, but CheckIsReady is stuck false, until I disconnect. I've if'd out nearly everything in my app except the connection logic, and I frequently find Connected does NOT go false when I pull the cable. And, when this happens, I also do not get the disconnect dialog from KMotion. I added a Console.WriteLine to show me my internal connection state, and the state of Connected, and the failure is highly repeatable. But, if I ALSO invoke CheckIsReady(), even though I don't USE the value returned, it seems to always behave correctly. So it appears Connected does not get properly updated under all circumstance UNLESS CheckIsReady() is invoked periodically. Does that make any sense? Does it give any clues to what's going on here?
>
> Also, when the hang occurs, there is a little green arrow next to the line indicated below, stating that that line is NEXT to be executed when the CPU returns from wherever it currently is. So it appears to be hanging within the WriteLineReadLine DLL call.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@> wrote:
> >
> > I don't think that sounds too high at all. 2-3 ms may be the theoretical
> > round trip time, but once you add the non-deterministic Windows timing and
> > the interop I think an average of 15 ms is excellent performance.
> >
> >
> >
> > -Brad Murry
> >
> >
> >
> > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> > Behalf Of himykabibble
> > Sent: Thursday, January 26, 2012 10:41 AM
> > To: DynoMotion@yahoogroups.com
> > Subject: [DynoMotion] Hanging In dotNet
> >
> >
> >
> >
> >
> > I've frequently had my app just hang after a re-connect. If I stop the
> > debugger after the hang, it is ALWAYS at the point indicated by ==> below:
> >
> > public string WriteLineReadLine(string command)
> > {
> > string response = "";
> > try
> > {
> > MarshalPre(ref response);
> > KM_dotnet_Interop_WriteLineReadLine(_InstanceHandle, _BoardNumber, command,
> > ref response);
> > ==>MarshalPost(ref response);
> > }
> >
> > What does this mean? I can't step or otherwise continue from this point. I
> > never see this without a disconnect/reconnect. I have to assume it's being
> > influenced by something in my app, since I can't get it to happen with my
> > connection test app. But I have no idea how to pin down the root cause,
> > since it all works fine as long as I don't go through (usually multiple)
> > connect/disconnect cycles.
> >
> > I'm also seeing typical turn-around times for UpdateMainStatus() averaging
> > 15 mSec, as measured using this code:
> >
> > Stopwatch Watch = new Stopwatch();
> > Watch.Reset();
> > Watch.Start();
> >
> > KMController.UpdateMainStatus();
> >
> > Watch.Stop();
> > Console.WriteLine("UpdateStatus: " + Watch.ElapsedMilliseconds + "\n");
> >
> > The range of numbers I see is from a low of 2-3mSec, to a high of about
> > 30mSec. Isn't this awfully high? You've both told me it should be 1-2mSec,
> > but I almost never see it that low. Running my minimal connection test app,
> > I see similar, though slightly shorter, times, though there is more
> > variability there.
> >
> > Regards,
> > Ray L.
> >
>

It appears to me something, perhaps in the DLL, is getting whacked. When the board re-connects, I download and run my init code, then initialize some I/Os and Persist Vars. One of the things that gets done is to initialize the spindle controls - turning off both relays, and setting the PWM to zero. Setting the PWM is done by running my SpindlePWM program on thread 2. The new PWM value comes, in part, from values stored in Persist vars 90-92 (for SWord, SSO, and actual spindle RPM). The connection hang is coming from a call to read the SSO word using WriteLineReadLine passing the String "GetPersistDec 92". This var IS initialized before this call is made. On the initial connection after my app is started, it works correctly every time. After a disconnect/reconnect it goes into KM_dotnet_Interop_WriteLineReadLine(_InstanceHandle, _BoardNumber, command, ref response); and never returns. If I comment out that one line, then I get an completely bogus error when I try to run the SpindlePWM program, telling me it couldn't find the file ". That is a single double-quote. The path being passed into CompileAndRunCoff is absolutely valid: @"C:\My KFLop C Programs\KMotionCNC\KMotionCNCSpindlePWM.c".

I'm stuck....

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> OK, I thought you had both indicated typical was lower.
>
> In trying to pin down the connection hang, I've discovered something interesting. There seems to be an interaction between KM_Controller.Connected and KM_Controller.CheckIsReady(). As I reported yesterday, I can pretty easily get it in a state where Connected is true, but CheckIsReady is stuck false, until I disconnect. I've if'd out nearly everything in my app except the connection logic, and I frequently find Connected does NOT go false when I pull the cable. And, when this happens, I also do not get the disconnect dialog from KMotion. I added a Console.WriteLine to show me my internal connection state, and the state of Connected, and the failure is highly repeatable. But, if I ALSO invoke CheckIsReady(), even though I don't USE the value returned, it seems to always behave correctly. So it appears Connected does not get properly updated under all circumstance UNLESS CheckIsReady() is invoked periodically. Does that make any sense? Does it give any clues to what's going on here?
>
> Also, when the hang occurs, there is a little green arrow next to the line indicated below, stating that that line is NEXT to be executed when the CPU returns from wherever it currently is. So it appears to be hanging within the WriteLineReadLine DLL call.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@> wrote:
> >
> > I don't think that sounds too high at all. 2-3 ms may be the theoretical
> > round trip time, but once you add the non-deterministic Windows timing and
> > the interop I think an average of 15 ms is excellent performance.
> >
> >
> >
> > -Brad Murry
> >
> >
> >
> > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> > Behalf Of himykabibble
> > Sent: Thursday, January 26, 2012 10:41 AM
> > To: DynoMotion@yahoogroups.com
> > Subject: [DynoMotion] Hanging In dotNet
> >
> >
> >
> >
> >
> > I've frequently had my app just hang after a re-connect. If I stop the
> > debugger after the hang, it is ALWAYS at the point indicated by ==> below:
> >
> > public string WriteLineReadLine(string command)
> > {
> > string response = "";
> > try
> > {
> > MarshalPre(ref response);
> > KM_dotnet_Interop_WriteLineReadLine(_InstanceHandle, _BoardNumber, command,
> > ref response);
> > ==>MarshalPost(ref response);
> > }
> >
> > What does this mean? I can't step or otherwise continue from this point. I
> > never see this without a disconnect/reconnect. I have to assume it's being
> > influenced by something in my app, since I can't get it to happen with my
> > connection test app. But I have no idea how to pin down the root cause,
> > since it all works fine as long as I don't go through (usually multiple)
> > connect/disconnect cycles.
> >
> > I'm also seeing typical turn-around times for UpdateMainStatus() averaging
> > 15 mSec, as measured using this code:
> >
> > Stopwatch Watch = new Stopwatch();
> > Watch.Reset();
> > Watch.Start();
> >
> > KMController.UpdateMainStatus();
> >
> > Watch.Stop();
> > Console.WriteLine("UpdateStatus: " + Watch.ElapsedMilliseconds + "\n");
> >
> > The range of numbers I see is from a low of 2-3mSec, to a high of about
> > 30mSec. Isn't this awfully high? You've both told me it should be 1-2mSec,
> > but I almost never see it that low. Running my minimal connection test app,
> > I see similar, though slightly shorter, times, though there is more
> > variability there.
> >
> > Regards,
> > Ray L.
> >
>

Brad,

I am about to post a dead simple test program that reliably induces this issue about one time out of 3 or so. It will be in my folder in the Files section in a few minutes. If you run, and disconnect/reconnect the board a few times, you'll find after 2-4 disconnects, the app simply hangs. If you interrupt it, it will be on that line with the DLL call I pointed out earlier every time. Note that at this point the board is fine - you can kill and re-start the app without re-connecting the board, and all is well.

BTW - I do NOT have anything else running - just the test app itself.

Hopefully this will enable you and Tom to kill this bug.

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> I do occasionally get this as well (hanging on a card call), and I believe
> only when KMotion.exe or KMCNC.exe is running as well. I think someone else
> is getting a token and being selfish with it maybe?
>
>
>
>
>
> I have also had instances where the MotionServer will stay in the processes
> and cannot be killed, resulting in the need of a CPU reboot.
>
>
>
> It does appear to work under normal conditions though..
>
>
>
>
>
> -Brad
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> Behalf Of himykabibble
> Sent: Thursday, January 26, 2012 12:36 PM
> To: DynoMotion@yahoogroups.com
> Subject: [DynoMotion] Re: Hanging In dotNet
>
>
>
>
>
> It appears to me something, perhaps in the DLL, is getting whacked. When the
> board re-connects, I download and run my init code, then initialize some
> I/Os and Persist Vars. One of the things that gets done is to initialize the
> spindle controls - turning off both relays, and setting the PWM to zero.
> Setting the PWM is done by running my SpindlePWM program on thread 2. The
> new PWM value comes, in part, from values stored in Persist vars 90-92 (for
> SWord, SSO, and actual spindle RPM). The connection hang is coming from a
> call to read the SSO word using WriteLineReadLine passing the String
> "GetPersistDec 92". This var IS initialized before this call is made. On the
> initial connection after my app is started, it works correctly every time.
> After a disconnect/reconnect it goes into
> KM_dotnet_Interop_WriteLineReadLine(_InstanceHandle, _BoardNumber, command,
> ref response); and never returns. If I comment out that one line, then I get
> an completely bogus error when I try to run the SpindlePWM program, telling
> me it couldn't find the file ". That is a single double-quote. The path
> being passed into CompileAndRunCoff is absolutely valid: @"C:\My KFLop C
> Programs\KMotionCNC\KMotionCNCSpindlePWM.c".
>
> I'm stuck....
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> "himykabibble" <jagboy@> wrote:
> >
> > OK, I thought you had both indicated typical was lower.
> >
> > In trying to pin down the connection hang, I've discovered something
> interesting. There seems to be an interaction between
> KM_Controller.Connected and KM_Controller.CheckIsReady(). As I reported
> yesterday, I can pretty easily get it in a state where Connected is true,
> but CheckIsReady is stuck false, until I disconnect. I've if'd out nearly
> everything in my app except the connection logic, and I frequently find
> Connected does NOT go false when I pull the cable. And, when this happens, I
> also do not get the disconnect dialog from KMotion. I added a
> Console.WriteLine to show me my internal connection state, and the state of
> Connected, and the failure is highly repeatable. But, if I ALSO invoke
> CheckIsReady(), even though I don't USE the value returned, it seems to
> always behave correctly. So it appears Connected does not get properly
> updated under all circumstance UNLESS CheckIsReady() is invoked
> periodically. Does that make any sense? Does it give any clues to what's
> going on here?
> >
> > Also, when the hang occurs, there is a little green arrow next to the line
> indicated below, stating that that line is NEXT to be executed when the CPU
> returns from wherever it currently is. So it appears to be hanging within
> the WriteLineReadLine DLL call.
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> Brad Murry <bradodarb@> wrote:
> > >
> > > I don't think that sounds too high at all. 2-3 ms may be the theoretical
> > > round trip time, but once you add the non-deterministic Windows timing
> and
> > > the interop I think an average of 15 ms is excellent performance.
> > >
> > >
> > >
> > > -Brad Murry
> > >
> > >
> > >
> > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ]
> On
> > > Behalf Of himykabibble
> > > Sent: Thursday, January 26, 2012 10:41 AM
> > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > Subject: [DynoMotion] Hanging In dotNet
> > >
> > >
> > >
> > >
> > >
> > > I've frequently had my app just hang after a re-connect. If I stop the
> > > debugger after the hang, it is ALWAYS at the point indicated by ==>
> below:
> > >
> > > public string WriteLineReadLine(string command)
> > > {
> > > string response = "";
> > > try
> > > {
> > > MarshalPre(ref response);
> > > KM_dotnet_Interop_WriteLineReadLine(_InstanceHandle, _BoardNumber,
> command,
> > > ref response);
> > > ==>MarshalPost(ref response);
> > > }
> > >
> > > What does this mean? I can't step or otherwise continue from this point.
> I
> > > never see this without a disconnect/reconnect. I have to assume it's
> being
> > > influenced by something in my app, since I can't get it to happen with
> my
> > > connection test app. But I have no idea how to pin down the root cause,
> > > since it all works fine as long as I don't go through (usually multiple)
> > > connect/disconnect cycles.
> > >
> > > I'm also seeing typical turn-around times for UpdateMainStatus()
> averaging
> > > 15 mSec, as measured using this code:
> > >
> > > Stopwatch Watch = new Stopwatch();
> > > Watch.Reset();
> > > Watch.Start();
> > >
> > > KMController.UpdateMainStatus();
> > >
> > > Watch.Stop();
> > > Console.WriteLine("UpdateStatus: " + Watch.ElapsedMilliseconds + "\n");
> > >
> > > The range of numbers I see is from a low of 2-3mSec, to a high of about
> > > 30mSec. Isn't this awfully high? You've both told me it should be
> 1-2mSec,
> > > but I almost never see it that low. Running my minimal connection test
> app,
> > > I see similar, though slightly shorter, times, though there is more
> > > variability there.
> > >
> > > Regards,
> > > Ray L.
> > >
> >
>

OK, it's there...

--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> Brad,
>
> I am about to post a dead simple test program that reliably induces this issue about one time out of 3 or so. It will be in my folder in the Files section in a few minutes. If you run, and disconnect/reconnect the board a few times, you'll find after 2-4 disconnects, the app simply hangs. If you interrupt it, it will be on that line with the DLL call I pointed out earlier every time. Note that at this point the board is fine - you can kill and re-start the app without re-connecting the board, and all is well.
>
> BTW - I do NOT have anything else running - just the test app itself.
>
> Hopefully this will enable you and Tom to kill this bug.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@> wrote:
> >
> > I do occasionally get this as well (hanging on a card call), and I believe
> > only when KMotion.exe or KMCNC.exe is running as well. I think someone else
> > is getting a token and being selfish with it maybe?
> >
> >
> >
> >
> >
> > I have also had instances where the MotionServer will stay in the processes
> > and cannot be killed, resulting in the need of a CPU reboot.
> >
> >
> >
> > It does appear to work under normal conditions though..
> >
> >
> >
> >
> >
> > -Brad
> >
> >
> >
> > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> > Behalf Of himykabibble
> > Sent: Thursday, January 26, 2012 12:36 PM
> > To: DynoMotion@yahoogroups.com
> > Subject: [DynoMotion] Re: Hanging In dotNet
> >
> >
> >
> >
> >
> > It appears to me something, perhaps in the DLL, is getting whacked. When the
> > board re-connects, I download and run my init code, then initialize some
> > I/Os and Persist Vars. One of the things that gets done is to initialize the
> > spindle controls - turning off both relays, and setting the PWM to zero.
> > Setting the PWM is done by running my SpindlePWM program on thread 2. The
> > new PWM value comes, in part, from values stored in Persist vars 90-92 (for
> > SWord, SSO, and actual spindle RPM). The connection hang is coming from a
> > call to read the SSO word using WriteLineReadLine passing the String
> > "GetPersistDec 92". This var IS initialized before this call is made. On the
> > initial connection after my app is started, it works correctly every time.
> > After a disconnect/reconnect it goes into
> > KM_dotnet_Interop_WriteLineReadLine(_InstanceHandle, _BoardNumber, command,
> > ref response); and never returns. If I comment out that one line, then I get
> > an completely bogus error when I try to run the SpindlePWM program, telling
> > me it couldn't find the file ". That is a single double-quote. The path
> > being passed into CompileAndRunCoff is absolutely valid: @"C:\My KFLop C
> > Programs\KMotionCNC\KMotionCNCSpindlePWM.c".
> >
> > I'm stuck....
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> > "himykabibble" <jagboy@> wrote:
> > >
> > > OK, I thought you had both indicated typical was lower.
> > >
> > > In trying to pin down the connection hang, I've discovered something
> > interesting. There seems to be an interaction between
> > KM_Controller.Connected and KM_Controller.CheckIsReady(). As I reported
> > yesterday, I can pretty easily get it in a state where Connected is true,
> > but CheckIsReady is stuck false, until I disconnect. I've if'd out nearly
> > everything in my app except the connection logic, and I frequently find
> > Connected does NOT go false when I pull the cable. And, when this happens, I
> > also do not get the disconnect dialog from KMotion. I added a
> > Console.WriteLine to show me my internal connection state, and the state of
> > Connected, and the failure is highly repeatable. But, if I ALSO invoke
> > CheckIsReady(), even though I don't USE the value returned, it seems to
> > always behave correctly. So it appears Connected does not get properly
> > updated under all circumstance UNLESS CheckIsReady() is invoked
> > periodically. Does that make any sense? Does it give any clues to what's
> > going on here?
> > >
> > > Also, when the hang occurs, there is a little green arrow next to the line
> > indicated below, stating that that line is NEXT to be executed when the CPU
> > returns from wherever it currently is. So it appears to be hanging within
> > the WriteLineReadLine DLL call.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> > Brad Murry <bradodarb@> wrote:
> > > >
> > > > I don't think that sounds too high at all. 2-3 ms may be the theoretical
> > > > round trip time, but once you add the non-deterministic Windows timing
> > and
> > > > the interop I think an average of 15 ms is excellent performance.
> > > >
> > > >
> > > >
> > > > -Brad Murry
> > > >
> > > >
> > > >
> > > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ]
> > On
> > > > Behalf Of himykabibble
> > > > Sent: Thursday, January 26, 2012 10:41 AM
> > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > > Subject: [DynoMotion] Hanging In dotNet
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I've frequently had my app just hang after a re-connect. If I stop the
> > > > debugger after the hang, it is ALWAYS at the point indicated by ==>
> > below:
> > > >
> > > > public string WriteLineReadLine(string command)
> > > > {
> > > > string response = "";
> > > > try
> > > > {
> > > > MarshalPre(ref response);
> > > > KM_dotnet_Interop_WriteLineReadLine(_InstanceHandle, _BoardNumber,
> > command,
> > > > ref response);
> > > > ==>MarshalPost(ref response);
> > > > }
> > > >
> > > > What does this mean? I can't step or otherwise continue from this point.
> > I
> > > > never see this without a disconnect/reconnect. I have to assume it's
> > being
> > > > influenced by something in my app, since I can't get it to happen with
> > my
> > > > connection test app. But I have no idea how to pin down the root cause,
> > > > since it all works fine as long as I don't go through (usually multiple)
> > > > connect/disconnect cycles.
> > > >
> > > > I'm also seeing typical turn-around times for UpdateMainStatus()
> > averaging
> > > > 15 mSec, as measured using this code:
> > > >
> > > > Stopwatch Watch = new Stopwatch();
> > > > Watch.Reset();
> > > > Watch.Start();
> > > >
> > > > KMController.UpdateMainStatus();
> > > >
> > > > Watch.Stop();
> > > > Console.WriteLine("UpdateStatus: " + Watch.ElapsedMilliseconds + "\n");
> > > >
> > > > The range of numbers I see is from a low of 2-3mSec, to a high of about
> > > > 30mSec. Isn't this awfully high? You've both told me it should be
> > 1-2mSec,
> > > > but I almost never see it that low. Running my minimal connection test
> > app,
> > > > I see similar, though slightly shorter, times, though there is more
> > > > variability there.
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > >
> >
>

Equally, if not more, interesting: If you comment out the following three lines in my test program:

SetPersistVarAsFloat((int)PersistVars.PERSIST_SPINDLE_SWORD, (float)rpm);
Double SSO = GetPersistVarAsFloat((int)PersistVars.PERSIST_SPINDLE_SSO);
Double SpindleActualRPM = rpm * SSO / 100.0;
/SetPersistVarAsFloat((int)PersistVars.SPINDLE_PWM_VAR, (float)SpindleActualRPM);

Then the following compile/link will fail, with the error message about not being able to find the file named ".

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> Brad,
>
> I am about to post a dead simple test program that reliably induces this issue about one time out of 3 or so. It will be in my folder in the Files section in a few minutes. If you run, and disconnect/reconnect the board a few times, you'll find after 2-4 disconnects, the app simply hangs. If you interrupt it, it will be on that line with the DLL call I pointed out earlier every time. Note that at this point the board is fine - you can kill and re-start the app without re-connecting the board, and all is well.
>
> BTW - I do NOT have anything else running - just the test app itself.
>
> Hopefully this will enable you and Tom to kill this bug.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@> wrote:
> >
> > I do occasionally get this as well (hanging on a card call), and I believe
> > only when KMotion.exe or KMCNC.exe is running as well. I think someone else
> > is getting a token and being selfish with it maybe?
> >
> >
> >
> >
> >
> > I have also had instances where the MotionServer will stay in the processes
> > and cannot be killed, resulting in the need of a CPU reboot.
> >
> >
> >
> > It does appear to work under normal conditions though..
> >
> >
> >
> >
> >
> > -Brad
> >
> >
> >
> > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> > Behalf Of himykabibble
> > Sent: Thursday, January 26, 2012 12:36 PM
> > To: DynoMotion@yahoogroups.com
> > Subject: [DynoMotion] Re: Hanging In dotNet
> >
> >
> >
> >
> >
> > It appears to me something, perhaps in the DLL, is getting whacked. When the
> > board re-connects, I download and run my init code, then initialize some
> > I/Os and Persist Vars. One of the things that gets done is to initialize the
> > spindle controls - turning off both relays, and setting the PWM to zero.
> > Setting the PWM is done by running my SpindlePWM program on thread 2. The
> > new PWM value comes, in part, from values stored in Persist vars 90-92 (for
> > SWord, SSO, and actual spindle RPM). The connection hang is coming from a
> > call to read the SSO word using WriteLineReadLine passing the String
> > "GetPersistDec 92". This var IS initialized before this call is made. On the
> > initial connection after my app is started, it works correctly every time.
> > After a disconnect/reconnect it goes into
> > KM_dotnet_Interop_WriteLineReadLine(_InstanceHandle, _BoardNumber, command,
> > ref response); and never returns. If I comment out that one line, then I get
> > an completely bogus error when I try to run the SpindlePWM program, telling
> > me it couldn't find the file ". That is a single double-quote. The path
> > being passed into CompileAndRunCoff is absolutely valid: @"C:\My KFLop C
> > Programs\KMotionCNC\KMotionCNCSpindlePWM.c".
> >
> > I'm stuck....
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> > "himykabibble" <jagboy@> wrote:
> > >
> > > OK, I thought you had both indicated typical was lower.
> > >
> > > In trying to pin down the connection hang, I've discovered something
> > interesting. There seems to be an interaction between
> > KM_Controller.Connected and KM_Controller.CheckIsReady(). As I reported
> > yesterday, I can pretty easily get it in a state where Connected is true,
> > but CheckIsReady is stuck false, until I disconnect. I've if'd out nearly
> > everything in my app except the connection logic, and I frequently find
> > Connected does NOT go false when I pull the cable. And, when this happens, I
> > also do not get the disconnect dialog from KMotion. I added a
> > Console.WriteLine to show me my internal connection state, and the state of
> > Connected, and the failure is highly repeatable. But, if I ALSO invoke
> > CheckIsReady(), even though I don't USE the value returned, it seems to
> > always behave correctly. So it appears Connected does not get properly
> > updated under all circumstance UNLESS CheckIsReady() is invoked
> > periodically. Does that make any sense? Does it give any clues to what's
> > going on here?
> > >
> > > Also, when the hang occurs, there is a little green arrow next to the line
> > indicated below, stating that that line is NEXT to be executed when the CPU
> > returns from wherever it currently is. So it appears to be hanging within
> > the WriteLineReadLine DLL call.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> > Brad Murry <bradodarb@> wrote:
> > > >
> > > > I don't think that sounds too high at all. 2-3 ms may be the theoretical
> > > > round trip time, but once you add the non-deterministic Windows timing
> > and
> > > > the interop I think an average of 15 ms is excellent performance.
> > > >
> > > >
> > > >
> > > > -Brad Murry
> > > >
> > > >
> > > >
> > > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ]
> > On
> > > > Behalf Of himykabibble
> > > > Sent: Thursday, January 26, 2012 10:41 AM
> > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > > Subject: [DynoMotion] Hanging In dotNet
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I've frequently had my app just hang after a re-connect. If I stop the
> > > > debugger after the hang, it is ALWAYS at the point indicated by ==>
> > below:
> > > >
> > > > public string WriteLineReadLine(string command)
> > > > {
> > > > string response = "";
> > > > try
> > > > {
> > > > MarshalPre(ref response);
> > > > KM_dotnet_Interop_WriteLineReadLine(_InstanceHandle, _BoardNumber,
> > command,
> > > > ref response);
> > > > ==>MarshalPost(ref response);
> > > > }
> > > >
> > > > What does this mean? I can't step or otherwise continue from this point.
> > I
> > > > never see this without a disconnect/reconnect. I have to assume it's
> > being
> > > > influenced by something in my app, since I can't get it to happen with
> > my
> > > > connection test app. But I have no idea how to pin down the root cause,
> > > > since it all works fine as long as I don't go through (usually multiple)
> > > > connect/disconnect cycles.
> > > >
> > > > I'm also seeing typical turn-around times for UpdateMainStatus()
> > averaging
> > > > 15 mSec, as measured using this code:
> > > >
> > > > Stopwatch Watch = new Stopwatch();
> > > > Watch.Reset();
> > > > Watch.Start();
> > > >
> > > > KMController.UpdateMainStatus();
> > > >
> > > > Watch.Stop();
> > > > Console.WriteLine("UpdateStatus: " + Watch.ElapsedMilliseconds + "\n");
> > > >
> > > > The range of numbers I see is from a low of 2-3mSec, to a high of about
> > > > 30mSec. Isn't this awfully high? You've both told me it should be
> > 1-2mSec,
> > > > but I almost never see it that low. Running my minimal connection test
> > app,
> > > > I see similar, though slightly shorter, times, though there is more
> > > > variability there.
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > >
> >
>