Difference between revisions of "PC Example Applications"
From Dynomotion
(List LabView and Python Examples) |
(→Correction and update to VS2022 options) |
||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | __FORCETOC__ | ||
| + | |||
A number of PC Applications using the KMotion Libraries are available in the Software download. Visual Studio should be used to modify/compile the applications. Currently the projects are compatible with VS 2008 Standard but later Versions can upgrade the projects and can be used including the free Microsoft Version of VS 2013 Community. In some cases MFC capability needs to be added as a separate download. | A number of PC Applications using the KMotion Libraries are available in the Software download. Visual Studio should be used to modify/compile the applications. Currently the projects are compatible with VS 2008 Standard but later Versions can upgrade the projects and can be used including the free Microsoft Version of VS 2013 Community. In some cases MFC capability needs to be added as a separate download. | ||
| Line 16: | Line 18: | ||
* Download Waveform - simple example to download some data to the gather buffer | * Download Waveform - simple example to download some data to the gather buffer | ||
* SimpleCoffload - simple example to compile/download a C Program to KFLOP | * SimpleCoffload - simple example to compile/download a C Program to KFLOP | ||
| − | * SimpleConsole - simple example to send [. | + | * SimpleConsole - simple example to send [http://dynomotion.com/Help/CmdsCategory.htm Console Script commands] to KFLOP |
* SimpleCoordMotion - simple example of creating coordinated motion paths in KFLOP | * SimpleCoordMotion - simple example of creating coordinated motion paths in KFLOP | ||
* SimpleGCode - simple example to execute a GCode File | * SimpleGCode - simple example to execute a GCode File | ||
| Line 44: | Line 46: | ||
* OnOffWPF.sln - Demonstrates Bit Commands to KFLOP with WPF GUI | * OnOffWPF.sln - Demonstrates Bit Commands to KFLOP with WPF GUI | ||
| + | |||
| + | ==Debugging From .NET into Unmanaged C++ Code of KMotion Libraries== | ||
| + | When debugging Managed code such as an App written in C# .NET it is sometimes helpful to step into or set breakpoints or view variables in the Unmanaged C++ KMotion Libraries to understand exactly what is happening. Visual Studio allows you to do this but the Project Properties for the App must have the "Enable native code debugging" option enabled. | ||
| + | |||
| + | |||
| + | [[File:EnableNativeCodeDebugging.png|none|link=]] | ||
| + | |||
| + | |||
| + | Then for example when debugging on a line of Managed Code that makes a call to the KMotion Libraries such as this: | ||
| + | |||
| + | |||
| + | [[File:StepInto.png|none|link=]] | ||
| + | |||
| + | |||
| + | Use the debugger Debug | Step Into Menu button or tool bar button. | ||
| + | |||
| + | |||
| + | Note in some cases Right-Click Step Into Specific can be used or may be necessary to specify exactly what to Step into as shown below: | ||
| + | |||
| + | |||
| + | [[File:StepIntoSpecific.png|none|link=]] | ||
| + | |||
| + | |||
| + | Stepping into functions should eventually get into the C++ Libraries as shown here: | ||
| + | |||
| + | |||
| + | [[File:IntoCppCode.png|none|link=]] | ||
| + | |||
| + | |||
| + | If Visual Studio skips over Unmanaged code calls and refuses to step into the Unmanaged functions you may have some odd Visual Studio debug options set. Exit debugging and within Visual Studio use the Debug | Options | Debugging | General and select options as shown below: | ||
| + | |||
| + | |||
| + | |||
| + | [[File:DebugOptions2022.png|none|link=]] | ||
| + | |||
| + | |||
| + | |||
| + | Note one disadvantage of having native code debugging enabled is that Visual Studio's powerful Edit and Continue option to make changes on-the-fly is not available. So when not necessary to debug into Unmanaged code it is may be desirable to disable native code debugging. | ||
| + | |||
| + | |||
| + | |||
| + | Note the App being debugged should be using the Debug Versions of the KMotion Libraries from the Debug folder rather than the Release folder. The BuildAllLibs.sln in configuration Debug may be used to create the Debug Versions. | ||
==Installing your PC Application on a Target System== | ==Installing your PC Application on a Target System== | ||
| Line 49: | Line 93: | ||
| − | Here is a relevant | + | Here is a relevant thread from our forum: |
| − | [https:// | + | [https://www.dynomotion.com/forum/archive/KFlop%20and%20dotnet%20dependencies.html KFlop and dotnet dependencies....] |
Quote: | Quote: | ||
''<span id="yui_3_15_0_1_1456686023559_758" class="qreply">The cleanest way of sandboxing a KFlop DotNet application seems to be this:<br /><br />1-Create a new DotNet Solution/Project and set the Project/Properties for the following<br /><br />Set the Debug Configuration's Build output path = bin\Debug1 (This can be anything except a folder named "Debug" or "Release")<br />Set the Release Configuration's Build output path = bin\Release1 (This can be anything except a folder named "Debug" or "Release")<br /><br />2-Into your newly created Debug1 or Release1 folder(s), copy the appropriate debug or release versions of the following from the KMotion/Debug|Release folder:<br /><br />KMotionDLL.dll<br />KMotion_dotNet.dll<br />KMotion_dotNet_Interop.dll<br />GCodeInterpreter.dll<br />KMotionServer.exe<br />TCC67.exe<br /><br />3-Copy the folder DSP_KFLOP and it's contents into both the Debug1 and Release1 folders.<br /><br />Why it works: By using names other than "Debug" and "Release" for the application container folders we prevent the KMotionDLL from looking for a parent folder containing the KFLOP headers and compiles. This causes KMotionDLL to look in the current apppath (whichhappens to be where everything else is as well) for the DSP_KFLOP folder.<br /><br />At any point in the future, the Debug1 or Release1 container folders can be renamed with their app's name (or anything else other than the words Debug or Release) and moved, copied and the dotnet application within should continue to run without issue.</span>'' | ''<span id="yui_3_15_0_1_1456686023559_758" class="qreply">The cleanest way of sandboxing a KFlop DotNet application seems to be this:<br /><br />1-Create a new DotNet Solution/Project and set the Project/Properties for the following<br /><br />Set the Debug Configuration's Build output path = bin\Debug1 (This can be anything except a folder named "Debug" or "Release")<br />Set the Release Configuration's Build output path = bin\Release1 (This can be anything except a folder named "Debug" or "Release")<br /><br />2-Into your newly created Debug1 or Release1 folder(s), copy the appropriate debug or release versions of the following from the KMotion/Debug|Release folder:<br /><br />KMotionDLL.dll<br />KMotion_dotNet.dll<br />KMotion_dotNet_Interop.dll<br />GCodeInterpreter.dll<br />KMotionServer.exe<br />TCC67.exe<br /><br />3-Copy the folder DSP_KFLOP and it's contents into both the Debug1 and Release1 folders.<br /><br />Why it works: By using names other than "Debug" and "Release" for the application container folders we prevent the KMotionDLL from looking for a parent folder containing the KFLOP headers and compiles. This causes KMotionDLL to look in the current apppath (whichhappens to be where everything else is as well) for the DSP_KFLOP folder.<br /><br />At any point in the future, the Debug1 or Release1 container folders can be renamed with their app's name (or anything else other than the words Debug or Release) and moved, copied and the dotnet application within should continue to run without issue.</span>'' | ||
Latest revision as of 20:30, 9 August 2023
A number of PC Applications using the KMotion Libraries are available in the Software download. Visual Studio should be used to modify/compile the applications. Currently the projects are compatible with VS 2008 Standard but later Versions can upgrade the projects and can be used including the free Microsoft Version of VS 2013 Community. In some cases MFC capability needs to be added as a separate download.
Note All the projects in KMotion Versions 4.34a and later have now been updated and should work out-of-the-box with VS2015.
Link to the Microsoft Free Visual Studio 2015 Community Version
When installing make sure options for C++ and MFC are enabled.
The Install Root directory contains a VS Solution BuildAllLibs.sln to build the KMotion Libraries.
The VS Solution \PC VC Examples\BuildExamples.sln will build most all of the Examples
MFC C++ Examples - \PC VC Examples
- KMotionCNC - CNC Application for controlling Mill/Router/Lathe etc
- Download Waveform - simple example to download some data to the gather buffer
- SimpleCoffload - simple example to compile/download a C Program to KFLOP
- SimpleConsole - simple example to send Console Script commands to KFLOP
- SimpleCoordMotion - simple example of creating coordinated motion paths in KFLOP
- SimpleGCode - simple example to execute a GCode File
C# Examples - \PC VC Examples
- KFlopWebNC - HTML CNC based App interfacing to KMotion Libraries
- KMotion_dotNet Console - Windows Console App using .NET Library Interface
- MeasureFiducials - Video Alignment Application to measure fiducial alignment marks and map coordinate space
- SimpleFormsCS - Simple Windows C# Forms App includes USB speed test
- TeachMotion - App for use with Lathe Spinners to teach Spinning motion and create GCode
Visual Basic Examples \PC VB Examples
- DynoMotion VB.net - Demonstrates Coordinated motion, GCode Execution, Status, etc...
- Jogger - Simple VB6 App to Jog Axes
- Jogger.NET - simple VB .NET App to Jog Axes
LabView Examples \PC LabView Examples
- Kmotion DotNet DLL Sample.vi - Simple GUI to Jog, Display Readout, Execute C Programs, Console messages
Iron Python Examples \PC Python Examples
- OnOffWPF.sln - Demonstrates Bit Commands to KFLOP with WPF GUI
Contents
Debugging From .NET into Unmanaged C++ Code of KMotion Libraries
When debugging Managed code such as an App written in C# .NET it is sometimes helpful to step into or set breakpoints or view variables in the Unmanaged C++ KMotion Libraries to understand exactly what is happening. Visual Studio allows you to do this but the Project Properties for the App must have the "Enable native code debugging" option enabled.
Then for example when debugging on a line of Managed Code that makes a call to the KMotion Libraries such as this:
Use the debugger Debug | Step Into Menu button or tool bar button.
Note in some cases Right-Click Step Into Specific can be used or may be necessary to specify exactly what to Step into as shown below:
Stepping into functions should eventually get into the C++ Libraries as shown here:
If Visual Studio skips over Unmanaged code calls and refuses to step into the Unmanaged functions you may have some odd Visual Studio debug options set. Exit debugging and within Visual Studio use the Debug | Options | Debugging | General and select options as shown below:
Note one disadvantage of having native code debugging enabled is that Visual Studio's powerful Edit and Continue option to make changes on-the-fly is not available. So when not necessary to debug into Unmanaged code it is may be desirable to disable native code debugging.
Note the App being debugged should be using the Debug Versions of the KMotion Libraries from the Debug folder rather than the Release folder. The BuildAllLibs.sln in configuration Debug may be used to create the Debug Versions.
Installing your PC Application on a Target System
A number of KMotion DLLs EXEs and Data files in an expected structure are required for your application to run. The Simplest solution is to install KMotion on the target system and place your executable in the \KMotion\Release Directory. Otherwise you will need to include all the files referenced directly or indirectly by your application.
Here is a relevant thread from our forum:
KFlop and dotnet dependencies....
Quote:
The cleanest way of sandboxing a KFlop DotNet application seems to be this:
1-Create a new DotNet Solution/Project and set the Project/Properties for the following
Set the Debug Configuration's Build output path = bin\Debug1 (This can be anything except a folder named "Debug" or "Release")
Set the Release Configuration's Build output path = bin\Release1 (This can be anything except a folder named "Debug" or "Release")
2-Into your newly created Debug1 or Release1 folder(s), copy the appropriate debug or release versions of the following from the KMotion/Debug|Release folder:
KMotionDLL.dll
KMotion_dotNet.dll
KMotion_dotNet_Interop.dll
GCodeInterpreter.dll
KMotionServer.exe
TCC67.exe
3-Copy the folder DSP_KFLOP and it's contents into both the Debug1 and Release1 folders.
Why it works: By using names other than "Debug" and "Release" for the application container folders we prevent the KMotionDLL from looking for a parent folder containing the KFLOP headers and compiles. This causes KMotionDLL to look in the current apppath (whichhappens to be where everything else is as well) for the DSP_KFLOP folder.
At any point in the future, the Debug1 or Release1 container folders can be renamed with their app's name (or anything else other than the words Debug or Release) and moved, copied and the dotnet application within should continue to run without issue.
