What I actually did was create a new windows forms project and copied the code from the vb example.  Then in the release and debug folders copied the 6 files you indicated.  I tried making debug1 and release 1 folders but it seemed to insist on still using the std debug and release folders for some reason.

To quote Mae West--"I never said it would be easy, I only said it would be worth it."

I'll suggest you first update everything to the newest release version of the KFlop stuff.

Next, you cannot manually create the debug1/release1 folders. They must be setup in your VS project settings or it won't know the folder in which to compile.

Steps to setup your VS.Net project:

1-Create a new DotNet Solution/Project and set the Project/Properties to the following-
Set the Debug Configuration's Build output path to bin\Debug1    (This can be anything except a folder named "Debug" or "Release")
Set the Release Configuration's Build output path to bin\Release1 (This can be anything except a folder named "Debug" or "Release")

2-Into your project's newly setup Debug1 or Release1 folder(s), copy the appropriate debug or release versions of the following files from the KMotion/Debug|Release folder:

KMotionDLL.dll
KMotion_dotNet.dll
KMotion_dotNet_Interop.dll
GCodeInterpreter.dll
KMotionServer.exe
TCC67.exe (This is the compiler for their DSP C code)
emc.var (This is required at initialization of the Interpreter code (for using GCode). The interpreter can be set to go to another file AFTER this one is read by default, even if you don't want to use it, but it MUST be present at Interpreter Initialization.

3-Copy the folder DSP_KFLOP and it's contents from C:\KMotion<Version> into both the Debug1 and Release1 folders (if both are to be used).

This cures an issue created in the folder hierarchies that Dynomotion has set up that follows the following rule:
-If the Executable's containing (parent) folder is named Debug or Release, the Dynomotion's libraries look for the folder named DSP_KFLOP in the parent folder's path.
-If the Executable's containing (parent) folder is NOT named Debug or Release, the Dynomotion's libraries look for that folder in the same folder as the executable.

Why my setup 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 app path (which happens 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.

--

sam marrocco | chief technical officer
ringside.cutters.picnic.moonlink

248 548 2500 w
248 910 3344 c

ringsidecreative.com

I also confirmed it wasn't trying to go back and use the Kmotion program folder files, by making them offline temporarily.  So a fresh start with just the 6 files and dspkflop folder.  Though the test program is not actually using this so far - I guess it's only used if new c-code needs to be compiled and uploaded?

Yes....not all files are required for basic code. But, you'll soon find yourself encountering errors as you begin doing things such as using the interpreter, compiling startup configuration code (as you thought) and adding features. I found it handy to individually remove files one at a time to determine what individual functions they brought to the party.

--

sam marrocco | chief technical officer
ringside.cutters.picnic.moonlink

248 548 2500 w
248 910 3344 c

ringsidecreative.com