Dynomotion Forum

From the blog:

Although C Programs can be Flashed to KFLOP memory so they will be present in KFLOP Memory on Power up this is not normally recommended and not usually required. KFLOP normally powers up with no C Programs in Memory. Programs can be compiled, downloaded, and executed dynamically in Threads by Applications at run time. They do not need to be pre-loaded (or Flashed) into KFLOP Memory. For example when KMotionCNC executes GCode and encounters an M3 it may download the configured C Program to the Configured Thread and execute it.

So if I understand correctly, there are three ways to run the KFLOP.
1) Write a completely autonomous program in C, flash it to memory, and run the KFLOP autonomously. This apparently is not recommended.
2) Use KMotionCNC and upload G-Code, possibly executing C code, running from the KMotionCNC window with its user interface and communicating with the KFLOP via the USB interface.
3) Use the .NET interface and write a user interface in LabView, Windows C++, Python, etc which communicates with the KFLOP via the USB interface.

In cases 2 and 3, you write a C program that is loaded onto the board from the PC at startup (every time the system is powered on, what happens when the KFLOP is powered up and the PC isn't there?) and just talks to the user interface on the PC. The documentation is a bit confusing as to what functionality is on which. When the blog says "Programs can be compiled, downloaded, and executed dynamically in Threads by Applications at run time", which "Applications" are we talking about?

Is this basically correct?

pblase wrote: ↑

Tue Apr 30, 2019 6:29 pm

In cases 2 and 3, you write a C program that is loaded onto the board from the PC at startup (every time the system is powered on, what happens when the KFLOP is powered up and the PC isn't there?) and just talks to the user interface on the PC.

Nothing. KFlop simply sits there dumbly doing nothing, unless you tell it to do something.

The documentation is a bit confusing as to what functionality is on which. When the blog says "Programs can be compiled, downloaded, and executed dynamically in Threads by Applications at run time", which "Applications" are we talking about?

Any PC application written to make use of the KFlop. And I suspect what is meant by run time in this context, is when you need to run said C programs in KFlop, not when the PC application is run.
Using KMotionCNC as an example, it can be configured to compile, download and execute various C programs to the KFlop. An example would be you typically run an initialisation C program that configures the KFlop for use into one thread (this will typically have an infinite loop for monitoring, unless your use is very basic). Then you would also have various other C programs, which are downloaded and executed in other threads when needed. I.e. you may have a C program to handle a tool change. It will only be downloaded and executed when you command a tool change. The same could apply to controlling the spindle.

There is a lot of functionality you can access without C programs, like PC applications can directly control output bits, command jogs, configure settings, read input bits etc.
C programs are needed for things that are time critical I.e. where you need an output to respond quickly to an input change (IIRC the PC communication is updated at around 10Hz, so if you need something to respond instantly, you'd do it using C), or more complex processes where you don't need any PC application input and/or bit bashing between PC and KFlop would add too much time.
The area between the two is a bit blurry, as there can be multiple ways to achieve the same thing, but unless you want to write PC programs, C programs for the KFlop are far simpler.

It's worth noting C programs are only compiled once, either if the they've never been compiled before, or a change in the original C program is detected, or the thread it is being loaded to is changed. The compiled files are stored as .out files beside the original C program, with the thread number appended to the file name. (i.e. my Init.C file, is compiled to Init(1).out, as it gets loaded into thread 1).
After the initial compile, program downloading is pretty much instantaneous (unless it's some kind of huge C program, that may take a bit longer to download!).


If you'd like to tell us what you're looking to do, I'm sure you'll get suggestions on the best way to achieve it.

Ok, thanks much. I'm new to the Dynomotion system, and there's a lot here to wrap one's head around.

What I have is a KFLOP and KANALOG driving two servo amplifiers (AMC AB30A200AC), that in turn are driving two H2W Tech linear motors with Renishaw LM10 linear encoders. For the first task, the system just needs to move each motor from position 1 to position 2 as quickly as possible (accelerate half way, deacellerate half-way). It would be nice if it could operate without a PC, just by pushing a button, but I can use a laptop with LabView as a user interface, via the .NET libraries.

The main problem is that this thing needs to be operated by non-technical types (or at least scientists who aren't wanting to bother with loading programs and such) and so the whole boot-up process will need to be automated as much as possible. Lots to learn here.

So that should be:

"[KFLOP]Programs can be compiled, downloaded, and executed dynamically in [KFLOP]Threads by [PC]Applications at run time",

Nothing. KFlop simply sits there dumbly doing nothing, unless you tell it to do something.

I do a lot of embedded systems programming, and it's nice to have this verified. I never assume that a CPU will simply sit still and do nothing!
So the general idea is that you write a C program that responds to specific commands from the PC; not that you write an autonomous program that runs on the KFLOP and runs stand-alone.

That actually sounds like a case where flashing the C program to the KFlop could be a good option.

The usual reasons for recommending not to flash C programs, is if you're using a PC anyway there's no real benefit to flashing, and it can cause longer term support issues as any update to the KFlop firmware will clear any flashed programs. Which can give you a big headache if you don't have a clear record of what's flashed and still have a copy of the required files.


You might of already read it, but as you're using a Kanalog, although the KFlop pins do nothing, some of the Kanalog outputs can be random until the KFlop boots and initialises the Kanalog, and is why it's recommended to use the EnableAll (watchdog) output to ensure nothing powers up during booting.

It would be nice if it could operate without a PC, just by pushing a button

That is certainly possible. It should be simple to write a C Program to monitor an input connected to a button and when pushed do a simple move. After the program is debugged you could Flash the program into KFLOP and remove the PC.

The reason we don't normally recommend this is only to avoid confusion. You will need to keep track what has been flashed into each KFLOP. If a PC is always connected it is simpler to just have your PC application load whatever it needs.