G-codes/offsets/tools with .Net

[Demondor]

Code: Select all

using (StreamWriter writer = new StreamWriter(file))
{
     writer.WriteLine(gcode);
     writer.WriteLine();
}
string readText = File.ReadAllText(file);
//RichTextBox_GCode.Document.Blocks.Clear();
RichTextBox_GCode.AppendText(readText);

Code: Select all

bool f = false; // bool state, If for some reason an error occurs inside using {}, for example, there will be an error in the specified file path
using (StreamWriter writer = new StreamWriter(file))
{
     writer.WriteLine(gcode);
     writer.WriteLine();
     f=true;
}
if (f)
{
	RichTextBox_GCode.AppendText(gcode); // the text is the same and it makes no sense to read it from a file, this increases the execution time
	 if (!Connected) KM.CoordMotion.IsSimulation = true;
            LaunchExecution(file, 0, 0);
}

[Moray]

Hi Demondar,

my ultimate goal is to replicate all the functions of KMotionCNC in C#, so I can add new functionality.
The current issue with the GCode, is certain things in the Interpreter have to be set/triggered via running the relevant GCode, and not via dotNet
I.e. to switch between Inch/MM, you have to do it via G20/21, as that triggers a sequence in the interpreter that updates various offsets, whereas if you just switch mode via dotNet using LengthUnits, those offsets don't update.

So what I need to do is run a few commands while initialising, like set G20/21, and set the global offset.

I've just done some testing in KMotionCNC, and it looks like the main offsets/modes are shared between the KFlop and simulation, however simulation maintains it's own set of axis positions (i.e if you move the KFlop to say X10, then switch to simulation, the DROs will still show 0).
So it looks like I'm good to set the required modes/offsets with the interpreter in Simulation.

[TomKerekes]

Hi Moray,

While going back over DoGCode to add the line to close the streamwriter, I noticed the line that it puts the interpreter in simulation mode if there is no KFlop connected. Comment out that code, and no mystery lockups, or at least no activating simulation.

That might be a timing/race condition on startup. Maybe something is happening such as the initialization code is checking for a connection before a timer tick occurs which will try to make a connection to obtain status. You might need some mechanism to wait until the connection status has been updated before initialization.

KMotionCNC checks if there is a KFLOP before commanding the GCode because there would be an error if trying to run GCode in non-simulation mode as the Interpreter tries to synch to KFLOP and such. So KFLOP switches to Simulation mode in that case then remembers to restore the original Simulation state after the GCode completes.

I've just done some testing in KMotionCNC, and it looks like the main offsets/modes are shared between the KFlop and simulation, however simulation maintains it's own set of axis positions (i.e if you move the KFlop to say X10, then switch to simulation, the DROs will still show 0).
So it looks like I'm good to set the required modes/offsets with the interpreter in Simulation.

The Interpreter only has one State that applies to both Simulation and non-simulation. So anything like changing units or offsets should apply to the Interpreter State and effect both modes. However Non-Simulation mode actually reads the actual current machine position from KFLOP where obviously Simulation mode can not do this. The Interpreter State has a "Current Position" based on the last commanded position. I tried moving to X10 then switching to Simulation mode and the position remained 10 unlike what you describe. This is because the last commanded position is 10. However if you move in Simulation mode then the Simulated position and actual machine position will then become different.

HTH

[Moray]

That might be a timing/race condition on startup. Maybe something is happening such as the initialization code is checking for a connection before a timer tick occurs which will try to make a connection to obtain status. You might need some mechanism to wait until the connection status has been updated before initialization.

KMotionCNC checks if there is a KFLOP before commanding the GCode because there would be an error if trying to run GCode in non-simulation mode as the Interpreter tries to synch to KFLOP and such. So KFLOP switches to Simulation mode in that case then remembers to restore the original Simulation state after the GCode completes.

By initialisation code, I'm referring to the interpreter initialisation, so setting all the values via dotNet, and sending G20/21 and G52 to ensure the interpreter gets configured correctly.

I'm guessing you are correct about the timing/race condition.
The code sets up the TImer tick, which will happen concurrently in it's own thread, as the main code continues to the initialisation, so I'd guess the interpreter initialisation (well actually the configuration as I've already added a InitializeInterpreter() immediately after the KM_Controller is created to try and stop the problem with offsets being updated from the var file) is happening before a KFlop has been detected and connected to.

Once I'd gone back over the original KMotionCNC code, I remembered I'd looked at the simulation mode activation/deactivation, then for simplicity put the code to switch to simulation in to avoid errors, which obviously came back and bit me :-/
I've now added the extra code to check simulation mode, and restore the mode as needed.

The Interpreter only has one State that applies to both Simulation and non-simulation. So anything like changing units or offsets should apply to the Interpreter State and effect both modes. However Non-Simulation mode actually reads the actual current machine position from KFLOP where obviously Simulation mode can not do this. The Interpreter State has a "Current Position" based on the last commanded position. I tried moving to X10 then switching to Simulation mode and the position remained 10 unlike what you describe. This is because the last commanded position is 10. However if you move in Simulation mode then the Simulated position and actual machine position will then become different.

I've just rechecked this, and if you move to a different position in simulation mode, the DROs will switch between the actual position and the last simulated position if you toggle Simulation mode. But if you then do any move in non-simulation mode, the simulation position is updated.


I'm assuming as things now work as expected, there shouldn't be any problem issuing the G20/21 and G52 before the KFlop connects?

[Moray]

Code: Select all

using (StreamWriter writer = new StreamWriter(file))
{
     writer.WriteLine(gcode);
     writer.WriteLine();
}
string readText = File.ReadAllText(file);
//RichTextBox_GCode.Document.Blocks.Clear();
RichTextBox_GCode.AppendText(readText);

Code: Select all

bool f = false; // bool state, If for some reason an error occurs inside using {}, for example, there will be an error in the specified file path
using (StreamWriter writer = new StreamWriter(file))
{
     writer.WriteLine(gcode);
     writer.WriteLine();
     f=true;
}
if (f)
{
	RichTextBox_GCode.AppendText(gcode); // the text is the same and it makes no sense to read it from a file, this increases the execution time
	 if (!Connected) KM.CoordMotion.IsSimulation = true;
            LaunchExecution(file, 0, 0);
}

Demondar, I forgot to say thanks for.
The code at the moment is quite messy, with various parts done as simply as possible to test things. The reading from file, was so I could check what was physically being written without swapping to a different window to open the text file.

My current goal is to understand how all the basic functionality works, and once I've achieved that (main thing left is to handle tools - I've got it working using the old tool table format, but I'd like to load tools directly without needing an external tool file), I'll go back over my code, clean it up, and add in the extra error checking.

[TomKerekes]

Hi Moray,

I'm assuming as things now work as expected, there shouldn't be any problem issuing the G20/21 and G52 before the KFlop connects?

Yes I believe so.

[Demondor]

Hi Moray.
I think I realized that you can’t. And I see this option.Starting the timer is done as a separate function, in the constructor only setting the timer. After you load all the necessary settings for yours and the interpreter, including files for the interpreter. After all the settings, start the timer. In the tick of the timer, enter the variable, after connecting to the board, count several ticks and run your code, then set the flag that the action has been performed and it is no longer necessary to perform it.
Sorry for my google English.

[Moray]

Hi Tom,

Now I have my gcode text viewer mostly functional (still got a couple minor issues to fix), I'm looking at graphics.

I see there are various callbacks, but I'm struggling to fully understand them.
Are they called once at the end of the relevant move, or continually during the move?

Also what do the sequence_number, and ID actually do?
Do I need to use them for generating graphics (from my scan of the interpreter files, it looks like sequence_number is related the GCode line number?), or can I ignore them?

[TomKerekes]

Hi Moray,

I see there are various callbacks, but I'm struggling to fully understand them.
Are they called once at the end of the relevant move, or continually during the move?

As the Interpreter parses the GCode which creates coordinated motion segments to be buffered, it makes the call backs below to inform the application what motion was actually created. Note the Interpreter must always work ahead to keep enough buffered data so that if the PC/Windows/USB stalls for some time the motion will continue un-interrupted. The Interpreter typically works ahead a few lines of GCode but in extreme cases might be working ahead hundreds or thousands of lines. Also the converse is true. A single line of GCode may create several or hundreds of motion segments. Each callback occurs once at the time the Interpreter/Trajectory Planner decides a particular motion segment will be made. KMotionCNC's GCode Viewer basically adds/draws the motion at the time of the callback which is why it always shows the upcoming look ahead path.

Code: Select all

void StraightTraverseCallback(double x, double y, double z, double a, double b, double c, int sequence_number);

void ArcFeedCallback(bool ZeroLenAsFullCircles, double DesiredFeedRate_in_per_sec, 
			    CANON_PLANE plane,
				double first_end, double second_end, 
		        double first_axis, double second_axis, int rotation,
				double axis_end_point,double a, double b, double c,
				double first_start, double second_start, double axis_start_point, int sequence_number, int ID);

void StraightFeedCallback(double DesiredFeedRate_in_per_sec,
							   double x, double y, double z, double a, double b, double c, int sequence_number, int ID);

Also what do the sequence_number, and ID actually do?

sequence_number advances by one for each line of GCode executed. So if Execution begins on the first line and there are no subroutine calls or loops then the sequence_number will equal the GCode Line number. But in general this will not be the case.

In some cases a single line of GCode has more than one part to it. Mainly when radius compensation is active a single feed can create a feed and arc. The ID identifies which part of the GCode created the motion.

Do I need to use them for generating graphics (from my scan of the interpreter files, it looks like sequence_number is related the GCode line number?), or can I ignore them?

With look ahead halt/resume turns out to be quite complicated. With regard to graphics, when a halt occurs and the machine actually comes to a stop, KMotionCNC erases the look ahead graphics back to where the tool actually stopped. After coming to a stop the sequence number and ID of where we stopped is determined. So all the graphics with a larger sequence number/ID is removed. Because we likely stopped in the middle of a line of GCode, then the graphics beyond the xyz point where we stopped, with the same sequence number and ID, should also be removed. See the function:

int CPath3d::RemovePathEnd(int sequence_number, int ID, double x, double y, double z)

HTH

[Moray]

Thanks for that Tom.

I think I maybe understand about 70-80% of what happens, and I'll hopefully understand a bit more once I start the code, and see what data is produced.

I'll very likely be back with more questions though!