qtvcp issues

I have found something interesting that is potentially a problem that needs to be looked into.

If I modify the x1Mill_P gui to look like this and save it and making sure it goes into the folder where my .ini file is:



When running I get back:



So there is a path determination error in that the gui file being used is not the one in the folder that .ini is in.
Here is what I have for a gui path and this is expected to route correctly and likely the source of my problem.

To determine the actual file location of my .INI file and to use it as a base location for all other file locations for my x1Mill gui. I have some code in my handler file that I use to do this. Right now it only has determination for my preference file but other files or paths to files can be added easily from this base location.

I plan on having everything that the gui requires within the folder that the .ini file is in, including folders for icons, macros, or whatever. I do not like scattering these items all over the place. I want to be able to grab the entire folder for backup and have everything it needs.

Attached is the code I use in my handler that for right now only has my preference file added. Perhaps this will aid in properly locating the .ui file under all conditions when its name is added.

If you look at the debug output in the terminal, it should give you information about where it is looking for the UI and handler file.

The is already a mechanism for finding path information.
in the handler file's __init__ function, the 'paths' gives reference to this information.
for instance:
paths.CONFIGPATHS gives the path to the configuration file that was launched.
paths.IMIAGEDIR gives the path to standard image files.
There are more.
The qtvcp.core library 'Info' gives important INI information, including the INI path

There is already a mechanism for a preference file - that is one of the things the screen_options widget sets up.
In the handler file's initialized__ function, the variable 'self.w.PREFS' holds the reference to the preference file

auto-mation-assist wrote: Chris,

Ok I will try to do that today but may not have the time. I suspect now this may only be a local problem here and that I need to do a little more work to try to figure this out.

I like the fact that you were able to eliminate the need for pins in the Versa code. If I can figure out the changes required I would like to built a version of that also. I Will push the latest changes to the probing gui soon but this may not help you a lot since I use different names for buttons and displays to clarify those items just a bit. It will likely need a lot of search and replace work for the names.

On the use of pins:

I think the use of pins gives an easy way to code things and offers a great deal lot of flexibility for the user. Flexibility in my mind is very important since many LinuxCnc users will always want to add special functions in a fast and easy way without involving the programmer and asking for modifications to the main code. I consider pins to be similar to global variables. It offers a way to route data to suit the users requirements.

In looking at the hal components I generated within my handler file I noticed that they never enter a ready state. I wonder if they need to be placed in the 'bin' folder somehow so they can be found. There was some mention of something like that in my internet search for a answer as to why 'ready' never occurs. I have added some pictures of how I generate the pins are below in the hope of solving the never ready problem. Adding the below to the postgui hal file does not help.

loadusr -W x1_jogging
loadusr -W x1_tool_measure
loadusr -W x1_probing


In your file 'qtvcp' located in the bin folder there is:

##############
# Build ui
##############

#if there was no component name specified use the xml file name
if opts.component is None:
opts.component = PATH.BASENAME

I would like to enter a name here but have no idea of where to put such a name.



My editorial comment: I think we all know that LinuxCnc is lacking a modern network interface and that this has resulted in everyone being forced to find ways to interface modern methods to poorly documented ancient code that relies on NML.

It seems Versaprobe uses HAL pins to transport preference file info to the Oword routines.
Maybe the idea is to allow one to changes these on the fly - but that seems a wrong way to do it.

If one makes a HAL component after making the pins, one has to specifically make the component ready.
HAL components are explained here: linuxcnc.org/docs/devel/html/hal/halmodule.html
You don't need to make a new HAL component - you can use qtvcp's HAL component - self.hal gives reference to it in the handler file.

To change the base name of qtvcp's HAL pins, use the -c switch in the INI file:
DISPLAY= qtvcp -d -c newname x1Mill_p

Chris M

I can chalk up my recent problems to human error.

My original problem with buttons not responding as expected was due to me setting up the buttons to use signal 'toggle' instead of 'pressed'.

During trouble shooting my links to the gui in qt designer got pointed to the wrong gui folder, while my run environment was set to the correct folder. Thus no matter what changes I made to the gui it made no difference.

But its all better now so I can march on.

It also cured my HAL components not ready notification.

Chris,

Since I got my project back on tract and finished with my buttons and hal pin self lessons I had time to get the 'form' probing panel up to date for the Versa Widget.

I have pushed the latest and perhaps final version of the probe .ui along with documentation that is in the document folder to my git hub account at: github.com/auto-mation-assist/x1Mill_bra...m/x1Mill/versa_probe

I would like to make this the Versa_probe.ui and then help work on anything required to integrate it and make it compatible with the versa_probe.py widget. Since I use the .ui in multiple projects I would like to keep the names within the .ui file the same.

Let me know what you wish me to do.

Picture of the probing gui:

That looks great.
The only reason i haven't updated the ui file is because of the name changes.
Ultimately I con't care much what the names end up as, but during development, it's painful to convert from versa probes naming to yours, while still referencing versa probes function names.

I'm having difficulty to test the probe routine on a real machine as my machine is not sable with the newest distribution. I do note that we probably have to look at what to do if the motion controller is in out of metric mode. ( I assume you use metric )
Mind you it might a problem because the conversion is not completed.

I'm curious why you would still us the ui file separately after a widget is made - surely the widget is easier to use?

Chris M

Working with what I have within the x1Mill gui related to probing allowed me to get a good feel on what was needed and how it could be accomplished in a way that was like original with only name and format changes. It does not need a lot more to become fully functional but I do not plan to continue on that path. But may come useful in the future so I will just put it in storage as a potential resource.

I will work on getting the latest .ui into the Versa Widget on my end and do any name conversions required and see how it goes. I think you may have the straight down probing working or nearly complete. I can easily test on my milling machine.

I know that changing the names from the originals on my end was a pain but did not mind doing it to match the .ui file that was generated long before looking at Verser code.

Since I'm done with testing buttons for now I'm back to using my original gui that uses action pins for a good number of things. I need to get my Jog rate and step size routines to interface with qtvcp now. I just need to enter the required links and will look at the action button code as an aid o see what is needed..

I just remembered that I forgot to add that almost all my work is done in factions of inches and not mm.

Ok I pushed updates to include your latestest design and reworked the names to use your defaults - other then I fixed a miss spelling of length.
It's on going work of course.

Chris M