Hi Brad/Ray,
That code is basically correct but not really used in the same manner as in KMotionCNC.
Unfortunately there is probably no easy and 100% reliable method to determine if the board is connected. This is because the board can connect or disconnect at any time. So by the time we checked it might have already changed. Also because we want to allow multiple applications or threads to have access to the single USB driver there is a blocking and server mechanism. This means that is someone is being a hog then it might take a long time to get access to the USB driver to determine the status. With a timeout on the request it becomes unclear whether the board is present or not. Some other App might be being a hog, or even if everybody plays by the rules Windows might be doing something funny to cause the timeout. Maybe there is a better way.
The WaitToken has 3 possible return codes:
KMOTION_NOT_CONNECTED - this means we got access to the Server and it told us the board is not present
KMOTION_LOCKED - this means we got access to the Server, the board is present, Everybody else is being held off so we can use it
KMOTION_IN_USE - this is poorly named. It really means we couldn't get the board locked for possibly a variety of reasons in the time specified.
Calling WaitToken with no timeout should always return in a few seconds max with NOT_CONNECTED or LOCKED (unless somebody never releases the Token).
The code below seems inefficient in that we have waited up to 100ms to get our place in the queue and blocked everybody else to get the Token, but then immediately give it back without using it.
KMotionCNC uses the code below, but if it gets the token it reads the MAIN_STATUS and updates all the screens, otherwise it just skips updating the screens with the assumption it is better to have old data on the screens rather than have the GUI non responsive at times.
Somehow KMotionCNC and KMotion both side step the issue by not really caring if the board is connected or not as they don't try to do anything to the board until somehow instructed by the user to do something. When the User commands something to happen it assumes the board is present and starts issuing commands. This is most efficient in the normal case we most care about. If the board is not present then we get an error anyway which could be handled in the same manner as if we somehow knew the command wouldn't work beforehand (with the exception that the Libraries currently displays an error which I agree should be optional).
But after saying all that I don't exactly understand the result Ray is getting.
I'm open for suggestions on how to do things better, but all the above complexity should be considered before we start making changes. Or maybe add some parallel mechanism to augment the functionality?
Regards
TK
| Group: DynoMotion |
Message: 3247 |
From: Brad Murry |
Date: 1/21/2012 |
| Subject: Re: KM_Controller.Connected |
Hello Tom, Off the top of my head, it seems that error callbacks as we have discussed would handle the situation nicely. The API could have three modes:: 1) Message windows (current mehavior) 2) Callbacks (which would route to .net event handlers as the other callbacks do) 3) Both This way I could just set the connected property in the event handler. -Brad Murry From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
Sent: Saturday, January 21, 2012 3:42 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Re: KM_Controller.Connected That code is basically correct but not really used in the same manner as in KMotionCNC. Unfortunately there is probably no easy and 100% reliable method to determine if the board is connected. This is because the board can connect or disconnect at any time. So by the time we checked it might have already changed. Also because we want to allow multiple applications or threads to have access to the single USB driver there is a blocking and server mechanism. This means that is someone is being a hog then it might take a long time to get access to the USB driver to determine the status. With a timeout on the request it becomes unclear whether the board is present or not. Some other App might be being a hog, or even if everybody plays by the rules Windows might be doing something funny to cause the timeout. Maybe there is a better way. The WaitToken has 3 possible return codes: KMOTION_NOT_CONNECTED - this means we got access to the Server and it told us the board is not present KMOTION_LOCKED - this means we got access to the Server, the board is present, Everybody else is being held off so we can use it KMOTION_IN_USE - this is poorly named. It really means we couldn't get the board locked for possibly a variety of reasons in the time specified. Calling WaitToken with no timeout should always return in a few seconds max with NOT_CONNECTED or LOCKED (unless somebody never releases the Token). The code below seems inefficient in that we have waited up to 100ms to get our place in the queue and blocked everybody else to get the Token, but then immediately give it back without using it. KMotionCNC uses the code below, but if it gets the token it reads the MAIN_STATUS and updates all the screens, otherwise it just skips updating the screens with the assumption it is better to have old data on the screens rather than have the GUI non responsive at times. Somehow KMotionCNC and KMotion both side step the issue by not really caring if the board is connected or not as they don't try to do anything to the board until somehow instructed by the user to do something. When the User commands something to happen it assumes the board is present and starts issuing commands. This is most efficient in the normal case we most care about. If the board is not present then we get an error anyway which could be handled in the same manner as if we somehow knew the command wouldn't work beforehand (with the exception that the Libraries currently displays an error which I agree should be optional). But after saying all that I don't exactly understand the result Ray is getting. I'm open for suggestions on how to do things better, but all the above complexity should be considered before we start making changes. Or maybe add some parallel mechanism to augment the functionality?
Ray,
This is the code for the Connected property::
public bool Connected
{
get
{
var result = WaitToken(100);
_Connected = result != KMOTION_TOKEN.KMOTION_NOT_CONNECTED;
if (result == KMOTION_TOKEN.KMOTION_LOCKED)
{
ReleaseToken();
}
return _Connected;
}
}
It should be the same method that KMotionCNC uses, as Tom directed me how to implement it.
Tom, does it look right or did I miss something?
-Brad Murry
--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> Brad,
>
> This seems odd to me. The behavior noted below is 100% consistent. If, however, I include a call to IsReady(), then Connected behaves correctly. Although, I do not consistently get the KMotion MessageBox telling me the connection has gone missing. Shouldn't Connected give the correct response, even in the absence of any other communications?
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> >
> > Brad,
> >
> > I seem to have run face first into a problem that makes no sense to me. I have a method that simply returns KM_Controller.Connected. If no board is connected when my app starts, this returns false. If I then plug the board in, after it initialized, Connected flips to true. If I then unplug the board, Connected remains true! This is with v428, a new board, which is freshly flashed with v428 FW.
> >
> > Regards,
> > Ray L.
> >
>
|
|
| Group: DynoMotion |
Message: 3248 |
From: Tom Kerekes |
Date: 1/21/2012 |
| Subject: Re: KM_Controller.Connected |
Hi Brad,
Good point I agree. I will try to add that. It might not be easy because a lot of errors are generated in a separate Windows Process (KMotionServer), but I think the messages can just be piped back to the calling process.
But if you only set the status in the callback it would always be disconnected. I guess you mean to periodically test it most likely with the attempt to get Main_Status and if successful set it connected.
Regards
TK
| Group: DynoMotion |
Message: 3279 |
From: Brad Murry |
Date: 1/22/2012 |
| Subject: Re: KM_Controller.Connected |
I am adding a CheckConnected(delegate void) member to the Kmotion_dotNet libs. This way it will lock the board, execute the delegate (function pointer) and then release the lock. I think this will provide a mechanism to all something useful to happen while the lock is in place and is closer to what KMCNC is doing. So basically you would pass it a delegate pointer to your GUI update method. Thoughts? -Brad Murry From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
Sent: Saturday, January 21, 2012 3:42 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Re: KM_Controller.Connected That code is basically correct but not really used in the same manner as in KMotionCNC. Unfortunately there is probably no easy and 100% reliable method to determine if the board is connected. This is because the board can connect or disconnect at any time. So by the time we checked it might have already changed. Also because we want to allow multiple applications or threads to have access to the single USB driver there is a blocking and server mechanism. This means that is someone is being a hog then it might take a long time to get access to the USB driver to determine the status. With a timeout on the request it becomes unclear whether the board is present or not. Some other App might be being a hog, or even if everybody plays by the rules Windows might be doing something funny to cause the timeout. Maybe there is a better way. The WaitToken has 3 possible return codes: KMOTION_NOT_CONNECTED - this means we got access to the Server and it told us the board is not present KMOTION_LOCKED - this means we got access to the Server, the board is present, Everybody else is being held off so we can use it KMOTION_IN_USE - this is poorly named. It really means we couldn't get the board locked for possibly a variety of reasons in the time specified. Calling WaitToken with no timeout should always return in a few seconds max with NOT_CONNECTED or LOCKED (unless somebody never releases the Token). The code below seems inefficient in that we have waited up to 100ms to get our place in the queue and blocked everybody else to get the Token, but then immediately give it back without using it. KMotionCNC uses the code below, but if it gets the token it reads the MAIN_STATUS and updates all the screens, otherwise it just skips updating the screens with the assumption it is better to have old data on the screens rather than have the GUI non responsive at times. Somehow KMotionCNC and KMotion both side step the issue by not really caring if the board is connected or not as they don't try to do anything to the board until somehow instructed by the user to do something. When the User commands something to happen it assumes the board is present and starts issuing commands. This is most efficient in the normal case we most care about. If the board is not present then we get an error anyway which could be handled in the same manner as if we somehow knew the command wouldn't work beforehand (with the exception that the Libraries currently displays an error which I agree should be optional). But after saying all that I don't exactly understand the result Ray is getting. I'm open for suggestions on how to do things better, but all the above complexity should be considered before we start making changes. Or maybe add some parallel mechanism to augment the functionality?
Ray,
This is the code for the Connected property::
public bool Connected
{
get
{
var result = WaitToken(100);
_Connected = result != KMOTION_TOKEN.KMOTION_NOT_CONNECTED;
if (result == KMOTION_TOKEN.KMOTION_LOCKED)
{
ReleaseToken();
}
return _Connected;
}
}
It should be the same method that KMotionCNC uses, as Tom directed me how to implement it.
Tom, does it look right or did I miss something?
-Brad Murry
--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> Brad,
>
> This seems odd to me. The behavior noted below is 100% consistent. If, however, I include a call to IsReady(), then Connected behaves correctly. Although, I do not consistently get the KMotion MessageBox telling me the connection has gone missing. Shouldn't Connected give the correct response, even in the absence of any other communications?
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> >
> > Brad,
> >
> > I seem to have run face first into a problem that makes no sense to me. I have a method that simply returns KM_Controller.Connected. If no board is connected when my app starts, this returns false. If I then plug the board in, after it initialized, Connected flips to true. If I then unplug the board, Connected remains true! This is with v428, a new board, which is freshly flashed with v428 FW.
> >
> > Regards,
> > Ray L.
> >
>
|
|
| Group: DynoMotion |
Message: 3281 |
From: himykabibble |
Date: 1/22/2012 |
| Subject: Re: KM_Controller.Connected |
Brad,
Anything that makes it easier to reliably detect connect/disconnect events sounds good to me!
Regards,
Ray L.
--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> I am adding a CheckConnected(delegate void) member to the Kmotion_dotNet libs.
>
>
>
> This way it will lock the board, execute the delegate (function pointer) and then release the lock.
>
>
>
> I think this will provide a mechanism to all something useful to happen while the lock is in place and is closer to what KMCNC is doing.
>
>
>
> So basically you would pass it a delegate pointer to your GUI update method.
>
>
>
>
>
> Thoughts?
>
>
>
> -Brad Murry
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> Sent: Saturday, January 21, 2012 3:42 PM
> To: DynoMotion@yahoogroups.com
> Subject: Re: [DynoMotion] Re: KM_Controller.Connected
>
>
>
>
>
> Hi Brad/Ray,
>
>
>
> That code is basically correct but not really used in the same manner as in KMotionCNC.
>
>
>
> Unfortunately there is probably no easy and 100% reliable method to determine if the board is connected. This is because the board can connect or disconnect at any time. So by the time we checked it might have already changed. Also because we want to allow multiple applications or threads to have access to the single USB driver there is a blocking and server mechanism. This means that is someone is being a hog then it might take a long time to get access to the USB driver to determine the status. With a timeout on the request it becomes unclear whether the board is present or not. Some other App might be being a hog, or even if everybody plays by the rules Windows might be doing something funny to cause the timeout. Maybe there is a better way.
>
>
>
> The WaitToken has 3 possible return codes:
>
>
>
> KMOTION_NOT_CONNECTED - this means we got access to the Server and it told us the board is not present
>
> KMOTION_LOCKED - this means we got access to the Server, the board is present, Everybody else is being held off so we can use it
>
> KMOTION_IN_USE - this is poorly named. It really means we couldn't get the board locked for possibly a variety of reasons in the time specified.
>
>
>
> Calling WaitToken with no timeout should always return in a few seconds max with NOT_CONNECTED or LOCKED (unless somebody never releases the Token).
>
>
>
> The code below seems inefficient in that we have waited up to 100ms to get our place in the queue and blocked everybody else to get the Token, but then immediately give it back without using it.
>
>
>
> KMotionCNC uses the code below, but if it gets the token it reads the MAIN_STATUS and updates all the screens, otherwise it just skips updating the screens with the assumption it is better to have old data on the screens rather than have the GUI non responsive at times.
>
>
>
> Somehow KMotionCNC and KMotion both side step the issue by not really caring if the board is connected or not as they don't try to do anything to the board until somehow instructed by the user to do something. When the User commands something to happen it assumes the board is present and starts issuing commands. This is most efficient in the normal case we most care about. If the board is not present then we get an error anyway which could be handled in the same manner as if we somehow knew the command wouldn't work beforehand (with the exception that the Libraries currently displays an error which I agree should be optional).
>
>
>
> But after saying all that I don't exactly understand the result Ray is getting.
>
>
>
> I'm open for suggestions on how to do things better, but all the above complexity should be considered before we start making changes. Or maybe add some parallel mechanism to augment the functionality?
>
>
>
> Regards
>
> TK
>
>
>
>
>
>
>
>
>
>
>
> From: bradodarb <bradodarb@...>
> To: DynoMotion@yahoogroups.com
> Sent: Saturday, January 21, 2012 1:24 PM
> Subject: [DynoMotion] Re: KM_Controller.Connected
>
>
>
>
>
>
> Ray,
>
> This is the code for the Connected property::
>
> public bool Connected
> {
> get
> {
> var result = WaitToken(100);
> _Connected = result != KMOTION_TOKEN.KMOTION_NOT_CONNECTED;
> if (result == KMOTION_TOKEN.KMOTION_LOCKED)
> {
> ReleaseToken();
> }
> return _Connected;
> }
> }
>
> It should be the same method that KMotionCNC uses, as Tom directed me how to implement it.
>
> Tom, does it look right or did I miss something?
>
> -Brad Murry
> --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> , "himykabibble" <jagboy@> wrote:
> >
> > Brad,
> >
> > This seems odd to me. The behavior noted below is 100% consistent. If, however, I include a call to IsReady(), then Connected behaves correctly. Although, I do not consistently get the KMotion MessageBox telling me the connection has gone missing. Shouldn't Connected give the correct response, even in the absence of any other communications?
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> , "himykabibble" <jagboy@> wrote:
> > >
> > > Brad,
> > >
> > > I seem to have run face first into a problem that makes no sense to me. I have a method that simply returns KM_Controller.Connected. If no board is connected when my app starts, this returns false. If I then plug the board in, after it initialized, Connected flips to true. If I then unplug the board, Connected remains true! This is with v428, a new board, which is freshly flashed with v428 FW.
> > >
> > > Regards,
> > > Ray L.
> > >
> >
> |
|
| Group: DynoMotion |
Message: 3285 |
From: Tom Kerekes |
Date: 1/22/2012 |
| Subject: Re: KM_Controller.Connected |
Hi Brad,
Sound good. An alternate solution might be to just leave it locked and return. The caller could (must) then call ReleaseToken if it was Locked.
But you wouldn't want to keep the board locked the whole time you update your GUI screens. Only for the time you need to read the Main_Status (or whatever) up from KFLOP.
Regards
TK
| Group: DynoMotion |
Message: 3288 |
From: Brad Murry |
Date: 1/22/2012 |
| Subject: Re: KM_Controller.Connected |
Well, it should make the connected query more useful, but there is still no disconnect/connect event…… Waiting to see if Tom could consider implementing the callbacks I suggested previously. -Brad Murry From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of himykabibble
Sent: Sunday, January 22, 2012 12:37 PM
To: DynoMotion@yahoogroups.com
Subject: [DynoMotion] Re: KM_Controller.Connected Brad,
Anything that makes it easier to reliably detect connect/disconnect events sounds good to me!
Regards,
Ray L.
--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> I am adding a CheckConnected(delegate void) member to the Kmotion_dotNet libs.
>
>
>
> This way it will lock the board, execute the delegate (function pointer) and then release the lock.
>
>
>
> I think this will provide a mechanism to all something useful to happen while the lock is in place and is closer to what KMCNC is doing.
>
>
>
> So basically you would pass it a delegate pointer to your GUI update method.
>
>
>
>
>
> Thoughts?
>
>
>
> -Brad Murry
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> Sent: Saturday, January 21, 2012 3:42 PM
> To: DynoMotion@yahoogroups.com
> Subject: Re: [DynoMotion] Re: KM_Controller.Connected
>
>
>
>
>
> Hi Brad/Ray,
>
>
>
> That code is basically correct but not really used in the same manner as in KMotionCNC.
>
>
>
> Unfortunately there is probably no easy and 100% reliable method to determine if the board is connected. This is because the board can connect or disconnect at any time. So by the time we checked it might have already changed. Also because we want to allow multiple applications or threads to have access to the single USB driver there is a blocking and server mechanism. This means that is someone is being a hog then it might take a long time to get access to the USB driver to determine the status. With a timeout on the request it becomes unclear whether the board is present or not. Some other App might be being a hog, or even if everybody plays by the rules Windows might be doing something funny to cause the timeout. Maybe there is a better way.
>
>
>
> The WaitToken has 3 possible return codes:
>
>
>
> KMOTION_NOT_CONNECTED - this means we got access to the Server and it told us the board is not present
>
> KMOTION_LOCKED - this means we got access to the Server, the board is present, Everybody else is being held off so we can use it
>
> KMOTION_IN_USE - this is poorly named. It really means we couldn't get the board locked for possibly a variety of reasons in the time specified.
>
>
>
> Calling WaitToken with no timeout should always return in a few seconds max with NOT_CONNECTED or LOCKED (unless somebody never releases the Token).
>
>
>
> The code below seems inefficient in that we have waited up to 100ms to get our place in the queue and blocked everybody else to get the Token, but then immediately give it back without using it.
>
>
>
> KMotionCNC uses the code below, but if it gets the token it reads the MAIN_STATUS and updates all the screens, otherwise it just skips updating the screens with the assumption it is better to have old data on the screens rather than have the GUI non responsive at times.
>
>
>
> Somehow KMotionCNC and KMotion both side step the issue by not really caring if the board is connected or not as they don't try to do anything to the board until somehow instructed by the user to do something. When the User commands something to happen it assumes the board is present and starts issuing commands. This is most efficient in the normal case we most care about. If the board is not present then we get an error anyway which could be handled in the same manner as if we somehow knew the command wouldn't work beforehand (with the exception that the Libraries currently displays an error which I agree should be optional).
>
>
>
> But after saying all that I don't exactly understand the result Ray is getting.
>
>
>
> I'm open for suggestions on how to do things better, but all the above complexity should be considered before we start making changes. Or maybe add some parallel mechanism to augment the functionality?
>
>
>
> Regards
>
> TK
>
>
>
>
>
>
>
>
>
>
>
> From: bradodarb <bradodarb@...>
> To: DynoMotion@yahoogroups.com
> Sent: Saturday, January 21, 2012 1:24 PM
> Subject: [DynoMotion] Re: KM_Controller.Connected
>
>
>
>
>
>
> Ray,
>
> This is the code for the Connected property::
>
> public bool Connected
> {
> get
> {
> var result = WaitToken(100);
> _Connected = result != KMOTION_TOKEN.KMOTION_NOT_CONNECTED;
> if (result == KMOTION_TOKEN.KMOTION_LOCKED)
> {
> ReleaseToken();
> }
> return _Connected;
> }
> }
>
> It should be the same method that KMotionCNC uses, as Tom directed me how to implement it.
>
> Tom, does it look right or did I miss something?
>
> -Brad Murry
> --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> , "himykabibble" <jagboy@> wrote:
> >
> > Brad,
> >
> > This seems odd to me. The behavior noted below is 100% consistent. If, however, I include a call to IsReady(), then Connected behaves correctly. Although, I do not consistently get the KMotion MessageBox telling me the connection has gone missing. Shouldn't Connected give the correct response, even in the absence of any other communications?
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> , "himykabibble" <jagboy@> wrote:
> > >
> > > Brad,
> > >
> > > I seem to have run face first into a problem that makes no sense to me. I have a method that simply returns KM_Controller.Connected. If no board is connected when my app starts, this returns false. If I then plug the board in, after it initialized, Connected flips to true. If I then unplug the board, Connected remains true! This is with v428, a new board, which is freshly flashed with v428 FW.
> > >
> > > Regards,
> > > Ray L.
> > >
> >
> |
|
| Group: DynoMotion |
Message: 3290 |
From: Tom Kerekes |
Date: 1/22/2012 |
| Subject: Re: KM_Controller.Connected |
Hi Brad,
I intend to do that (Error message callbacks), but it will take some time.
Regards
TK
| Group: DynoMotion |
Message: 3292 |
From: Brad Murry |
Date: 1/22/2012 |
| Subject: Re: KM_Controller.Connected |
Hooray!!! Can’t wait Tom! -Brad Murry From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
Sent: Sunday, January 22, 2012 1:08 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Re: KM_Controller.Connected I intend to do that (Error message callbacks), but it will take some time. Well, it should make the connected query more useful, but there is still no disconnect/connect event…… Waiting to see if Tom could consider implementing the callbacks I suggested previously. Brad,
Anything that makes it easier to reliably detect connect/disconnect events sounds good to me!
Regards,
Ray L.
--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> I am adding a CheckConnected(delegate void) member to the Kmotion_dotNet libs.
>
>
>
> This way it will lock the board, execute the delegate (function pointer) and then release the lock.
>
>
>
> I think this will provide a mechanism to all something useful to happen while the lock is in place and is closer to what KMCNC is doing.
>
>
>
> So basically you would pass it a delegate pointer to your GUI update method.
>
>
>
>
>
> Thoughts?
>
>
>
> -Brad Murry
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> Sent: Saturday, January 21, 2012 3:42 PM
> To: DynoMotion@yahoogroups.com
> Subject: Re: [DynoMotion] Re: KM_Controller.Connected
>
>
>
>
>
> Hi Brad/Ray,
>
>
>
> That code is basically correct but not really used in the same manner as in KMotionCNC.
>
>
>
> Unfortunately there is probably no easy and 100% reliable method to determine if the board is connected. This is because the board can connect or disconnect at any time. So by the time we checked it might have already changed. Also because we want to allow multiple applications or threads to have access to the single USB driver there is a blocking and server mechanism. This means that is someone is being a hog then it might take a long time to get access to the USB driver to determine the status. With a timeout on the request it becomes unclear whether the board is present or not. Some other App might be being a hog, or even if everybody plays by the rules Windows might be doing something funny to cause the timeout. Maybe there is a better way.
>
>
>
> The WaitToken has 3 possible return codes:
>
>
>
> KMOTION_NOT_CONNECTED - this means we got access to the Server and it told us the board is not present
>
> KMOTION_LOCKED - this means we got access to the Server, the board is present, Everybody else is being held off so we can use it
>
> KMOTION_IN_USE - this is poorly named. It really means we couldn't get the board locked for possibly a variety of reasons in the time specified.
>
>
>
> Calling WaitToken with no timeout should always return in a few seconds max with NOT_CONNECTED or LOCKED (unless somebody never releases the Token).
>
>
>
> The code below seems inefficient in that we have waited up to 100ms to get our place in the queue and blocked everybody else to get the Token, but then immediately give it back without using it.
>
>
>
> KMotionCNC uses the code below, but if it gets the token it reads the MAIN_STATUS and updates all the screens, otherwise it just skips updating the screens with the assumption it is better to have old data on the screens rather than have the GUI non responsive at times.
>
>
>
> Somehow KMotionCNC and KMotion both side step the issue by not really caring if the board is connected or not as they don't try to do anything to the board until somehow instructed by the user to do something. When the User commands something to happen it assumes the board is present and starts issuing commands. This is most efficient in the normal case we most care about. If the board is not present then we get an error anyway which could be handled in the same manner as if we somehow knew the command wouldn't work beforehand (with the exception that the Libraries currently displays an error which I agree should be optional).
>
>
>
> But after saying all that I don't exactly understand the result Ray is getting.
>
>
>
> I'm open for suggestions on how to do things better, but all the above complexity should be considered before we start making changes. Or maybe add some parallel mechanism to augment the functionality?
>
>
>
> Regards
>
> TK
>
>
>
>
>
>
>
>
>
>
>
> From: bradodarb <bradodarb@...>
> To: DynoMotion@yahoogroups.com
> Sent: Saturday, January 21, 2012 1:24 PM
> Subject: [DynoMotion] Re: KM_Controller.Connected
>
>
>
>
>
>
> Ray,
>
> This is the code for the Connected property::
>
> public bool Connected
> {
> get
> {
> var result = WaitToken(100);
> _Connected = result != KMOTION_TOKEN.KMOTION_NOT_CONNECTED;
> if (result == KMOTION_TOKEN.KMOTION_LOCKED)
> {
> ReleaseToken();
> }
> return _Connected;
> }
> }
>
> It should be the same method that KMotionCNC uses, as Tom directed me how to implement it.
>
> Tom, does it look right or did I miss something?
>
> -Brad Murry
> --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> , "himykabibble" <jagboy@> wrote:
> >
> > Brad,
> >
> > This seems odd to me. The behavior noted below is 100% consistent. If, however, I include a call to IsReady(), then Connected behaves correctly. Although, I do not consistently get the KMotion MessageBox telling me the connection has gone missing. Shouldn't Connected give the correct response, even in the absence of any other communications?
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> , "himykabibble" <jagboy@> wrote:
> > >
> > > Brad,
> > >
> > > I seem to have run face first into a problem that makes no sense to me. I have a method that simply returns KM_Controller.Connected. If no board is connected when my app starts, this returns false. If I then plug the board in, after it initialized, Connected flips to true. If I then unplug the board, Connected remains true! This is with v428, a new board, which is freshly flashed with v428 FW.
> > >
> > > Regards,
> > > Ray L.
> > >
> >
> |
|
| Group: DynoMotion |
Message: 3293 |
From: Brad Murry |
Date: 1/22/2012 |
| Subject: Re: KM_Controller.Connected |
Ok, then maybe I should not implement it then. Get and release lock methods are already exposed on the .net side so maybe we can just leave it to the programmer of the app. GetMainStatus() does lock it. -Brad Murry From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
Sent: Sunday, January 22, 2012 12:50 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Re: KM_Controller.Connected Sound good. An alternate solution might be to just leave it locked and return. The caller could (must) then call ReleaseToken if it was Locked. But you wouldn't want to keep the board locked the whole time you update your GUI screens. Only for the time you need to read the Main_Status (or whatever) up from KFLOP. I am adding a CheckConnected(delegate void) member to the Kmotion_dotNet libs. This way it will lock the board, execute the delegate (function pointer) and then release the lock. I think this will provide a mechanism to all something useful to happen while the lock is in place and is closer to what KMCNC is doing. So basically you would pass it a delegate pointer to your GUI update method. That code is basically correct but not really used in the same manner as in KMotionCNC. Unfortunately there is probably no easy and 100% reliable method to determine if the board is connected. This is because the board can connect or disconnect at any time. So by the time we checked it might have already changed. Also because we want to allow multiple applications or threads to have access to the single USB driver there is a blocking and server mechanism. This means that is someone is being a hog then it might take a long time to get access to the USB driver to determine the status. With a timeout on the request it becomes unclear whether the board is present or not. Some other App might be being a hog, or even if everybody plays by the rules Windows might be doing something funny to cause the timeout. Maybe there is a better way. The WaitToken has 3 possible return codes: KMOTION_NOT_CONNECTED - this means we got access to the Server and it told us the board is not present KMOTION_LOCKED - this means we got access to the Server, the board is present, Everybody else is being held off so we can use it KMOTION_IN_USE - this is poorly named. It really means we couldn't get the board locked for possibly a variety of reasons in the time specified. Calling WaitToken with no timeout should always return in a few seconds max with NOT_CONNECTED or LOCKED (unless somebody never releases the Token). The code below seems inefficient in that we have waited up to 100ms to get our place in the queue and blocked everybody else to get the Token, but then immediately give it back without using it. KMotionCNC uses the code below, but if it gets the token it reads the MAIN_STATUS and updates all the screens, otherwise it just skips updating the screens with the assumption it is better to have old data on the screens rather than have the GUI non responsive at times. Somehow KMotionCNC and KMotion both side step the issue by not really caring if the board is connected or not as they don't try to do anything to the board until somehow instructed by the user to do something. When the User commands something to happen it assumes the board is present and starts issuing commands. This is most efficient in the normal case we most care about. If the board is not present then we get an error anyway which could be handled in the same manner as if we somehow knew the command wouldn't work beforehand (with the exception that the Libraries currently displays an error which I agree should be optional). But after saying all that I don't exactly understand the result Ray is getting. I'm open for suggestions on how to do things better, but all the above complexity should be considered before we start making changes. Or maybe add some parallel mechanism to augment the functionality?
Ray,
This is the code for the Connected property::
public bool Connected
{
get
{
var result = WaitToken(100);
_Connected = result != KMOTION_TOKEN.KMOTION_NOT_CONNECTED;
if (result == KMOTION_TOKEN.KMOTION_LOCKED)
{
ReleaseToken();
}
return _Connected;
}
}
It should be the same method that KMotionCNC uses, as Tom directed me how to implement it.
Tom, does it look right or did I miss something?
-Brad Murry
--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> Brad,
>
> This seems odd to me. The behavior noted below is 100% consistent. If, however, I include a call to IsReady(), then Connected behaves correctly. Although, I do not consistently get the KMotion MessageBox telling me the connection has gone missing. Shouldn't Connected give the correct response, even in the absence of any other communications?
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> >
> > Brad,
> >
> > I seem to have run face first into a problem that makes no sense to me. I have a method that simply returns KM_Controller.Connected. If no board is connected when my app starts, this returns false. If I then plug the board in, after it initialized, Connected flips to true. If I then unplug the board, Connected remains true! This is with v428, a new board, which is freshly flashed with v428 FW.
> >
> > Regards,
> > Ray L.
> >
>
|
|
| | | | | | | |
