G-Code Loop

[CNC_Machines]

Greetings,

I am building a piece of factory equipment that can either run automatically or manually. I am struggling with the most efficient way to make the logic work.

1. Press Cycle Start
2. M1XX WaitBit - Bit driven by forever loop in my init file
- If in Manual Mode then set the bit
-If in Auto Mode. Wait for loading confirmation, then set the bit
3. Execute G-Code
4. End Program (I DONT KNOW HOW TO DO THIS PART)
-If in Manual M30
-If in Auto M99

The cycle time on this machine is quite fast 3-6 seconds. I am wanting to use the wait bit and M30 and M99 codes so I dont have to reset the motion buffer after every cycle. My current M30 program presses the cycle start button DoPC(PC_COMM_EXECUTE), if it is in auto mode. It appears that this adds a second to my cycle time. Is there a way for the CNC program to read the state of a bit and either perform an M30(End Program), or M99(Repeat)?

Thanks,

Scott

[TomKerekes]

Hi Scott,

I don't fully understand your Auto/Manual mode.

But you might form a loop and then conditionally Stop like this:

Code: Select all

#1=1		(set GCode Var #1 to 1)
O1   		(Label 1)
G0X0Y0		(Do some GCode)
G1X1F240
G1X0
M98 P1 L#1	(loop back if GCode Var#1 = 1)
M30		(Stop)

M47 can also be used to loop back to the start of the program

[CNC_Machines]

Thanks Tom. Is there a way to update Var #1 from inside of KMotion? Really that is my question. I have a selector switch for "Auto" and "Manual". Is there a way to pass that state from the KFlop to KmotionCNC?

[CNC_Machines]

Tom,

This flowchart explains what I am attempting to do. I have the waitbit down, and your loop explains the logic. I am just missing how to change the variable in the G code based off of the switch.

Thanks,

Scott

[TomKerekes]

Hi Scott,

Thanks for the flow chart. But a few things still aren't exactly clear. When would the operator change the mode switch?

Do you realize with your proposed method if the system is in auto mode, running GCode, and the Operator switches to manual, then the GCode will finish, then run the Manual GCode, then stop. Would that make sense?

Is the Manual GCode and the Auto GCode the same?

I also see other issues:

#1 If running in Auto mode and waiting, switching to manual might then wait forever?

#2 Interpreting GCode has look ahead. The Interpreter executes, works ahead, and buffers the motion in KFLOP. The benefit of this is that the motion can be performed with zero (less than 90us) PC/Windows/USB delays. The WaitBit doesn't actually make the Interpreter wait. Instead it inserts a command in the motion sequence to wait at that point in the motion, then proceeds. So for example say that KMotionCNC is set to do 10 seconds of buffering and the GCode sequence involves 2 seconds of motion. In this case the Interpreter will loop 5 times putting 5 sets of motion and waits into the queue. The effect of this will be that switching from Auto to Manual mode will result in 5 more Auto cycles and then one manual cycle before finishing. Probably not what you want?

To avoid the look ahead issue you can place an MCode Execute Action in the loop. When encountering the MCode the Interpreter will wait until all previous buffered motion completes before executing the MCode. The disadvantage would be that the MCode itself and then re-filling the motion buffer to resume motion may then take some time and introduce a delay (probably a few milliseconds on average, on occasion longer depending on Windows).

If I understood your requirements better we could probably find a proper solution with zero delay at least most of the time.

If any delay was overlapped with the Loading operation then that would be fully optimal also. What triggers the Loading?

Anyway here is an example of how a C Program might change clear a GCode Variable.

Code: Select all

#include "KMotionDef.h"

#define TMP 10 // which spare persist to use to transfer data
#include "KflopToKMotionCNCFunctions.c"


main()
{
	// Zero GCode Var 1
	SetUserDataDouble(10,0.0);
	
	// transfer up to the GCode Vars
	SetVars(1,1,10);  // Upload 1 value to GCode 1 from persist 10   
}

Sorry for no simple answer.

[CNC_Machines]

Tom,

I appreciate the detailed reply. To help you understand, we have 30+ small CNC machines being run by KFlops on our factory floor with a desire to build more. The main issue is the actual cycle time for the machines is quite small (4-10 seconds), and the way I have them programmed causes long delays. Sometimes the machine will stall during each cycle for 10 seconds or more. Other times it is as little as 0.5 seconds. The wide swing makes things problematic.

The machine is actually much more complicated then the flow chart suggests. I am attaching a truth table that indicates all of the machine states. The Kflop is controlling an auto loader, KMotionCNC, and and unloading chute. The idea is to have a factory worker be able to turn the switch to "Manual" sit in front of the machine and load parts all day, pressing "Cycle Start" each time. They could turn the swith to "Auto" and it self loads, Cuts, and unloads. This is all currently working, just with delays.

Current Method:

1. Cycle Start
2. S - Spindle Speed, C program to update global variable used in the autoloader and M3 Program.
3. M100
-If in manual proceed and execute G Code (First checks interlock bits if the loader or un loader are in the way. If interference executes the halt/rewind command)
-If Auto checks/waits for a part to load - Then executes G Code.
4. M30 C Program - If switch is in Manual it does nothing, if Auto it presses the "Cycle Start" button again

My feeling was that using the C programs to press cycle start was causing it to buffer motion and all the communication back and forth was causing the lag. I was hoping that getting rid of any C program running in G code drop all of the delays. The loader/unloader would set/clear bits independently without any back and forth. With only waitbits it should run quickly.

Check out this new flow chart. Would your original G-Code work if I could make variable #1 connected to the state of the mechanical switch?

Thanks,

Scott

[TomKerekes]

Hi Scott,

Thanks for more info. I don't understand the state table matrix - other than I can understand what the states are.

You still didn't indicate whether the manual and auto GCode are exactly the same. The reason I ask is that I'm thinking to get the absolute best performance it might be best to basically keep the GCode in a forever loop with a single WaitBit in all cases. Then use a C Program that performs real-time logic based on Manual/Auto, Interlocks, Load/unload state etc. So then in Manual Mode when the Operator pushes a "Go" button the C Program could immediately Clear/Set the WaitBit and motion would begin instantly.

If this "Go" button was an external button hard wired to KFLOP the response would be 100% guaranteed instantaneous. If the "Go" button were a User Button on the Screen to just set a KFLOP IO Bit, the delay should be very minimal. Although nothing in Windows will never have significant delays on occasion.

Of course in Auto mode state changes of the Loader/Unloader could be detected and trigger the motions to start instantaneously as well.

Does this approach sound reasonable?

As a side note. I'm surprised you see delays of over 10 seconds. I would expect delays of ~0.5 sec 99% of the time because of several 0.1 sec status update times in KMotionCNC. Then maybe delays of 1 second (an additional 0.5 sec) ~1% of the time. Then several seconds like 0.00001% of the time. Something odd must be going on like a flood of requests to KMotionCNC or something.

Regards

[CNC_Machines]

Thanks Tom, Yes the manual and auto gcode remain the same. Your suggestion for the forever loop in GCode is interesting, but I have a few questions. The GCode is being constantly updated(same in either mode), the operator control panel has a GUI to make minor corrections. Right now when they make a correction it overwrites the G code and "Cycle Start" runs the new code. If the G Code were overwritten while in an infinite loop, would the interperter wait to pull the new code in until the cycle completes? In this case it never would complete and the updates wouldnt be accepted?

I am trying to think of other things that might be slowing it down. At the beginning of every cycle I am reading in a variable to calculate the auto loader positions. Would this have a significant impact? Would it be faster to pass it in as a global persist variable from G Code? I am already doing this with the spindle speed.

//Read the text file for the part heel diameter - used for loading conveyor speeds & loading head position
FILE *f;
f=fopen("C:\\Users\\pkg0p1trim1\\Desktop\\HeelDiameter.txt","rt"); // open some text file in read text mode
if (!f) // opened sucessfully??
{
printf("Unable to open Heel Diameter file\n");
SetBit(LoaderFLT); //Fault the loader

FILE *f=fopen("C:\\Users\\PKG0P1TRIM1\\Desktop\\FaultLog.txt","wt");
fprintf(f,"Unable to open Heel Diameter file\n");
fclose(f);
return;
}

[TomKerekes]

Hi Scott,

Thanks Tom, Yes the manual and auto gcode remain the same. Your suggestion for the forever loop in GCode is interesting, but I have a few questions. The GCode is being constantly updated(same in either mode), the operator control panel has a GUI to make minor corrections. Right now when they make a correction it overwrites the G code and "Cycle Start" runs the new code. If the G Code were overwritten while in an infinite loop, would the interperter wait to pull the new code in until the cycle completes? In this case it never would complete and the updates wouldnt be accepted?

Correct. If the GCode changes we would need to halt the Interpreter, change the GCode, restart the Interpreter.

How often does this occur? Would it be ok to pay a second or so penalty in these cases?

Could you explain more about the "GUI"? Is that a PC program? Separate from KMotionCNC?

I am trying to think of other things that might be slowing it down. At the beginning of every cycle I am reading in a variable to calculate the auto loader positions. Would this have a significant impact? Would it be faster to pass it in as a global persist variable from G Code? I am already doing this with the spindle speed.

I ran some tests. Reading a file typically takes ~ 0.1 sec per line.

I don't understand what is calculating and writing the disk file? The GUI? How would the GCode get the value?

But yes if the GUI could put the data into KFLOP in say a persist variable, then KFLOP would have instant access to it.

Regards