Dynomotion Forum

In trying to modify KmotionCNC, it is useful to understand how it works. Unfortunately, there is a LOT of code involved, and it is sometimes obscure and mostly undocumented and uncommented. In looking at it, one of the first questions I came up with is what is the point of KmotionSever.exe? It appears to only add complexity without adding value.
I would really like to redo KmotionCNC using WPF or some other modern GUI framework and get rid of all the MFC stuff (MFC is way past its prime), and to this end it would be nice if the "Driver Model.doc" file or the wiki contained a lot more elaboration on the system architecture.

Hi rlkeck10,

KMotionServer is what allows multiple Applications to simultaneously access multiple KFLOP boards. Without KMotionServer once an Application opened the USB Driver to communicate with one KFLOP no other applications could have access to that KFLOP or any others.

In general, I would not expect it to be useful or safe for more than on application to be accessing a single Kflop at a time, at least assuming it is being used in a typical machine control application. Indeed if the Kflop USB driver permitted sharing by different apps, the first thing I'd imagine doing would be adding some kind of mutex to prohibit sharing. In the case where more than one access might be useful, I would think it would need to be implemented on an application specific basis to prevent bad things from happening.

As far as multiple applications accessing multiple different Kflops, I would not expect the USB driver would prohibit that. For the most part in Windows, only one application can access a device at a time (e.g. a serial port), but multiple applications can access different devices of the same type at one time (e.g. app1 can use COM1 and and app2 can use COM2 at the same time). There are devices that permit shared access, but they are unusual. I only have one Kflop, so I cannot confirm this for Kflop, but since it is evidently using an FTDI chipset, which is commonly used for USB serial applications, I'd be really surprised if two different apps cannot access two different Kflops at the same time.

In short, I cannot really think of a scenario where the sharing the server allows would be useful.

The ability to have more than program access a single KFlop can be useful.

The main benefit I've found, is rather than have to modify KMotionCNC (I've never been able to get my head around the whole MFC thing!), you can create another program that will run alongside KMotionCNC to do something specific. Personally I've got a probing program that accesses the KFlop directly for status, then links into KMotionCNC for a few things (mainly jogging IIRC).
And also KMotion itself allows you to monitor the KFlop, while KMotionCNC is running.

I have started work on a KMotionCNC replacement that uses C#/WPF, but it's very much a long term project.
My program is using the dotNet interface, which means most of the background connection information is dealt with behind the scenes, without needing to know anything about the architecture. I just connect to whatever KFlop is connected (I have left my code, so it can be expanded to handle selecting one of multiple KFlops, but it simply connects the first KFlop in the list at the moment).

I see your point, although it really makes the point the KmotionCNC is not written in a way that makes it easy to expand and modify (you should be able to easily integrate probing into KmotionCNC). Still KmotionSever is not a good sharing solution. For example it is perfectly possible to start two instances of KmotionCNC and they will permit you to try and run two G code programs at once with immediately disastrous results.

In any event, I am busy rewriting the equivalent of the CKMotionDDL class interface to Kmotion as a WINAPI dll that does not use Kmotion server. The reason for using a WINAPI dll is that almost any programming language that runs on Windows has the ability to call a WINAPI dll. I can then easily write a bridge CKMotionDLL class that will allow KMotionCNC to use my DLL instead of the original to allow for testing. The next step would be to do the same for CCoordMotion. Once those two are done, it should be much easier to replace KMotionCNC with for example a WPF equivalent. The other intriguing possibility would be to use Lua ala Mach 4 (I really like the way Lua makes it easy to modify and expand Mach 4 even if it does require you to learn yet another programming language).

If I make enough progress, I'll investigate putting the results on GitHub although I'll need to find out about copyright. I'm assuming, since there is a Linux port of the code already on GitHub, this is possible, but Dynomotion does not explicitly state the license terms for the code that I have found. I suspect since it uses code from EMC, it may necessarily be GPL. Looking through the forums, it is clear that multiple people have made an effort to produce a WPF or .NET version of KmotionCNC. It would be nice to find a way to coordinate and cooperate on such an effort.

I'm pretty sure even your average user, if they did manage to open multiple instances of KMotionCNC, would either realise, or not try running G code in more than one instance.

I do get your argument, but are you still going to be able to use KMotion while also using KMotionCNC?
For setup/diagnostic purposes, being able to switch between whatever active program you're using (be that KMotionCNC or something custom), and KMotion is almost essential. If you remove that capability, then you'll likely have to recreate a lot of KMotion's functionality in your own program.



You have to remember, the whole Dynomotion ecosystem will have it's roots quite some time ago (I'm sure Tom probably doesn't want to admit how long ago!), when existing standards were quite different. I actually just checked, and the earliest date in the changelog for KMotion/CNC 2.23 was April 2005. WPF didn't get released until 2006. MFC was released in 1992. And for completion, WinForms was 2002 (I know, I tripped down a google rabbit hole there!)

At what point as a company do you drop all old code, and re-write from the ground up, especially for a program that you don't directly make money from, just so the program does the same thing, but using a newer standard?
As per Tom's reply to my own thread, KMotionCNC is currently about 45'000 lines of code.

I might be interested in a bit more collaboration on my program. If you're interested have a scan through my thread (or just the last couple pages) to see where I'm heading/thinking, and drop me a PM. I won't be doing any more major work to it for at least a few weeks, as I'm currently trying to get one mill retrofitted, and build a new lathe from scratch :-/

I don't see a constant need to switch between Kmotion and KmotionCNC, so I don't find that compelling. I don't see any guarantee that if you mess with the Kflop using Kmotion while KmotionCNC is active, you will not end up with unpredictable results. It would be better from all points of view to shut one down, use the other then restart the first.

I completely get the long history of Kmotion. I understand that Dynomotion may have no incentive to rewrite it. I am aware of the large number of lines of code, however, many of those support the MFC GUI and would require far fewer lines of code to replace with, for example, WPF.

The part of Kmotion which is really valuable is the hardware interface, which actually is not that large and GCodeInterpreter, which I've not done a line count on. GCodeInterpreter needs to be somewhat modified to provide a language neutral API, but that can be done while leaving it largely unmodified. My goal is to get both of these pieces to a point where they are language neutral and MVM or MVVM compatible. Reproducing the actual GUI with WPF requires almost no lines of code, only a bunch of XAML. I don't think it will then require vast amounts of code to wire it up the the hardware interface and the g-code interpreter.

The interesting thing is that as I modify the code, it gets simpler and easier to understand. If in the end, if someone really wants a client server architecture, it would be reasonably easy to put it back in.

Looking at your thread, I don't think we are really that far apart. I'm trying in essence to provide a clean separation of the motion control code from the MFC GUI code so it can be reused in whatever GUI framework one chooses. While I still have away to go, this actually looks to be do-able.

You don't need to constantly switch between KMotion and KMotionCNC, however during the initial machine setup, it's pretty much essential.

Have KMotion open for modifying C programs, and to monitor axes/bits/console, while you also have KMotionCNC running to trigger the required events you're trying to get working. Only being able to have one or the other, means you're going to have to duplicate a fair bit of KMotion functionality in KMotionCNC.
There is always the possibility of doing something in KMotion that will cause unpredictable results, but under normal circumstances you wouldn't be running KMotion while using KMotionCNC.


You do realise most of the GCodeInterpreter functionality is already exposed via dotNet, which can be accessed via VB,C++, and C#?
I'm pretty sure with dotNet, you could lock the KFlop so no other app can access it by grabbing the token and never releasing it.


Out of curiosity, with your approach, what would happen if there was ever an ethernet KFlop released, so you're not directly connecting to a device driver?
(for anybody getting excited, I have no idea if there will ever be an ethernet KFlop. I'm just speculating!)

The problem with Kmotion as it stands, is it is very hard to figure out how it works. In part this is because of the server code, which requires locking all over the place. By removing that, there is a considerable simplification. The .NET interop stuff provided, again looks unnecessarily complex and it is a C++ .NET interface. I've learned from experience, that if you can avoid that and use C# pinvoke, it is much cleaner.
So basically, I'm going to be doing a certain amount of refactoring to clean things up.

As for Ethernet, not a problem. One of the things that motivates this is I'd potentially like to use it with another motion controller that has an Ethernet interface. If the code is properly structured, substituting one device for another is a matter of supplying a shim layer. I would point out there is no fundamental difference between talking to the FTDI port and talking to an Ethernet device. In both cases they are in essence "pipes".

ON the subject of Kmotion server I find it invaluable for monitoring the Kflop especially while debugging my program, testing c-code etc.

My main complaint is when I start it up and that damn white window covers my whole monitor, every time! What is the possible purpose of that? I'm sure I have spent way too many total hours resizing it back to the menu strip, which is all that is needed...

Also it often crashes when I close my other program, so I would not use it while doing anything critical with machinery attached...