--- In DynoMotion@yahoogroups.com, Tom Kerekes wrote:
>
> Hi Ray,
>
> Yeah finding the guy who can't find the token doesn't help identify the guy who stole it.
>
> I can't think of an easy way without writing diagnostic code.  Maybe you could change all the places that call WaitToken to pass a unique wait time as a sort of ID.Then save or log the times somewhere.
>
> Regards
> TK
>
>
>
> ________________________________
> From: himykabibble
> To: DynoMotion@yahoogroups.com
> Sent: Friday, January 18, 2013 1:21 PM
> Subject: [DynoMotion] Re: Interpreter.Interpret
>
>
>  
> Tom,
>
> Yup. In my code, there's only one place I ever get the token, and that's as part of a PCComm call, which can't be happening here. So, it has to be getting lost inside dotNet, perhaps when the disconnect happens? It's hanging on the line:
> ok = cload_sect_data(s)
> right at the end of cload_data(), called from the line:
>
> result = !cload_headers() || !cload_symbols() || !cload_data();
>
> in cload(); That probably doesn't help....
>
> How can I figure out where the lock is getting lost?
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes wrote:
> >
> > Hi Ray,
> >
> > The obvious thing would be that someplace the Token is obtained and never released.
> >
> > Regards
> > TK
> >
> >
> >
> > ________________________________
> > From: himykabibble
> > To: DynoMotion@yahoogroups.com
> > Sent: Friday, January 18, 2013 1:06 PM
> > Subject: [DynoMotion] Re: Interpreter.Interpret
> >
> >
> >  
> > Man! I hate it when this happens! I set out to debug this, and now it's doing something different! When I try to load the Init program following a re-connect, it's hanging in a call to WaitToken, made from within KM_dotnet_Interop_CompileAndLoadCoff. What could I be doing that would cause that? It never happens on the first connect.
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes wrote:
> > >
> > > Hi Ray,
> > >
> > > I can't think of any.  Obviously you can normally run multiple MDI commands without doing any special re-initialization.
> > >
> > > Regards
> > > TK 
> > >
> > >
> > >
> > > ________________________________
> > > From: himykabibble
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Friday, January 18, 2013 10:45 AM
> > > Subject: [DynoMotion] Re: Interpreter.Interpret
> > >
> > >
> > >  
> > > Tom,
> > >
> > > I have the full VS2008. I'll see if I can figure out how to do that.
> > >
> > > Is there some initialization I should have to do after a re-connect? I do not re-create the Controller, CoordMotion or Interpreter objects, nor the KM_IO object. I just re-do my own initialization of their properties, exactly as I do on first connect.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com, Tom Kerekes wrote:
> > > >
> > > > Hi Ray,
> > > >
> > > > I would just break with VS and switch to the Interpreter Thread to see where it is and what it is waiting for.ÃÆ'‚  But I'm not sure if you can do that with only the Express Version of VS.
> > > >
> > > > Regards
> > > > TK
> > > >
> > > >
> > > >
> > > >
> > > > ________________________________
> > > > From: himykabibble
> > > > To: DynoMotion@yahoogroups.com
> > > > Sent: Thursday, January 17, 2013 10:45 PM
> > > > Subject: [DynoMotion] Interpreter.Interpret
> > > >
> > > >
> > > > ÃÆ'‚ 
> > > > Tom,
> > > >
> > > > I'm down to one last bug that really has me stumped. My app starts up properly first time, every time, whether the board is connected or not. If not connected, it waits until the board is plugged in and initialized, correctly detects its presence, connects and initializes everything it needs to, and the app works properly. If the board is then unplugged, it detects this disconnect, E-Stops, and waits for it to return. When the board is again plugged in, it is again detected and initialized, *except* it hangs at the very end of the app initialization. Almost the last thing in my initialization is running an MDI line to set some default modal states. The call to Interpreter.Interpret does no throw any exceptions, yet I never get the InterpreterDone callback, which I use to know when the initialization is done. If I break into the debugger when it's hung, and FORCE it to think the Interpreter has completed, then all is well, and the app works as
> it
> > > > should.
> > > >
> > > > Is there anything you can think of that could cause the Interpreter to accept a G-code file without complaint, but then NOT execute it correctly, and issue the Done callback? ALL of the initialization code is identical for the first connection, and the second one, yet the second one ALWAYS fails in the manner described above. Since I'm not getting any exceptions or other error indications, I'm stumped as to how to go any further.
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > >
> >
>

--- In DynoMotion@yahoogroups.com, "himykabibble" wrote:
>
> Tom,
>
> Since we know the board has been disconnected and re-connected, is there any way I can force a "reset" of everything - basically a re-boot of KMotion and dotNet so they will forget there ever was a lock?
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes wrote:
> >
> > Hi Ray,
> >
> > Yeah finding the guy who can't find the token doesn't help identify the guy who stole it.
> >
> > I can't think of an easy way without writing diagnostic code.  Maybe you could change all the places that call WaitToken to pass a unique wait time as a sort of ID.Then save or log the times somewhere.
> >
> > Regards
> > TK
> >
> >
> >
> > ________________________________
> > From: himykabibble
> > To: DynoMotion@yahoogroups.com
> > Sent: Friday, January 18, 2013 1:21 PM
> > Subject: [DynoMotion] Re: Interpreter.Interpret
> >
> >
> >  
> > Tom,
> >
> > Yup. In my code, there's only one place I ever get the token, and that's as part of a PCComm call, which can't be happening here. So, it has to be getting lost inside dotNet, perhaps when the disconnect happens? It's hanging on the line:
> > ok = cload_sect_data(s)
> > right at the end of cload_data(), called from the line:
> >
> > result = !cload_headers() || !cload_symbols() || !cload_data();
> >
> > in cload(); That probably doesn't help....
> >
> > How can I figure out where the lock is getting lost?
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes wrote:
> > >
> > > Hi Ray,
> > >
> > > The obvious thing would be that someplace the Token is obtained and never released.
> > >
> > > Regards
> > > TK
> > >
> > >
> > >
> > > ________________________________
> > > From: himykabibble
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Friday, January 18, 2013 1:06 PM
> > > Subject: [DynoMotion] Re: Interpreter.Interpret
> > >
> > >
> > >  
> > > Man! I hate it when this happens! I set out to debug this, and now it's doing something different! When I try to load the Init program following a re-connect, it's hanging in a call to WaitToken, made from within KM_dotnet_Interop_CompileAndLoadCoff. What could I be doing that would cause that? It never happens on the first connect.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com, Tom Kerekes wrote:
> > > >
> > > > Hi Ray,
> > > >
> > > > I can't think of any.  Obviously you can normally run multiple MDI commands without doing any special re-initialization.
> > > >
> > > > Regards
> > > > TK 
> > > >
> > > >
> > > >
> > > > ________________________________
> > > > From: himykabibble
> > > > To: DynoMotion@yahoogroups.com
> > > > Sent: Friday, January 18, 2013 10:45 AM
> > > > Subject: [DynoMotion] Re: Interpreter.Interpret
> > > >
> > > >
> > > >  
> > > > Tom,
> > > >
> > > > I have the full VS2008. I'll see if I can figure out how to do that.
> > > >
> > > > Is there some initialization I should have to do after a re-connect? I do not re-create the Controller, CoordMotion or Interpreter objects, nor the KM_IO object. I just re-do my own initialization of their properties, exactly as I do on first connect.
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes wrote:
> > > > >
> > > > > Hi Ray,
> > > > >
> > > > > I would just break with VS and switch to the Interpreter Thread to see where it is and what it is waiting for.ÃÆ'‚  But I'm not sure if you can do that with only the Express Version of VS.
> > > > >
> > > > > Regards
> > > > > TK
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ________________________________
> > > > > From: himykabibble
> > > > > To: DynoMotion@yahoogroups.com
> > > > > Sent: Thursday, January 17, 2013 10:45 PM
> > > > > Subject: [DynoMotion] Interpreter.Interpret
> > > > >
> > > > >
> > > > > ÃÆ'‚ 
> > > > > Tom,
> > > > >
> > > > > I'm down to one last bug that really has me stumped. My app starts up properly first time, every time, whether the board is connected or not. If not connected, it waits until the board is plugged in and initialized, correctly detects its presence, connects and initializes everything it needs to, and the app works properly. If the board is then unplugged, it detects this disconnect, E-Stops, and waits for it to return. When the board is again plugged in, it is again detected and initialized, *except* it hangs at the very end of the app initialization. Almost the last thing in my initialization is running an MDI line to set some default modal states. The call to Interpreter.Interpret does no throw any exceptions, yet I never get the InterpreterDone callback, which I use to know when the initialization is done. If I break into the debugger when it's hung, and FORCE it to think the Interpreter has completed, then all is well, and the app works as
> > it
> > > > > should.
> > > > >
> > > > > Is there anything you can think of that could cause the Interpreter to accept a G-code file without complaint, but then NOT execute it correctly, and issue the Done callback? ALL of the initialization code is identical for the first connection, and the second one, yet the second one ALWAYS fails in the manner described above. Since I'm not getting any exceptions or other error indications, I'm stumped as to how to go any further.
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > >
> > >
> >
>

--- In DynoMotion@yahoogroups.com, "himykabibble" wrote:
>
> Tom,
>
> Perusing the dotNet code, I came across the method below, which seems suspect to me. Is it not possible for "action.Invoke()" to throw an exception, which would leave the lock hung?
>
> public bool CheckConnected(params Action[] actions)
> {
> var result = WaitToken(100);
> var conected = result != KMOTION_TOKEN.KMOTION_NOT_CONNECTED;
> if (result == KMOTION_TOKEN.KMOTION_LOCKED)
> {
> foreach (var action in actions)
> {
> action.Invoke();
> }
> ReleaseToken();
> }
> return conected;
> }
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, "himykabibble" wrote:
> >
> > Tom,
> >
> > Since we know the board has been disconnected and re-connected, is there any way I can force a "reset" of everything - basically a re-boot of KMotion and dotNet so they will forget there ever was a lock?
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes wrote:
> > >
> > > Hi Ray,
> > >
> > > Yeah finding the guy who can't find the token doesn't help identify the guy who stole it.
> > >
> > > I can't think of an easy way without writing diagnostic code.  Maybe you could change all the places that call WaitToken to pass a unique wait time as a sort of ID.Then save or log the times somewhere.
> > >
> > > Regards
> > > TK
> > >
> > >
> > >
> > > ________________________________
> > > From: himykabibble
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Friday, January 18, 2013 1:21 PM
> > > Subject: [DynoMotion] Re: Interpreter.Interpret
> > >
> > >
> > >  
> > > Tom,
> > >
> > > Yup. In my code, there's only one place I ever get the token, and that's as part of a PCComm call, which can't be happening here. So, it has to be getting lost inside dotNet, perhaps when the disconnect happens? It's hanging on the line:
> > > ok = cload_sect_data(s)
> > > right at the end of cload_data(), called from the line:
> > >
> > > result = !cload_headers() || !cload_symbols() || !cload_data();
> > >
> > > in cload(); That probably doesn't help....
> > >
> > > How can I figure out where the lock is getting lost?
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com, Tom Kerekes wrote:
> > > >
> > > > Hi Ray,
> > > >
> > > > The obvious thing would be that someplace the Token is obtained and never released.
> > > >
> > > > Regards
> > > > TK
> > > >
> > > >
> > > >
> > > > ________________________________
> > > > From: himykabibble
> > > > To: DynoMotion@yahoogroups.com
> > > > Sent: Friday, January 18, 2013 1:06 PM
> > > > Subject: [DynoMotion] Re: Interpreter.Interpret
> > > >
> > > >
> > > >  
> > > > Man! I hate it when this happens! I set out to debug this, and now it's doing something different! When I try to load the Init program following a re-connect, it's hanging in a call to WaitToken, made from within KM_dotnet_Interop_CompileAndLoadCoff. What could I be doing that would cause that? It never happens on the first connect.
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes wrote:
> > > > >
> > > > > Hi Ray,
> > > > >
> > > > > I can't think of any.  Obviously you can normally run multiple MDI commands without doing any special re-initialization.
> > > > >
> > > > > Regards
> > > > > TK 
> > > > >
> > > > >
> > > > >
> > > > > ________________________________
> > > > > From: himykabibble
> > > > > To: DynoMotion@yahoogroups.com
> > > > > Sent: Friday, January 18, 2013 10:45 AM
> > > > > Subject: [DynoMotion] Re: Interpreter.Interpret
> > > > >
> > > > >
> > > > >  
> > > > > Tom,
> > > > >
> > > > > I have the full VS2008. I'll see if I can figure out how to do that.
> > > > >
> > > > > Is there some initialization I should have to do after a re-connect? I do not re-create the Controller, CoordMotion or Interpreter objects, nor the KM_IO object. I just re-do my own initialization of their properties, exactly as I do on first connect.
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes wrote:
> > > > > >
> > > > > > Hi Ray,
> > > > > >
> > > > > > I would just break with VS and switch to the Interpreter Thread to see where it is and what it is waiting for.ÃÆ'‚  But I'm not sure if you can do that with only the Express Version of VS.
> > > > > >
> > > > > > Regards
> > > > > > TK
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > ________________________________
> > > > > > From: himykabibble
> > > > > > To: DynoMotion@yahoogroups.com
> > > > > > Sent: Thursday, January 17, 2013 10:45 PM
> > > > > > Subject: [DynoMotion] Interpreter.Interpret
> > > > > >
> > > > > >
> > > > > > ÃÆ'‚ 
> > > > > > Tom,
> > > > > >
> > > > > > I'm down to one last bug that really has me stumped. My app starts up properly first time, every time, whether the board is connected or not. If not connected, it waits until the board is plugged in and initialized, correctly detects its presence, connects and initializes everything it needs to, and the app works properly. If the board is then unplugged, it detects this disconnect, E-Stops, and waits for it to return. When the board is again plugged in, it is again detected and initialized, *except* it hangs at the very end of the app initialization. Almost the last thing in my initialization is running an MDI line to set some default modal states. The call to Interpreter.Interpret does no throw any exceptions, yet I never get the InterpreterDone callback, which I use to know when the initialization is done. If I break into the debugger when it's hung, and FORCE it to think the Interpreter has completed, then all is well, and the app works as
> > > it
> > > > > > should.
> > > > > >
> > > > > > Is there anything you can think of that could cause the Interpreter to accept a G-code file without complaint, but then NOT execute it correctly, and issue the Done callback? ALL of the initialization code is identical for the first connection, and the second one, yet the second one ALWAYS fails in the manner described above. Since I'm not getting any exceptions or other error indications, I'm stumped as to how to go any further.
> > > > > >
> > > > > > Regards,
> > > > > > Ray L.
> > > > > >
> > > > >
> > > >
> > >
> >
>