G-codes/offsets/tools with .Net
Moderators: TomKerekes, dynomotion
Re: G-codes/offsets/tools with .Net
While I'm logged in, just a quick update.
The screen designer is now functional.
I won't say fully functional, as it's a big "clunky" to use, but it allows moving/editing controls, and in terms of custom controls, allows unlimited buttons that can switch screens or execute C Programs.
I have a wish list of items to add (ability for buttons to control outputs, and labels to respond to bits), but am currently working on tidying up the core functionality, as my next step is using it on a functioning machine.
However once I get the directory structure tidied up, I'll get another version uploaded to get some feedback.
The screen designer is now functional.
I won't say fully functional, as it's a big "clunky" to use, but it allows moving/editing controls, and in terms of custom controls, allows unlimited buttons that can switch screens or execute C Programs.
I have a wish list of items to add (ability for buttons to control outputs, and labels to respond to bits), but am currently working on tidying up the core functionality, as my next step is using it on a functioning machine.
However once I get the directory structure tidied up, I'll get another version uploaded to get some feedback.
- TomKerekes
- Posts: 2676
- Joined: Mon Dec 04, 2017 1:49 am
Re: G-codes/offsets/tools with .Net
Regards,
Tom Kerekes
Dynomotion, Inc.
Tom Kerekes
Dynomotion, Inc.
Re: G-codes/offsets/tools with .Net
I do have it uploading to GitHub, but that's not my GitHub, and I've still got mine set to private.
Re: G-codes/offsets/tools with .Net
This is the latest version, just to get some feedback on the screen designer.
You need to unzip the attached file to the KMotion/Release directory. When run, a basic configuration file should be created, along with a default screen. The only reason the Screens/Images directories are included, is the default screen makes use of the Kogna image (there should be a Kogna image as the background, if not can you post up the contents of the Debug box on the Debug tab).
If you add images, they must be within the Screens directory, or a sub-directory of Screens (external Image referencing is a bit of a pain, so image URI's are hardcoded from Screens).
The default screen is a bit technicolour, as I had it setup to try out various control properties, and I've not yet sanitised it.
There are a few notes that are on my todo/tofix lists-
-- If you change the control name (on a control that lets you change the control name aka only user controls), and don't comply with the WPF control naming requirements (can't have spaces or various special characters), then the app will crash (I need to add a try/catch, and input validation).
-- You need to click Make Changes before any change will occur (or for those changes to be saved)
-- If you use SaveAs, and want to then work on the new copy/screen, you need to load that new Screen, then reload the Screen Designer in order to edit it (the default screen on loading can be changed on the Config -> Tool/Setup Files tabs)
-- The RichTextBox_GCode cannot be deleted. It can only be made not Visible. This is because loading big files can be quite resource heavy, plus there is the whole keeping track of line positions, and I felt simply hiding it so you can switch between screens would be a more efficient way of handling the GCodeViewer.
-- Colours can either be entered as a full hex ARGB code, or using using standardly available text options - https://learn.microsoft.com/en-us/dotne ... esktop-8.0
-- DRO Set buttons are still hardcoded (I've not yet got around to creating code behind for the pop-up windows)
-- Slider do nothing
I would strongly advise not to try running this on a working machine, as I've only done some very minimal testing, and have no idea what I've managed to break while adding the ScreenDesigner!
Also I've just remembered that if you do create a User Button to run a C Program, despite being able to save a thread number, the actual thread is still hard coded (I actually started to do finish this tonight, but decided I'd finish of a few other loose ends to get this release uploaded)
You need to unzip the attached file to the KMotion/Release directory. When run, a basic configuration file should be created, along with a default screen. The only reason the Screens/Images directories are included, is the default screen makes use of the Kogna image (there should be a Kogna image as the background, if not can you post up the contents of the Debug box on the Debug tab).
If you add images, they must be within the Screens directory, or a sub-directory of Screens (external Image referencing is a bit of a pain, so image URI's are hardcoded from Screens).
The default screen is a bit technicolour, as I had it setup to try out various control properties, and I've not yet sanitised it.
There are a few notes that are on my todo/tofix lists-
-- If you change the control name (on a control that lets you change the control name aka only user controls), and don't comply with the WPF control naming requirements (can't have spaces or various special characters), then the app will crash (I need to add a try/catch, and input validation).
-- You need to click Make Changes before any change will occur (or for those changes to be saved)
-- If you use SaveAs, and want to then work on the new copy/screen, you need to load that new Screen, then reload the Screen Designer in order to edit it (the default screen on loading can be changed on the Config -> Tool/Setup Files tabs)
-- The RichTextBox_GCode cannot be deleted. It can only be made not Visible. This is because loading big files can be quite resource heavy, plus there is the whole keeping track of line positions, and I felt simply hiding it so you can switch between screens would be a more efficient way of handling the GCodeViewer.
-- Colours can either be entered as a full hex ARGB code, or using using standardly available text options - https://learn.microsoft.com/en-us/dotne ... esktop-8.0
-- DRO Set buttons are still hardcoded (I've not yet got around to creating code behind for the pop-up windows)
-- Slider do nothing
I would strongly advise not to try running this on a working machine, as I've only done some very minimal testing, and have no idea what I've managed to break while adding the ScreenDesigner!
Also I've just remembered that if you do create a User Button to run a C Program, despite being able to save a thread number, the actual thread is still hard coded (I actually started to do finish this tonight, but decided I'd finish of a few other loose ends to get this release uploaded)
- Attachments
-
- KMoCNC_240111.zip
- (1.18 MiB) Downloaded 250 times
Re: G-codes/offsets/tools with .Net
I'm back looking at the core functionality, and have already fixed a big bug I introduced in the DRO colours, but I'm struggling with the DRO values and I can't remember if this is something I've had an issue with before or not.
If I enable my test machine, the DROs start at 0.
If I then jog say 1mm, the DRO shows 1mm.
If I then click the axis Zero button, the correct offset gets updated, but the DRO remains at it's previous 1mm value.
To get the DRO values, I'm using ConvertAbsoluteToInterpreterCoord()
Am I correct in thinking that this should be applying the appropriate offsets to the DRO without me having to add code to apply the active offset(s)?
If I enable my test machine, the DROs start at 0.
If I then jog say 1mm, the DRO shows 1mm.
If I then click the axis Zero button, the correct offset gets updated, but the DRO remains at it's previous 1mm value.
To get the DRO values, I'm using ConvertAbsoluteToInterpreterCoord()
Am I correct in thinking that this should be applying the appropriate offsets to the DRO without me having to add code to apply the active offset(s)?
Re: G-codes/offsets/tools with .Net
Just realised what I've been doing wrong.
I've been writing the values to the DROs before calling ConvertAbolsuteToInterpreterCoord/Machine(), so I was writing the absolute values to the DROs, and as I use the same variables for reading the absolute values and writing to the DROs, I was only getting the absolute value.
Re-ordering the code has solved the problem, but I need to think if using the same variables is going to cause me problems later..
I've been writing the values to the DROs before calling ConvertAbolsuteToInterpreterCoord/Machine(), so I was writing the absolute values to the DROs, and as I use the same variables for reading the absolute values and writing to the DROs, I was only getting the absolute value.
Re-ordering the code has solved the problem, but I need to think if using the same variables is going to cause me problems later..
Re: G-codes/offsets/tools with .Net
This is the latest version. It's only the basic .exe, so you'll need to combine it with the previous download to get all the additional files.
DRO set buttons can now be added/removed/edited, although the popup is currently hardcoded (I do appear to have a bug with setting/zeroing the Z axis, but I'm not sure why, as the code is identical to the X and Y).
User Buttons can now be configured to trigger single Bits.
I've also fixed a few other minor issues.
And I forgot to mention in the previous posts, that the Screen Designer button is hardcoded to the lower right corner of the Main tab just for easy access while testing things at the moment. I will eventually move it to a settings tab.
DRO set buttons can now be added/removed/edited, although the popup is currently hardcoded (I do appear to have a bug with setting/zeroing the Z axis, but I'm not sure why, as the code is identical to the X and Y).
User Buttons can now be configured to trigger single Bits.
I've also fixed a few other minor issues.
And I forgot to mention in the previous posts, that the Screen Designer button is hardcoded to the lower right corner of the Main tab just for easy access while testing things at the moment. I will eventually move it to a settings tab.
Re: G-codes/offsets/tools with .Net
Noticed I created a bug that prevented the File and Thread from being saved for User Buttons, so I've deleted the file from the previous post and attached the latest version to this one.
Tom, how are DRO Labels handled?
I've tried searching the KMotionCNC code for them, but I'm struggling to find them. It's probably not helping that C++ code really isn't one of my strong points!
Tom, how are DRO Labels handled?
I've tried searching the KMotionCNC code for them, but I'm struggling to find them. It's probably not helping that C++ code really isn't one of my strong points!
- Attachments
-
- KMoCNC_240118.zip
- (621.29 KiB) Downloaded 248 times
- TomKerekes
- Posts: 2676
- Joined: Mon Dec 04, 2017 1:49 am
Re: G-codes/offsets/tools with .Net
see function
Code: Select all
void CKMotionCNCDlg::SetBigValues(CDisplay *Disp0, CDisplay *Disp1, CDisplay *Disp2, CDisplay *Disp3, CDisplay *Disp4, CDisplay *Disp5, bool KMotionPresent)
Regards,
Tom Kerekes
Dynomotion, Inc.
Tom Kerekes
Dynomotion, Inc.
Re: G-codes/offsets/tools with .Net
Tom, I'm not sure that's the right function, as that only appears to handle the main DROs, and Spindle Speed/Feedrate, not the DROlabels (one's that can be set to monitor a Var, with a C program on the Kflop being able to output to them).
Although that has reminded me I need to add the spindle and feedrate information.
Although that has reminded me I need to add the spindle and feedrate information.