[netboss]

Once again I fear I am the victim of my own actions.

Environment: KFlop with a third party controller, using KmotionCNC.

I have a GCode program that I have used for about a week. Among other things, it does external single point threading. Single point threading was working like a charm until yesterday afternoon. (more material to remove). At some point in the process of making the changes, the TPI went from 16tpi to 8tpi.

I've checked everything I can think of, the most obvious being the F word in the G32 block. It still reads f0.0625.

I considered that maybe the steps per inch on that axis had been changed. Using a dial indicator, I checked to see that when commanded to move one inch, the machine moved an inch. That test showed the moves were within 1/4 thousandth over 6 inches.

I checked to be sure I had not left an "open" G91 or some other scale or offset code. Nothing.

So in desperation I changed the F word in the G32 block from 0.0625 to 0.03125. Now I'm cutting 16tpi. Of course that should cut 32tpi.

Any ideas where to look next?

[TomKerekes]

Hi netboss,

Other things that would effect this would be:

Tool Setup | Trajectory Planner | Threading | Count/Rev - is the RPM Readout correct?

KFLOP Encoder Axis InputGain0 - again that would show the RPM readout would be wrong if that changed

FRO?

Rotate the Spindle One rev manually and check if the Kmotion.exe Axis Screen shows the correct number of Position Count change.

HTH
Regards

[netboss]

Tom,

Sorry to be AWOL. I had an emergency repair job for a client that has kept me tied up for a few days.

I had tried everything that you suggested and all was correct.

During my time away from this lathe, the PC that was running KmotionCNC was rebooted. After the reboot the problem disappeared. Whether the program had been corrupted, or whether a setting was altered and the reboot corrected it, I cannot tell. I'm leaning toward some sort of corruption in GCode processing as all the tests I ran (counts per rev, rpm, etc.) returned correct results. But even that seems unlikely as the corruption would have needed to alter ONLY the interpretation of the F word in the G32 command. Oh well, I guess I will never know.

BTW, the KFlop was NOT power cycled, but it was rebooted during all of this, so the evidence points to something happening within the PC.

I love working with your system. The KFlop has been rock solid. And the more I learn about your software, the more I realize just how flexible the entire system is.

Now another question (non-critical).

Having been a programmer in languages from IBM assembly up to modern day variants of "C", i tend to use variables a lot in my GCode, as well as use a lot of M98/M99 subroutines. (I guess my propensity toward modularization comes from my background).

The GCode limitation of using only non-descriptive, numbered variables limits the "readability" of GCode.

I have long had the idea to write a "pre-processor" that would allow a GCode programmer to use symbolic variables, run the GCode file through the pre-processor which would simply replace the symbolic variables with CGode type numeric variables. I realize the process would require extensive syntactic analysis of the GCode in order to "recognize" the descriptive variables, but I've given the matter a great deal of thought and am confident I can produce a usable program.

I think one can guess that I hand code much of my GCode, and even that with is produced by CAM is highly modified by me.

The flexibility of KMotionCNC raises the question of using it as a platform for such a process. As I envision it, the coder would be able to use symbolic symbols in the GCode screen and when any execute action was taken, single step, simulate, run, etc. a preprocessor would grab the CGode and do the conversion. All of this would be most effective (from the operator's standpoint) if the GCode screen retained the symbolic variables in view of the operator.

I recognize that there could be significant problems to overcome in implementing such a preprocessor, but again, I'm confident that I can find a way if it is at all possible.

So my question is, "Is there a 'hook', API, C code file, routine, etc, which would offer a logical place to begin such a process?". I've read several posts or articles which allude to the GCode interpreter used by KMotionCNC, but nothing too specific.

I suppose that I can investigate all of your source files in an effort to find that information, but a few words from you can eliminate hours of investigation.

And there is always the possibility that you will say that the method in which the GCode is parsed, makes such a project highly impracticable.

Thanks again for everything. I continue to be amazed at your level of support as well as the quality of your products. Keep up the good work, and PLEASE be around for another 10 years or so. I'm 72 years old and figure that by that time I won't be able to code anymore anyway. LOL.

Gary

Hi netboss,

Other things that would effect this would be:

Tool Setup | Trajectory Planner | Threading | Count/Rev - is the RPM Readout correct?

KFLOP Encoder Axis InputGain0 - again that would show the RPM readout would be wrong if that changed

FRO?

Rotate the Spindle One rev manually and check if the Kmotion.exe Axis Screen shows the correct number of Position Count change.

HTH
Regards

[TomKerekes]

Hi Gary,

Regarding Symbolic Variables: that would be nice. I'm not sure how difficult it would be. The rs274ngc_read() function in \GCodeInterpreter\rs274ngc.cpp would probably be the place to start studying. read_parameter() is called to load a Variable identified by an integer number and read_parameter_setting() is called to set a variable identified by an integer to an expression.

HTH
Regards

[netboss]

Thanks. I'll look into that code.