Is that why running the following code:
#include "KMotionDef.h"
main()
{
while(TRUE)
{
//Do nothing
}
}
Runs continuously when Compiled, downloaded and run within KMotion, but....
when Compiled, downloaded and run from a vb.net app starts the run, then fails (as indicated by the KMotion Thread Green 'indicator' almost immediately? Even though there is no output being sent from the KFlop C code, because KMotion is (somewhere in the background) requesting data from somewhere else in KMotion?
Console/printf issues with .Net usage
Moderators: TomKerekes, dynomotion
-
- Posts: 85
- Joined: Fri Apr 27, 2018 12:44 pm
-
- Posts: 85
- Joined: Fri Apr 27, 2018 12:44 pm
Re: Console/printf issues with .Net usage
Can't seem to get out of this rabbit hole....
A correction to my last post--The code executes continuously as expected when run from the minimal vb.net app that I attached earlier.
But it runs then quits almost immediately from my full vb.net application. This is the same C Code being used in the same thread in the KFlop with no output being expected. The green indicator in KMotion goes off right after it comes on at execution start.
Something I haven't found yet in my large app seems to be stopping execution of that simple loop.
A correction to my last post--The code executes continuously as expected when run from the minimal vb.net app that I attached earlier.
But it runs then quits almost immediately from my full vb.net application. This is the same C Code being used in the same thread in the KFlop with no output being expected. The green indicator in KMotion goes off right after it comes on at execution start.
Something I haven't found yet in my large app seems to be stopping execution of that simple loop.
- TomKerekes
- Posts: 2676
- Joined: Mon Dec 04, 2017 1:49 am
Re: Console/printf issues with .Net usage
Hi Sam,
If you run another program in the same Thread it will kill any previously running program. So you might check for that. The ch7->Position=a; debug code might prove the program is being killed before completing.
You might set a breakpoint in KMotionDLL.cpp:
int CKMotionDLL::LoadCoff(int Thread, const char *Name, int PackToFlash)
to catch any call to load another program.
If you run another program in the same Thread it will kill any previously running program. So you might check for that. The ch7->Position=a; debug code might prove the program is being killed before completing.
You might set a breakpoint in KMotionDLL.cpp:
int CKMotionDLL::LoadCoff(int Thread, const char *Name, int PackToFlash)
to catch any call to load another program.
Regards,
Tom Kerekes
Dynomotion, Inc.
Tom Kerekes
Dynomotion, Inc.
-
- Posts: 85
- Joined: Fri Apr 27, 2018 12:44 pm
Re: Console/printf issues with .Net usage
Thanks for the suggestion, Tom.
It looks as though I had another program loading into that same Thread later in the app for use, and that was causing the code to 'abort' just after start. That was an awful little thing of mine to get stuck on. Now I can get back to focusing on the MPG code that lead me into this.
Thanks again for your patience! if nothing else, now I know more about the console and threading system.
It looks as though I had another program loading into that same Thread later in the app for use, and that was causing the code to 'abort' just after start. That was an awful little thing of mine to get stuck on. Now I can get back to focusing on the MPG code that lead me into this.
Thanks again for your patience! if nothing else, now I know more about the console and threading system.
- TomKerekes
- Posts: 2676
- Joined: Mon Dec 04, 2017 1:49 am
Re: Console/printf issues with .Net usage
Great. Thanks for taking the time to post back.
Regards,
Tom Kerekes
Dynomotion, Inc.
Tom Kerekes
Dynomotion, Inc.
-
- Posts: 85
- Joined: Fri Apr 27, 2018 12:44 pm
Re: Console/printf issues with .Net usage
You're welcome. No one like an incomplete threads, on a forum or in code