#including KflopToKMotionCNCFunctions.c and others

Moderators: TomKerekes, dynomotion

Post Reply
MadTooler
Posts: 86
Joined: Thu Nov 08, 2018 11:57 pm

#including KflopToKMotionCNCFunctions.c and others

Post by MadTooler » Mon Nov 12, 2018 6:51 am

I have several c programs that need the "KflopToKMotionCNCFunctions.c" file. Since I store my C programs in a different location than within the c:\KMotion434 directory, I have been using the full path as #include "C:/KMotion434/C Programs/KflopToKMotionCNCFunctions.c"

However, the also usually needed #include "KMotionDef.h" is able to find the file without the path. This behavior is the only reason I even post on this issue. Note I am not much more than an amateur programmer lacking a good portion of the knowledge of the C file and data structure. That said, I assume I could do something like add a path somewhere to allow my programs to find the needed file with only #include "KflopToKMotionCNCFunctions.c".

Any advice is appreciated.

User avatar
TomKerekes
Posts: 2679
Joined: Mon Dec 04, 2017 1:49 am

Re: #including KflopToKMotionCNCFunctions.c and others

Post by TomKerekes » Mon Nov 12, 2018 5:00 pm

Hi MadTooler,

There isn’t a customizable include path. The compiler looks: In the same directory as the source file or in the DSP_KFLOP directory of the install directory. KMotionDef.h should remain within the install directory so the one used matches the firmware in use.

You might copy other utility files used by your code into the same directory as your code.
Regards,

Tom Kerekes
Dynomotion, Inc.

MadTooler
Posts: 86
Joined: Thu Nov 08, 2018 11:57 pm

Re: #including KflopToKMotionCNCFunctions.c and others

Post by MadTooler » Mon Nov 12, 2018 5:50 pm

Thanks, Tom. That answers my question.

That makes sense. I have left KMotionDef.h alone. My issue has only been with KflopToKMotionCNCFunctions.c. Using the path at #include works for me.

BTW, not sure if it is suppose to, but #including KflopToKMotionCNCFunctions.c throws a compile error occasionally when #include KMotionDef.h is not called from a line prior. The only time I have noticed it failing when it is written on a line after is where I have one c program including another. The includes in the included c program are the finicky ones.

Moray
Posts: 288
Joined: Thu Apr 26, 2018 10:16 pm

Re: #including KflopToKMotionCNCFunctions.c and others

Post by Moray » Tue Nov 13, 2018 5:50 pm

MadTooler wrote:
Mon Nov 12, 2018 5:50 pm
BTW, not sure if it is suppose to, but #including KflopToKMotionCNCFunctions.c throws a compile error occasionally when #include KMotionDef.h is not called from a line prior. The only time I have noticed it failing when it is written on a line after is where I have one c program including another. The includes in the included c program are the finicky ones.
Includes are read in order, so having KMotionDef.h after KflopToKMotioncCNCFunctions.s c will throw an error, as the ...Functions.c relies on code in the KMotionDef.h file, so if the KMotionDef.h file hasn't been read first, then the compiler will find unknown functions/constants in the ..Functions.c and throw an error.

MadTooler
Posts: 86
Joined: Thu Nov 08, 2018 11:57 pm

Re: #including KflopToKMotionCNCFunctions.c and others

Post by MadTooler » Wed Nov 14, 2018 3:01 am

Thanks, Moray.

I am aware of what the order of execution of includes should do. My initially poor ordering of the includes was due to sloppy practices. My note reflects a somewhat odd behavior where the compiler didn't seem to care if I had the includes in the wrong order unless it was within a c program that I was then including within another c program. Seems strange that it hasn't complained about the main program too.

Post Reply