G-codes/offsets/tools with .Net

[TomKerekes]

Oops I thought that was what you were after.

I think you'll want:

Code: Select all

int CScreen::ServiceImageButtons()

[Moray]

Thanks Tom, that looks like the correct function.

I've just spent this evening doing the ground work for dual state controls (aka controls that can change depending on a bit status), and my head is now burst from trying to remember LinQ, however I now have a filtered list of controls that now just need code added to change their properties depending on the attached bit state.

[Moray]

Latest version attached.
It's a full Zip that needs unzipped into the Kmotion/Release directory, and includes a few images and the default Screen (still technicolour!) with a few userbuttons, label, and image in the lower left corner of the screen to show the new functionality.

I now have what I'm calling DualState controls (I think!) fully functional.
This lets you set various control properties (Text/Colour/Image where allowable) to be dependant on the state of an individual bit.

There's no sanity checking on what Bit you enter on the ScreenDesigner screen, but it shouldn't let you enter anything non-numeric.

Next item on the list is Momentary and Toggle buttons, then I'll get onto LabelDROs.

[Moray]

After quite a bit of code refactoring, and changing how Bit controlling is handled, I now have the full suite of Buttons coded.
Normal single hit buttons, toggle buttons, and momentary buttons now exist.

You can also set an unlimited number of bits for any Button that controls bits.

I still need to add Bit validation, so I won't upload a new version just yet.
I'll also mention that I left quite a big bug in the previous upload, whereby you won't be able to reposition any controls using the Screen Designer. I had done some code tidy up, and got a couple variable names/indexes wrong, so the values didn't get saved correctly.

Next steps are user configurable CheckBoxes, and then being able to set Vars/Parameters for UserButtons that can make use of the functionality.

[Moray]

Oops I thought that was what you were after.

I think you'll want:

Code: Select all

int CScreen::ServiceImageButtons()

Tom, I'm finally getting around to LabelDROs, but my understanding of c++ is somewhat hindering me.
I see the relevant code for LabelDROs in the top function initially gets a result from GCodeDlg.GetVar

Code: Select all

int CKMotionCNCDlg::GetVar(int Var, int *value)
{
	CString s,r;

	if (Var >= 0 && Var < 200)
	{
		s.Format("GetPersistHex %d",Var);
		if(TheFrame->KMotionDLL->WriteLineReadLine(s, r.GetBufferSetLength(100))) return 1;
		r.ReleaseBuffer();
		sscanf(r,"%x",value);
	}
	return 0;
}

I'm struggling to understand exactly what the WriteLineReadLine section is doing.
I can see that if it returns 1, an error message is displayed, and it needs to return 0 in order to continue to reading the buffer.

Do I need that for dotNet?
Or can I simply read the VAR, get the string from the buffer, set the VAR to 0, and update my label?
(obviously with suitable error checking along the way)

[TomKerekes]

Hi Moray,

I'm not sure I understand the question. This function attempts to read a persist variable from KFLOP. The WriteLineReadLine sends the request and returns the response. If there was some error for example the USB cable was unplugged in the middle of the transaction then the function returns a non-zero value to indicate it failed. You should do something similar in .NET.

[Moray]

I think the main thing is I'm currently failing to understand how the whole LabelDRO process works, however having found and looked at the Add example, I'm a bit closer to understanding it.

This is what I think the process is-
C( Program/KFlop) loads the gather buffer.
C then sets the relevant VAR to the Gather Buffer offset.

KMCNC monitors the VAR (I failed to realise yesterday that WriteLineReadLine is used to simply read the VAR value).
If it's not 0, it then triggers the process to read the String from the Gather Buffer.
Once it's read the string, it then sets the VAR (back to) 0.

Does that sound right?
Am I also correct in saying that I could use GetUserDataFloat to read the VAR instead of WriteLineReadLine?

[TomKerekes]

That is all correct except GetUserDataFloat expects the value to be a float not an integer. KFLOP and the PC must agree on what the 32-bit value represents. Either an Integer or the binary image of a float. In this case it is an integer offset into the Gather Buffer so GetUserData would be appropriate.

[Moray]

And I now have functioning LabelDROs (although I have since realised you named them DROLabels!)
I also have the ability to set LabelDROs to read any VAR value, and display it as a label.

And having gone through the full list of ServiceKFlopCommands, the only things I still need to add are PC_COMM_GET_VARS and PC_COMM_SET_VARS, which shouldn't be too hard to implement.

All this now means I can start work on a proper screen, as my main goal is to have a toolchanger setup/status screen for my mill.

I'll try and get another upload done over the next few days, as there's a couple sanity checks I need to add, to avoid issues with control naming.

[Moray]

That is all correct except GetUserDataFloat expects the value to be a float not an integer. KFLOP and the PC must agree on what the 32-bit value represents. Either an Integer or the binary image of a float. In this case it is an integer offset into the Gather Buffer so GetUserData would be appropriate.

And forgot to mention, the reason I mentioned GetUserDataFloat, is that if you search for UserData in the help file, it only finds the options for Float and Double, not GetUserData. It only finds GetUserData if you explicitly search for it, as the help page for it doesn't contain just UserData (float and double have UserData in the code examples)